Reprise du message précédent :
Idéalment, les dev n'ont qu'a decouper en Thread, après c'est au Kernel de l'OS de savoir comment les repartir sur les CPU disponibles.

les additions sur le processeur 1, les multiplications sur le processeur 2
et après ça pète le feu

Optimiser pour du dualcore (ou du multicore) ce n'est pas "simplement" découper en thread. Et ce n'est pas le nombre de morceaux qui compte, mais la "taille" (% de charge de calcul) de chaque morceau, et en particulier la taille du plus gros morceau.
Exemple tout con : un dev qui découperait en morceaux, rendering, physique, IA (1 threas/unité), son (1 thread/son), reseau (1 thread/socket), etc.
Ca donnerait en permanances plusieurs dizaines de thread. Naivement on pourrait penser que c'est optimisé pour du multicore et que ça irait 16 fois plus vite sur un 16-cores que sur un monocore. Malheureusement rien ne permet de l'affirmer. Il suffit que le thread chargé du rendu 3D prenne 80% de la charge globale de calcul pour que tout tombe à l'eau ou presque.
Monocore : indice 100
Dualcore : indice 125 (1er core utilisé à 100% par le thread de rendu, tous les autres thread sur le 2ème core utilisé à 25%)
Quadcore : indice 125
n-core : indice 125 (n >=2)
 
Bref, malgré le fait que le dev est découpé au maximum tout ce qui pouvait etre découpé, malgré le fait que l'OS dispatchait idéalement tous les thread en fonction de leur charge, etc. le gain n'est que de 25% sur un dualcore, et aucun gain supplémentaire avec un quadcore (comparé au dualcore).
 
La phrase "les dev n'ont qu'a decouper en Thread" ressort souvent. En plus de sous-entendre que c'est simple à faire, c'est complètement faux. Il ne suffit pas de découper en thread.

Vous avez pensé aux performances ? non parce que  faire tourner plusieur threads à fond sur un seul CPU c'est loin d'être optimal.
 

et le coup de faire apparaitre les multicores comme un seul core pour les applis, ca donne que 25% également ?

 
Non ça pour l'instant c'est du domaine du fantasme donc ça donne 0%

 
Si, sauf que c'est la phrase découper en threads qui est comprise n'importe comment. C'est découper en threads globalement équivalents en terme de charge de calcul, et ca, c'est bcp plus compliqué comme vous l'avez tous expliqué les uns les autres

Oxygen3> Je reste persuadé (et je l'ai déjà vu sur Clubic, PCI...) que cette phrase, balancée comme ça, sans autre explication, et en utilisant l'expression "il suffit de" ou "n'ont qu'à" signifie que la personne n'a pas bien compris la différence entre faire du multithread et de l'optimisé multicore. Est-ce le cas de Mei ? J'en sais rien. Mais dans le doute, je préfère préciser certaine chose. Il n'y a pas que Mei qui lira mon post.

Clair, le "Yaka" c'esst facile à faire. Après, faut retrousser ses manches

le problème n'est pas que de répartir, le problème est de synchroniser et de ne pas de se choper de pénalités lors de d'échanges syncrhonisés verrouillé par le noyau.
 
pour que ce soit rentable, il faut que les éléments répartis en thread aient une certaine granularité avec peu d'inter-dépendances.
 
par exemple un thread par unité IA dans un jeu ce serait monstrueusement merdique dû aux interactions entre IAs.
 
après on peut dicrétiser le monde par zones indépendantes et répartir les zones sur plusieurs coeurs (genre un serveur dédié de monde permanent), ou d'autres trucs... (les libs physiques genre PhysX, Havok arrivent a profiter du multiproc, maintenant je sais pas c'est du balancement de charge au niveau group d'éléments simulés, ou autre approche...)

Tout dépend du nombre, mais avoir par exemple un nombre de thread x2 ou x4 du nombre de coeur je n'ai jamais vu que ca pénalisait fortement sur un monocore.

C'est d'ailleurs généralement comme ca que ca se passe me semble-t-il. La partie difficile n'est pas la répartition sur les CPU disponibles, c'est bien le découpage en thread.

J'vois pas comment ça pourrait se passer autrement. Cette remarque est banale finalement : pour qu'un processus puisse profiter du multicore, il suffit de découper en thread. Les developpeurs sont tous contents de l'apprendre...

ça dépends de l'interdépendance entre les différents threads et de leur charge respective. Pour de la compression video, la communication entre les threads doit être insignifiante donc ça n'a que peu d'impact si on a plus d'un thread par core. par contre pour les jeux c'est autre chose.

trés interessant pour un ignare comme moi tout ca
 
mais comme c vendredi:
"ouai ben depuis que je suis passé au multicore j'ai les vidéos qui rament "

Bien entendu mais ce que je voulais dire c'est que ce n'est pas le fait de faire tourner plusieurs thread sur le core qui fait baisser significativement les perfs.

"Il suffit" "Y'a qu'a" "C'est simple" sont des mots à ne jamais prononcer en la présence d'un dev

On est bien d'accord
 
Ils ont bien raison, faut pas se laisser faire

y'a pas qu'en face d'un dev qu'il faut pas le dire

moi en plus j'ai "faut pas bcp de temps pour faire ca?"

je ne réponds jamais non à cette question

moi en fait c'est souvent plutot une "question" affirmative

Question bete
 
est ce que la calibration varie d'un ecran a un autre du meme modele sur les CRT?
 

Bien sûr.

donc si j'achete 20 crt 21" de meme marque et de meme modele va falloir tous les calibrer?
 
c'est pour de l'imagerie dentaire

ils ont besoin d'ecrans calibrés en imagerie dentaire? si c pour des radios n&b t'as juste a regler le contraste et luminosité moi je penserais

c'est pour des images en 12bits monochrome nan? ce qui doit être intéressant c'est d'avoir au moins une carte vidéo qui affiche du 10 bits par composante (matrox, radeon X1xxx??)  (et que le logiciel suive)

faut prendre des mesure pour les implants et d'autre chose  
detecter les differents vaisseau sanguin ainsi que les nerf
 
bref il faut une image la plus fidele possible
 
 
et avec les lcd c'est pas encore ça

8 bits et 12 bits oui
 
mais on commence a voir des panoramique  3d maintenant

Salut,
 
Je change de sujet : ca fait depuis longtemps qu'on a plus parle du R600 directX10 d'ATI. C'est quoi le dernier status sur ce GPU ? (tjrs 80nm et pas 65nm , fin 2006 ou debut 2007 ?)
 
Merci !

J'ai entendu parler de 65nm chez ati, j'aurai mal entendu ?

je crois que c repoussé pour encore aprés le R600. ca marche mais y a pas encore un pourcentage assez rentable sur les yields si je me souviens bien

http://www.zeden.net/zeden/img.php [...] e=2006-09/
 
c'est moi ou la normal map du crâne est un peu cracra ?
(ou alors c'est une shadow map ?)

j'pense que c'est le post processing qui fait ça ... ça m'a l'air de faire un "cadrillage" assez droit

je pense pas que ce soit tu post-processing.
 
ça ressemble a normal map en DXTC ou une shadow map sans PCF ou autre.

achète un bon colorimètre, ça devrait pas exploser ton budget

Je penche plutot pour un artefact de compression.