Voir la version complète : Nehalem et innovations
Voilà, c'est parti...
Nehalem :
- nouvelle architecture (détails à définir)
- IMC comme l'A64 (détails à définir)
- CSI (HT like - détails à définir)
- quad core natif (pour ce que ça change...)
- octo core pas natif du coup (?)
- 45nm
- retour de l'hyperthreading à 2 process par core
bip bip...
Octo core natif base sur le core Nehalem aussi, mais pas encore presente, une demo a aussi ete faite d'un dual socket quad core.
Ok... J'hésite entre éditer le premier post pour le tenir à jour, et continuer la discussion... Je vote continuer la discussion...
Quelqu'un a vu sur le net un jeu des 7erreurs :D entre CSI et HT ?
d'autre part, on sait déjà quelle ram prendra l'IMC ? DDR3 - DDR4 - DDR8 (pourquoi s'emmerder) - ECC - Registered - FB-DIMM ?
Franck@x86
19/09/2007, 18h44
L'hyperthreading j'arrive pas trop à comprendre son intérêt sur une archi à pipeline court comme celle-ci, car mine de rien c'est une grosse source de conflits dans les L1.
Sur P4 le pipeline était tellement peu rempli par un thread que ça compensait les conflits de cache (et encore, pas toujours).
Et pour finir, il faut un OS capable de distinguer une unit logique d'une physique, cf le problème soulevé y'a qques temps sur ici même :
http://www.x86-secret.com/index.php?option=newsd&nid=850
Enfin j'imagine que si c'est prévu c'est que ça a un intérêt (méchamment j'allais ajouter "autre que commercial" ;))
(ou alors le pipeline n'est plus is court que ça :whistle: )
Je pense que l'article de RWT ne laisse plus beaucoup d'interrogations sur le CSI, même si je dois avouer qu'il y avait trop d'élec/physique pour moi et je n'ai pas tout lu. Et si on veut être précis ce n'est pas de l'HyperThreading mais du SMT, l'HT n'étant que l'implémentation du SMT au sein de NetBurst. Sa présence dans Nehalem est peut-être liée à une volonté de booster tout ce qui à trait à la virtualisation...
Stéphane.P
20/09/2007, 09h59
J'espère qu'ils vont nous trouver un remplaçant à la FB-Dimm qui ne soit pas trop couteux.
Et qui ne consomme pas 10W par barette...
Stéphane.P
20/09/2007, 11h38
Et qui ne consomme pas 10W par barette...
:jap:
J'ai encore manqué de me bruler les doigts hier. :lol:
Et si on commençait à envisager une DDRx-like en ZRAM histoire de gagner en densité, en dissipation, en fréquence et en latence. Apparement (avec ce que je sais des process, car je n'ai trouvé aucune infos spécifiques), le dev et la MaP seront coûteux, mais en prod, les coûts seront réduits (peut être même moins cher que la RAM actuelle, malgré le SOI obligatoire).
Regarde du cote de la PCM (http://en.wikipedia.org/wiki/Phase-change_memory)
L'hyperthreading j'arrive pas trop à comprendre son intérêt sur une archi à pipeline court comme celle-ci, car mine de rien c'est une grosse source de conflits dans les L1.
Cà existe depuis le POWER4 à 15 étages sur les entiers. Font ils çà pour le plaisir ?
Il s'agit plus probablement de mieux exploiter un pipeline très superscalaire, à mon humble avis. Le cache L1 pourrait gonfler un peu au passage, pour limiter les conflits.
C'est dans le POWER 5 que IBM a introduit le SMT, pas dans le POWER 4 (http://en.wikipedia.org/wiki/IBM_POWER)
RMI XLR (MIPS) sorti en 2005 est SMT aussi avec un pipeline plutot court.
Sur un P4 l'interet du SMT etait de combler des bulles de pipeline essentiellement creees par les longues latences de la plupart des operations et le manque d'opportunites de speculation.
Dans un processeur a pipeline plus court, comme le signale Alexko le SMT sert plus a remplir des unites d'executions que l'OOO n'arrive pas a alimenter par manque de parallelisme d'instruction.
Gonfler le cache L1 signifie souvent en augmenter la latence et/ou en changer l'architecture de maniere significative. La methode souvent employee pour permettre d'avoir un L1 rapide et assez gros est d'avoir une associativite assez faible, ce qui ne va pas du tout avec la multiplication des threads dans le CPU (on se retrouve avec un cache plus gros certes, mais avec beaucoup plus de conflits). Disposer d'un cache un peu plus gros et rapide apres le L1 permet d'amortir les conflits dus au SMT, mais ca implique d'avoir 3 niveaux car les caches de plusieurs MB ne sont pas particulierement rapides.
Dans ce cas, que reste-t-il à Nehalem pour gérer les problèmes de conflits dans le L1 ?
Garder une associativite "assez" elevee
Mais alors sans gonfler le L1 on se retrouve avec plus de conflits que sans SMT... et si on le gonfle on augmente la latence, ce qui est mauvais pour les performances en général, et single tread en particulier. Me trompé-je ?
Tu ne te trompes pas, il est difficile de ne aps reduire la performance d'1thread donne quand on execute un autre thread SMT en meme temps.
De maniere generale toutes les ressources qui doivent etre partagees ont une taille apparente plus faible lors de l'execution SMT. L'avantage est que la performance n'augmente pas de maniere lineaire avec la taille de ces structures.
L'essentiel est que le partage d'une structure ne penalise pas plus que le partage d'une autre de maniere a ne pas creer de goulets d'etranglement (une partie des penalites associees au partages de buffer ne sont pas additives).
Si le SMT "apporte" 20% de performance, au final chacun des threads ne fonctionnera qu'a environ 60% de sa vitesse originale si il avait ete seul. Le partage du L1 n'etant qu'un des elements contribuant au ralentissement.
Donc si on prend un exemple concret, disons un rendu 3DS Max : sur un Quad Core w/ SMT 2-Way, il peut être plus judicieux d'utiliser 4 threads plutôt que 8 ? Si oui, ça ne simplifie pas la vie des développeurs...
Non,
A supposer que ton scaling pour ajouter 1 core est de 1.8 et ton scaling pour ajouter un thread SMT est de 1.2
Perf a 4 threads : 3.6
Perf a 8 threads : 4.3
En revanche si tu as 1 thread de quake et N threads de 3DSmax, il vaut mieux ne faire tourner que 3 threads de 3DS max plutot que 7 parce que sinon ton quake va ralentir de maniere significative.
(bien entendu mes 1.8 et 1.2 sont hypothetiques, meme si plausibles).
Une petite question au passage sur le SMT sur une archi à pipeline long (genre HT sur p4 :D): en cas d'erreur de prédiction, est-ce que ça n'est pas encore plus pénalisant car il faut vider deux exécutions de l'unité de calcul?
et autre question (je sais, j'en profite): à partir du moment où on peut loger deux éxecutions dans un pipeline, pourquoi ne pas le faire? (mis à part les soucis de conflits de cache ou autre vu juste avant ce post) Je me demande si la longueur de pipeline est si importante que ça pour implémenter un HT. ou alors on peut mettre plus que deux éxecutions dans un pipeline (plutôt ça a déjà été fait?)?
Childerik
22/10/2007, 10h48
Rien ne dit que l'erreur de prédiction frappe les deux instructions. Et quelque soit le nombre d'instructions qui occupe le pipeline, on mettra le même temps à vider 31 étages, non ? En fait, je n'en sait rien, mais j'imagine que ça doit fonctionner comme ça.
Normalement, le principe de l'HT, c'est d'occuper les étages inoccupés par une seconde instruction, en parallèle avec la première instruction, ce qui donne un gain de temps.
http://www.x86-secret.com/articles/cpu/3066/3066-4.htm
D'après l'article, tout irait bien dans le meilleur des mondes possibles si le programmeur prévoit la division de la mémoire cache pour éviter qu'une instruction nouvelle efface les données en cache d'une autre instruction et provoque ainsi une baisse des perf en SMT.
Mettre plus de deux instructions dans le pipeline compliquerait encore plus la situation : tu imagines une mémoire cache divisée par 4 ou par 8 par instruction ? Avec un L1 famélique sur Netburst de surcroît :D
Fanche en cas d'erreur de prediction de branchement le flush ne s'applique qu'au flot d'instructions auquel le branch appartient. Le resultat est que quand un thread a des mauvaises predictions l'autre a plus de ressources.
Une des raisons pour ne pas le faire est que c'est complexe a implementer, et que chaque ressource doit etre partitionnee (statiquement ou dynamiquement). Le partitionnement statique coute plus de transistors (il te faut toujours un gros buffer si tu n as qu 1 thread) et le partitionnement dynamique t'amene a de nombreux scenarios de deadlock, livelock, et autres bugs qui demandent un design et une validation tres complexes.
effectivement, apparemment en cas d'erreur sur un thread, seul celui-ci est vidé du pipeline. Donc, mis à part les soucis de partage/conflits des caches et buffers, le nombre de threads dans le pipeline ne poserait pas de soucis.
Après j'ai l'impression qu'Intel mise surtout sur l'augmentation du cache L2, mais pourquoi ne pas augmenter plutôt le L1 (qui impliquerait, je pense, aussi une augmentation du cache L2)
Tiens on a repondu en meme temps.
Pour gonfler le L1 cf ce que j'ai dit hier. Prescott a gonfle le L1 de Northwood mais ca ne s'est pas passe sans heurts (perte de perf a cause de la latence sur certaines applis)
oui effectivement je viens de relire, désolé... faudrait que je me fasse greffer quelques unités de sauvegarde de contexte dans le cerveau :D
Garder une associativite "assez" elevee
Ouais, full associative power !
C'était ma contribution après 1 mois de méditation sur l'associativité des caches. On peut dire que ca aura été profitable.
OK, je repars...
disons que avec un cache fully associative la conso et le nombre de transistors necessaires augmentera du ratio (cout cellule CAM)/(cout cellule RAM), et la latence en prendra aussi un coup.
CAM = memoire addressable par contenu, wikipedia n'est pas tres detaille mais contient qq infos de base : http://en.wikipedia.org/wiki/Content_adressable_memory
OK pour la latence, par contre pour ce qui est du nombre de transistors et de la conso, on doit du coup pouvoir diminuer la taille du cache (ou ne pas l'augmenter) si on passe en fully associative.
Petite question subsidiaire sur le cache (désolé, je reviens à la charge, dans un topic différent (originellement, celui sur le K10 pour ceux qui essaient de suivre), mais toujours HS par rapport au topic :whistle:) :
Pourquoi est-ce qu'on ne substitue pas les adresses de données du programme par des adresses en cache allouées lors du decode ?
Le cache serait fully associative (dans le sens ou l'on pourrait écrire n'importe ou) et l'on disposerait de l'adresse de la donnée dans le cache, ce qui permettrait d'y accéder rapidement (pas de recherche dans la line).
oui mais dans ce cas il faut faire une transcription d'adresse et stocker l'adresse dans le cache, c'est peut-être pas si avantageux que ça
C'est deja le cas d'une certaine maniere tu stock une addresse virtuelle dans le cache et tu fais la traduction d'adresse dans une TLB.
De maniere generale il n'y a plus aucun gain visible au dela d'une associativite de 16 et les gains sont mineurs au dela de 8 (en considerant 1 seul thread), obtenir une associativite "complete" apporterait qq chose de minime aux microprocesseurs modernes (quelques pourcents en moyenne si la latence et le debit restaient les memes).
Le probleme de la solution de virtualiser une fois de plus l'espace d'adressage et que tu es force d'avoir une TLB plus complexe, en effet chaque acces au cache doit etre verifie par les TLB comme accedant a une page dans laquelle il a les droits de lecture ou d'ecriture appropries. Le traffic de coherence arrive aux caches en adresses physiques et aurait besoin d'etre traduit aussi afin de pouvoir verifier sa presence dans le cache, ralentissant de facto tout les snoops et les autres processeurs.
Une TLB plus compliquee implique une augmentationde la latence d'acces a moins que le cache soit completement virtuel (ce qui n'est plus le cas a ma connaissance depuis que les CPUs supportent le SMP pour des problemes de coherence).
Je ne pensais pas à utiliser une table de correspondance mais de substituer directement au niveau de l'instruction l'adresse d'origine par l'adresse physique en cache.
Cette adresse serait allouée lors du prefetch instruction ou du decode par le controleur de cache en fonction des disponibilités et des instructions déja chargées dans le pipe.
Le chargement de la donnée en cache a l'adresse allouée aurait lieu alors que l'instruction descend le pipe de manière à être disponible lorsque la lecture doit être faite.
La donnée ne pourrait être évincée du cache tant qu'une instruction l'utilisant serait présente dans le pipe.
Les adresses ne sont pas connues avant l'etage d'execution (sauf un cas eventuel ou tu aurais une bonne partie de l'addresse en immediat dans l'instruction) ou tu calcule l'adresse (en lisant un/des registres), c'est donc quasi impossible: tu peux bien entendu essayer de predire ce genre de choses tres en amont mais le taux de bonnes predictions est faible, tres faible.
Le plus tot pour faire la substitution c'est dans l'AGU et il faudrait que ta fonction de hashage ne prenne pas plus longtemps que l'add que tu dois deja faire pour calculer l'addresse.
Meme une analyse complexe du code a du mal a determiner si une instruction est utilisee pour produire une adresse ou une donnee etant donne qu'ils utilisent les memes instructions (certains utilisent meme lea pour des donnees). Et meme savoir si une instruction appartient au flot de calcul d'adresse ne permet pas de determiner l'adresse finale en avance.
Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.
Il y a des techniques qui essayent de predire les adresses et de transferer les donnees par des registres plutot que par le cache entre des instructions dependantes, ca s'appelle "memory renaming" et c'est a peu pres la seule technique que je connaisse qui reussisse dans certains cas particuliers a deviner une adresse a l'avance. Ca ne peut pas s'appliquer a une traduction systematique des adresses.
OK, merci pour l'explication.
Pour tenter de résumer, c'est parce que les adresses des données sont le résultat de calculs et non pas écrites en dur dans le code x86 que le problème de prédiction se pose.
un mov eax, [eax] est problématique, pas un mov eax, 00FF00EEh.
Si on pouvait avoir une bonne idee de l'adresse aussi en avance que tu le dis l'ensemble des caches de donnees des CPU actuels auraient 0 cycles de latence, on prefetcherai directement les donnees dans les registres juste avant de les utiliser.
On ne peut pas dans ce cas générer un code x86 n'utilisant que des adresses (relatives ?) écrites en dur ? (je ne me rends pas bien compte de ce que ca implique, désolé si c'est une aberration...)
Ca rendrait au moins le code enorme et diminurait les performances de maniere tres importante a moins de changer tout le cache d instruction et les decodeurs.
Je suppose que ca ne plairait pas non plus aux compilos.
Il y en a qui s'occupent sainement en attendant : http://smallcode.weblogs.us/2007/11/23/strcmp-and-strlen-using-sse-42-instructions/
Quelqu'un a essayé de SDK avec l'émulateur SSE4 ? http://softwarecommunity.intel.com/articles/eng/1193.htm
Edit : prudence sur le premier lien mais BifDefender ne me dit rien.
Childerik
12/12/2007, 15h21
Ton premier lien fait baliser mon AVG
A noter que l'emulateur est pour Penryn donc supporte SSE4.1 alors que les instructions discutees dans ton premier loin sont SSE4.2 (Nehalem only).
Donc meme sur l'emulateur Penryn le code en question ne tournera (malheureusement) pas.
En revanche quelqu'un qui voudrait absolument tester ce code aujourd'hui peut assez facilement developper des macros qui remplacent les 7 instructions SSE4.2 par une sequence d'instructions "equivalentes" (correspondant a la spec). Ca ne presente un interet que pour quelqu'un qui essayerait de tuner une appli existante sans support d'intel pour etre dispo a la release de Nehalem (l'emulateur ou un set de macro approprie etant probablement donne par Intel en NDA aux principales boites de sw).
Ton premier lien fait baliser mon AVG
Idem avec trendmicro sur mon PC du boulot.
Childerik
13/12/2007, 10h43
Je ne pense pas que ça soit un méchant script : juste un truc mal codé que certains AV croient être une petite saloperie.
Et pour finir, il faut un OS capable de distinguer une unit logique d'une physique, cf le problème soulevé y'a qques temps sur ici même :
http://www.x86-secret.com/index.php?option=newsd&nid=850
Plus on ira vers des processeurs multicores avec des hiérarchies de caches, plus l'OS devra être "renseigné" sur la structure du processeur. En dehors du cas du SMT, on retrouve aussi le problème de placer des threads qui travaillent sur les mêmes données. On a évidemment intérêt à les placer sur des cores, physiques ou logiques, qui ont un cache en commun le plus proche possible. Il y a donc clairement du travail à faire au niveau du placement/déplacement des threads sur le processeur.
En ce qui concerne l'intérêt du SMT, on peut aussi citer l'utilisation des "helper threads" qui, en tournant sur le même core, consomment peu de ressources mais permettent de déclencher les accès mémoires et donc la remontée des informations dans les caches plus tôt afin d'améliorer les performances du thread principale.
Plus on ira vers des processeurs multicores avec des hiérarchies de caches, plus l'OS devra être "renseigné" sur la structure du processeur. En dehors du cas du SMT, on retrouve aussi le problème de placer des threads qui travaillent sur les mêmes données. On a évidemment intérêt à les placer sur des cores, physiques ou logiques, qui ont un cache en commun le plus proche possible. Il y a donc clairement du travail à faire au niveau du placement/déplacement des threads sur le processeur.
En ce qui concerne l'intérêt du SMT, on peut aussi citer l'utilisation des "helper threads" qui, en tournant sur le même core, consomment peu de ressources mais permettent de déclencher les accès mémoires et donc la remontée des informations dans les caches plus tôt afin d'améliorer les performances du thread principale.
Je ne suis pas sur en fait qu'il vaut mieux que l'OS ait absolument besoin d'etre renseigne sur tous les details, je pense que c'est plus au hard de gerer ou positionner les threads pour obtenir la meilleur perf. Idealement l'OS communiquerait des indices sur les propriete des processus / threads executes comme :
- le taux de communication attendu entre les threads
- la sensibilite de l'application aux latences
- la sensibilite de l'application a la bande passante
Si l'OS n'est pas capable de connaitre ces infos, il n'y a aucune raison de lui donner le controle sur le positionnement des threads. Si il a ces infos, l'algo de scheduling va devoir changer a chaque generation pour chaque constructeur, donc autant definir une API et laisser le hardware (qui evolue toujours bcp plus vite que les OS) le controler.
il faut une API, on est bien d'accord, mais pour moi elle est pour explorer l'architecture du proc
le processeur n'a pas assez d'informations pour gérer un ordonnancement global, il ne connait pas tous les programmes qui tournent, et puis ça ferait encore des trucs crassoux à envoyer dans le processeur...
des travaux qui vont vont dans ce sens : http://hal.inria.fr/docs/00/15/45/06/PDF/main.pdf
Le processeur a beaucoup d'informations deja aujourd'hui qui sont generalement employees pour le power management uniquement, mais rien n'empeche d'etendre les API en question pour inclure des notions plus fines de performance.
Et je ne crois pas en la capacite des OS de gerer la performance efficacement, et ce principalement parce qu'un OS est developpe sur les CPUs d'hier pour les CPUs de demain avec a peu pres aucune idee de ce que seront les CPUs de demain. Et dire que les constructeurs de CPUs n'ont qu'a plus communiquer avec ceux qui font les OS est :
1 - une utopie, le secret represente des milliards pour les fabriquants de CPU, et ils ne vont pas communiquer des infos detaillees suffisament en avance pour pouvoir developper un OS dessus.
2 - impossible, au moment ou le fabriquant d'OS aurait besoin de ces infos le fabriquant de CPU ne sait pas encore suffisament a quoi ressemblera son CPU de demain (dans certains cas pas du tout meme).
3 - le power management, le CPU prend les decisions aujourd'hui (suivant les recommandations de l'OS) de la frequence a laquelle va tourner un thread, et il y a de bonnes chances pour qu'un jour le CPU sur lequel ce thread devra tourner sera decide apr le power management, ce qui enleve essentiellement toute possibilite a l'OS pour gerer la performance de maniere fine.
Bien entendu l'OS a un grand role a jouer, le CPU ignorant beaucoup de choses sur les caracteristiques des applis. Le plus simple est pour l'OS de les communiquer plutot que d'essayer de s'adapter a des algorithmes qui changent une fois par an (et pour Microsoft, en plus ca leur coute moins cher).
le processur "connaît" les processus qu'il exécute à un instant T, donc 2, 4, 8 threads
l'OS lui a une vision globale et a des informations sur la 100aine de processus lancés à un instant T
ça fait quand même une grosse différence au niveau des possibilités de réarangement de l'ordonnancement
je ne pense pas que l'OS ait besoin d'informations si précises que ça sur le processeur, il a juste besoin de connâitre les "sites" d'exécution et la "distance" entre ceux-ci
en plus, une solution niveau OS peut très bien gérer plusieurs processeurs physiquement séparés
il existe des solutions matérielles pour connecter de façon intelligente plusieurs processeurs entre eux, mais avec une solution OS on pourrait le faire avec un hardware hétérogène
Oui justement le processeur ne connait que ce qu'il execute a un instant donne, mais a cet instant il est aussi le seul qui peut resoudre le probleme d'optimisation de la dissipation energetique. Si l'OS ne lui fournit pas les informations sur les dependances des threads entre eux, la situation aboutira a une solution sub optimale d'un point de vue performance et energie.
Aujourd'hui les decisions sur la dissipation d'energie commencent a supplanter les decisions de placement de threads en terme d'impact sur les performances. Demain ce sera encore plus important.
Je ne me fait pas l'avocat d'un OS ignorant et d'un CPU qui fait tout. Comme tu le dis, c'est a l'OS de decider quels threads lancer concurrament et ca seul lui peut le faire, pour ca il a donc besoin d'un modele theorique representant les caracteristiques du processeur. En revanche une fois que les threads devant etre executes concurament ont ete selectiones, c'est au CPU de les placer le mieux possible (rien n'empeche l'OS de donner ses preferences, mais la decision finale est au CPU si on veut aboutir a une solution efficace a mon avis).
Les processeurs physiquements separes, ne sont effectivement pas power manages ensemble aujourd'hui, mais cela ne va plus durer tres longtemps.
au final c'est toujours le processeur qui aura la main, et c'est vrai qu'on ne va pas rendre la main à l'OS à chaque fois qu'il se passe quelque chose
donc effectivement, peut être que l'OS pourrait placer les threads sur une abstraction du processeur, et le processeur après exécute tout ça en respectant au mieux ces contraintes
Dans le cas "simple" où on a un seul processeur physique, il est clair que le processeur est positionné de manière optimale pour prendre les décisions de placement des threads.
Mais dès que l'on a plus d'un processeur physique, on commence à multiplier fortement les cas possibles:
*2 p4 avec HT activé: problème de positionnement des threads vis-à-vis des ressources de calcul, mais aussi des accès au cache.
*2 quads de type "Core": problème d'optimisation des accès aux caches, et problème d'optimisation de l'énergie
*2 opterons avec un seul banc mémoire: problème d'optimisation de la latence mémoire
*2 opterons avec 2 bancs mémoire: problème d'optimisation de la latence mémoire, incluant un problème de répartition des données entre les bancs mémoire
Avec un tout petit peu d'imagination, on peu aussi envisager les cas hypothétiques suivants:
*Larabee pourrait être un GPU capable aussi d'exécuter du x86: Dans ce cas, problème de placement des threads entre de processeurs aux caractéristiques fortement différentes
*Utilisation d'un CPU very low power pour des besoins d'économie d'énergie en plus du CPU "habituel". Même problème.
Il est clair que l'on peu envisager pas mal de cas, dont certains ne sont pas si farfelus que cela. Dans ces conditions, ce type de problème peut vite devenir non trivial, et surtout comportant des paramètre qui ne sont pas forcément prévus dès la conception des tous les processeurs utilisés dans le système.
Dans ces conditions, j'ai du mal à voir comment on pourrait déléguer tous ces arbitrages au CPU (ou aux CPU).
Pourquoi ne pas alors avoir un schéma inverse, où les processeurs fournissent des infos de monitoring détaillées au système d'exploitation, afin que ce dernier prenne les décisions de placement des threads pour optimiser une combinaison de performance et consommation énergetique? Cette solution me semble la plus flexible (bien que dans certains exemples il est possible que j'ai un peu forcé la flexibilité au delà du raisonable)
Dans ces conditions, j'ai du mal à voir comment on pourrait déléguer tous ces arbitrages au CPU (ou aux CPU).
A partir du moment ou les cpus sont sur le meme socket c'est trivial. C'est plus complique si ils sont sur des sockets differents. Le probleme de donner la main a l'OS est la granularite a laquelle il peut agir est generalement trop importante (plusieurs milisecondes dans le meilleur des cas alors que pour le cpu reagir en microsecondes est simple). Le CPU a de nombreuses infos sur sa performances actuelles, que l'OS peut acceder mais prend du temps, beaucoup de temps a utiliser.
Pourquoi est ce que ce n'est pas l'OS qui gere le throttling des CPUS quand ils depassent le TDP ? Tout simplement parce que le cpu serait brule depuis longtemps si c'etait le cas. Il en est de meme pour le power management de maniere generale.
Si tu as 4 threads sur un quad core qui supporte HT, rien ne t'empeche d'en scheduler 1 par core et de voir le power dissipe, et au final de les scheduler sur 2 cores +2 threads HT et la consommation d'energie est potentiellement reduite a un point tel que ca permet de tourner a des frequences bien plus elevees et de gagner de la performance au final... Le temps que l'OS se rende compte de ce genre de choses l'application est dans une phase differente...
Dans toutes les config qu tu liste le hardware aura moins de difficultes a prendre des decisions que l'OS. Surtout que l'OS qui devrait prendre les decisions est vista et que la moitie des archis dont tu parle, Microsoft n'avait aucune idee de ce qu'elles seraient quand Vista a ete developpe.
Donc au final je n'ai uncun mal a voir comment ces arbitrages pourraient etre donnes au CPU, mais je ne vois pas comment l'OS pourrait le gerer...
Je ne pense pas que ça soit un méchant script : juste un truc mal codé que certains AV croient être une petite saloperie.
Non en fait :sad: http://smallcode.weblogs.us/2007/12/15/trojan-attack/
J'ai téléchargé Antivir pour le coup, il m'a trouvé une saloperie mais je sais pas si c'est lié (ça faisait super longtemps que mon PC n'avait pas vu un antivirus).
il y a quand même déjà quelques mises en oeuvre, dont l'article que j'ai cité plus tôt :rolleyes:
A partir du moment ou les cpus sont sur le meme c'est plus complique si ils sont sur des sockets differents.
Bien que je te soutienne dans tes idées l’arrivée de CSI ne va-t-elle pas simplifier la communication socket to socket (au moins en couple)?
Ou en tous cas elle pourrait permettre d’envisager une solution pour des cpus sur des socket différent ?
Edit :
A la vue des bandes passantes possibles et de ces niveaux d’abstraction peut on se permettre d’imaginer une sorte de gestion en interne dans ce mini réseau ?
Bien sur il y aurait une perte profonde en capacité directe mais elle pourrait être renflouée par une meilleure efficience.
thread sur le forum RWT
http://www.realworldtech.com/forums/index.cfm?action=detail&id=85890&threadid=85890&roomid=2
Franck@x86
02/01/2008, 18h16
Rien à voir, mais c'est l'anniv de Fefe aujourd'hui !
bon anniv, et on te souhaite plein de succès ... de caches (huhu, ça c'est vraiment une bonne grosse blague d'informaticien !!)
Minuteman
02/01/2008, 18h32
Putain, j'ai pouffé de rire en lisant ça, je l'avais jamais entendue :p Bon anniversaire :)
En plus, il s'est mis sur son 31, huhuhu :p
Rien à voir, mais c'est l'anniv de Fefe aujourd'hui !
bon anniv, et on te souhaite plein de succès ... de caches (huhu, ça c'est vraiment une bonne grosse blague d'informaticien !!)
C'est clair :D
Joyeux anniversaire quand même, Fefe ;)
D'ailleurs, ou est fefe ?
Ils acceptent de vous donner des vacances quand même ? J'en connais en ce moment qui sont aux travaux forcés... :)
Bon anniversaire avec un peu de retard. Et pis bonne année bonne santé et tout et tout
Joyeux anniversaire avec un peu de retard aussi.
Franck@x86
03/01/2008, 12h46
Encore qques éléments sur le Nehalem :
http://www.hkepc.com/?id=568
NitroG42
03/01/2008, 12h53
Encore qques éléments sur le Nehalem :
http://www.hkepc.com/?id=568
Bon, je parle pas chinois, mais d'après ce que j'ai compris, ca a l'air assez sympa pour les serveurs quand même, surtout pour les serveurs multi-cpu, après je doute que les perfs soient aussi intéressante avec un seul proc.
Par contre 2009...
on a le temps de voir venir.
et là j'ai un petit fou-rire, "AMD 4x4".
aahaha.
10-25% d'amélioration en single thread... C'est dans l'air du temps. le K10 est pile au milieu avec 17%.
Mais plutôt sur l'IPC ou plutôt sur la fréquence ?
Je me rappelle de rumeurs qui disaient que Nehalem serait un mix de Core2/Conroe et de Netburst (ce qui expliquerait le retour de l'HT ?). Si oui, ce serait plutôt la fréquence qui monterait ?
J'aime bien le "Simultaneous SMT" :D
Merci a tous, oui j'etais en vacances ;)
Franck@x86
03/02/2008, 19h43
http://www.xtremesystems.org/forums/showthread.php?t=175737
Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.
Si tu postes ce screen c'est que tu considères qu'il est crédible, je suppose. Rien qui pourrait penser que c'est un fake ?
http://www.xtremesystems.org/forums/showthread.php?t=175737
Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.
C'est vrai que cette hiérarchie est intéressante... pour ne pas dire surprenante. J'ai hâte de voir ce que ça donne en pratique.
http://www.xtremesystems.org/forums/showthread.php?t=175737
Pas de bench hélas.
Il est intéressant de noter l'insertion des "petits" L2 entre les L1 et le gros L3 partagé entre les 4 cores.je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.
je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.
Les magiciens a employer ne seraient pas pour la latence, mais pour la bande passante de ton L2 geant qui se prendrait les miss de 8 threads sur 32K*4 de cache L1. Les gros caches n'ont en general qu'un seul port d'acces, et si tu multiplies les ports d'acces ca a aussi une bonne tendance a multiplier la surface consommee et le power (et a ajouter un peu de latence).
J'oubliais, inserer un "petit" L2 entre L1 et L3 partage augmente la latence de ce L3 de maniere significative, sauf si les access sont faits en parallele (mais dans ce cas la il n'y a plus d'effet de reduction de bande passante vers le L3).
Franck@x86
04/02/2008, 10h45
Si tu postes ce screen c'est que tu considères qu'il est crédible, je suppose. Rien qui pourrait penser que c'est un fake ?
Non ce n'est pas un fake, mais cela ne veut pas dire que les infos affichées sont correctes. J'ai déjà eu confirmation que le L1D de 16Ko est un bug, la taille réelle est de 32Ko (mêmes L1 que le C2D donc). Les autres infos des caches sont correctes. La fréquence d'horloge semble également correcte (2133 MHz mesurés et 2.13GHz dans le name string). Quant au FSB, je ne peux pas dire, il semble cohérent avec le coeff et la fréquence interne, cela dit ça peut très bien être un bug.
je trouve que cette archi sent moins bon que très gros L2 partagé et pas de L3... Ils ont qu'à embaucher des magiciens pour gérer la latence.
Je cite Fefe :
"Quand un cache devient trop lent on a tendance a intercaler un cache plus petit et plus rapide avant celui-ci (cela devient donc un cache de niveau 2)."
Nehalem applique cette règle à la lettre.
A la différence du Phenom pour lequel AMD a ajouté un L3 derrière les L1 et L2 hérités de l'A64, le Nehalem s'est vu insérer le L2 entre des L1 qu'on sait rapides, et un L3 partagé entre quatre cores, avec toutes les conséquences que cela implique sur sa BP.
Ce choix ne me semble pas incohérent, loin s'en faut. Ma seule interrogation c'est le power, parce que tous ces caches ça doit pomper. Reste à déterminer si le L3 est "full speed"...
Les magiciens a employer ne seraient pas pour la latence, mais pour la bande passante de ton L2 geant qui se prendrait les miss de 8 threads sur 32K*4 de cache L1. Les gros caches n'ont en general qu'un seul port d'acces, et si tu multiplies les ports d'acces ca a aussi une bonne tendance a multiplier la surface consommee et le power (et a ajouter un peu de latence).
J'oubliais, inserer un "petit" L2 entre L1 et L3 partage augmente la latence de ce L3 de maniere significative, sauf si les access sont faits en parallele (mais dans ce cas la il n'y a plus d'effet de reduction de bande passante vers le L3).
et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?
Franck@x86
04/02/2008, 11h10
et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?
Non c'est un choix architectural, au sens que le NHM "serait" capable de tels accès parallèles.
oui quand je parlais de probabilités, c'est les probabilités qu'intel fasse ce choix selon l'estimation individuelle subjective de chacun.
Personnellement, j'en doute, car quelque part, ça fait une réserve de performances en cas de besoin (concurrents devenus performants par exemple)
Franck@x86
04/02/2008, 11h32
ah oui pardon j'ai compris de travers.
et les probabilités que les accès se fassent en parallèle sur nehalem, vu le peu qu'on en sait aujourd'hui ? Elevé/moyenne/très faible ?
Ca depend de ton application bien sur, mais une des proprietes fondamentales des acces memoire est qu'ils arrivent en burst et non pas de maniere uniforme (les prefetchers ne sont pas pour rien dans se phenomene).
Dans une platforme mono thread, on peut avoir un cache avec une bande passante raisonable (tous les L2 intel recents peuvent effectuer un lookup tous les 2 cycles), et quand un burst arrive on penalise la latence de maniere moderee: en effet le nombre de miss qu'un core peut emettre en parallele avant de stall est assez limite (<10). Donc avec un peu de buffering ton cache reussit a servir toutes ces requetes sans trop de problemes, avec une penalite de quelques cycles lorsque tu arrives a la fin du burst, mais vu qu'en general les requetes a la fin d'un burst sont des prefetch, cela a peu ou pas d'impact sur les performances.
Bien entendu la grande majorite du temps cette bande passante sera la pour rien... Maintenant, tu multiplies le nombre de thread par 8. Que se passe t'il ?
Tu as en moyenne largement la bande passante pour servir tes applis, enfin dans la majorite des applications, il y en a tout de meme un certain nombre ou tu commenceras a saturer, mais suffisament peu pour que en moyenne cela ne semble pas etre un probleme majeur.
Donc pourquoi ne pas partager ce cache entre plus de monde ? deja, il va falloir pouvoir bufferiser 8 fois plus de requetes (allez 4x si c'est du SMT et que la ressource qui permet de track les miss en parallele est partagee). Cela fait de gros (tres gros?) buffers. Qui plus est cela augmente aussi de maniere tres significative le temps d'attente des requetes, surtout quand un core arrive alors qu'un autre vient de remplir le buffer geant devant ton cache.
Tu peux decider d'implementer un mecanisme out-of-order dans ton buffer pour essayer de donner une plus grosse priorite a certaines requetes, mais pour ce faire tu dois sacrifier de la latence pour tout le monde, et aps mal de transistors.
Donc au final, meme si un tel L2 pourrait fournir en moyenne une bande passante apropriee, il va etre sature extremement frequement, des lors que les differents thread auront des burst proches les uns des autres dans le temps. En pratique c'est tres frequent (en opposition au cas assez rare ou la bande passante moyenne sera proche du pic), et ce surtout dans les applications orientees serveur, ou le taux d'echec dans le L1 est particulierement eleve, et les prefetcher particulierement efficaces a generer du traffic inutile (quand actifs). Sur les applications client c'est un peu plus rare, et si le core n'etait pas destine a etre integre a des clients et serveurs, le choix serait potentiellement plus discuttable (ca ne le rend pas mauvais pour autant).
Question consommation d'energie, le taux d'activite moyen des caches est generalement faible donc le power "actif" est assez limite, et dans le cas ou ce taux d'activite serait tres eleve, en pratique le reste du CPU passe son temps a attendre la memoire donc consomme peu (donc la somme power CPU + power cache reste faible).
Il reste donc juste ce qui est l'essentiel de la consommation d'un cache: le leakage. Ce leakage est proportionnel a la surface occupee (donc la taille de tes caches), a supposer que tous tes caches operent a meme frequence et voltages, 4x256k de L2 en supplement de 8M vont t'ajouter 13% de power de leakage, a supposer que la surface investie dans ces caches n'ait pas ete investie dans un 9eme MB. En revanche avoir a supporter moins de bande passante te permet potentiellement d'utiliser un L3 fonctionnant a une frequence plus basse et un voltage plus bas, ce qui a un effet non negligeable sur le leakage en question.
Franck@x86
04/02/2008, 12h59
4x256k de L2 en supplement de 8M vont t'ajouter 13% de power de leakage.
ça c'est de la précision ! :p
Y'a donc de fortes chances que le L3 utilise une fréquence et une tension (et non pas un voltage :rolleyes:) différentes de celles du reste du CPU. Enfin ça semblerait logique, ne serait-ce que pour un meilleur contrôle de l'enveloppe thermique du CPU.
ça c'est de la précision ! :p
1M/8M =12.5% :p
Et desole, mes reponses sont bourrees d'anglicismes...
Y'a donc de fortes chances que le L3 utilise une fréquence et une tension (et non pas un voltage :rolleyes:) différentes de celles du reste du CPU. Enfin ça semblerait logique, ne serait-ce que pour un meilleur contrôle de l'enveloppe thermique du CPU.
Si c'est le cas, cela coute de la latence supplementaire pour changer de domaine de frequence lors d'un acces au cache (et c'est une latence loin d'etre negligeable puisqu'intervenant 2x par acces).
Ca depend de ton application bien sur, mais une des proprietes fondamentales des acces memoire est qu'ils arrivent en burst et non pas de maniere uniforme (les prefetchers ne sont pas pour rien dans ce phenomene).
[...]
Tu peux decider d'implementer un mecanisme out-of-order dans ton buffer pour essayer de donner une plus grosse priorite a certaines requetes, mais pour ce faire tu dois sacrifier de la latence pour tout le monde, et pas mal de transistors.
Pourquoi le prefetch génère t'il des pics ? Le mécanisme de découverte se fait par bloc, et non pas de manière continue dans le temps ? (en fonction de ce qui il y a dans le L1I ?).
Est-ce que la logique d'OOO/tri selon priorité dont tu parles à un niveau buffer ne devrait pas être de la responsabilité du prefetcher, de même que temporiser parfois afin d'éviter les "burst" ?
Surtout que comme tu dis, ce n'est "que" du prefetch. Les demandes de chargement liées à un miss sont-elles prioritaires (ca implique de pouvoir les reconnaitre).
(désolé hein, il doit y avoir un peu de tout et surtout du n'importe quoi... :))
Un prefetcher a une periode pendant laquelle il detecte des patterns d'acces et une periode ou il envoie des prefetchs. Sachant que dans la majorite des cas il realise "trop tard" sur quelles adresses envoyer des prefetchs, le plus tot est le mieux, d'ou l'aspect burst des acces les aux prefetch.
Cis dessus je dis "trop tard", et c'est dans le sens ou "a l'heure" pour un prechargement veut dire que le core va demander la donnee une fois que le prefetcher l'a ramene dans un cache, et non pas pendant que le prefetch est en cours (dans ce cas la il ne masque qu'une partie de la latence). Si je veux essayer de me rapprocher de "a l'heure" il faut que je specule plus et que j'envoie des prefetch de plus en plus tot, donc lorsque j'ai detecte un pattern qui me laisse deviner le prochain acces j'envoie non pas un prechargement mais plusieurs pour tenter d'arriver plus en avance. Je viens de decrire la creation d'un burst :).
Il y a d'autres raisons a l'aspect burst des acces memoire, les prefetcher etant surtout un amplificateur. Le premier est que malgre l'OOO dans le core et le "memory disambiguation" on a souvent des requetes memoires qui finissent par bloquer les autres load dans le pipeline d'etre traites. Lorsque cet acces (a longue latence) est servi, il debloque un groupe d'acces qui vont arriver en burst dans le sous systeme memoire, un de ces acces ayant de nouveau une grande chance d'en bloquer un paquet dans le pipeline.
C'est un peu comme l'effet acordeon dans les embouteillages...
Sinon les prefetchers sont deja "temporises" dans le sens ou les vraies requetes sont prioritaires sur les prefetch. En revanche il n'y a pas de raison d'attendre si on a predit qu'une adresse allait etre utilisee, la demander le plus tot possible est le mieux.
OK merci.
Par contre, je ne suis pas sur d'avoir compris le lien entre le fait de prédire tôt et le nombre de préchargement.
Si je veux essayer de me rapprocher de "a l'heure" il faut que je specule plus et que j'envoie des prefetch de plus en plus tot, donc lorsque j'ai detecte un pattern qui me laisse deviner le prochain acces j'envoie non pas un prechargement mais plusieurs pour tenter d'arriver plus en avance.
C'est parce que :
- une fois détecté un pattern, celui-ci permet de connaitre d'un coup plusieurs chargements à venir, et du coup on envoie les préchargement tous ensemble afin d'avoir une latence minimale, ou
- parce que plus on fait la prédiction tôt, moins le pattern est précis, et plus on a de chargements hypothétiques et donc de préchargements à faire si on veut être sur de tomber juste
Les 2:
- le premier parce que un prefetcher va detecter un stream et donc lancer les prefetchs de ce stream
- le second parce que tu as multiples prefetchers par core et que chacun d'entre eux va essayer de predire les acces et multiplier les prefetch en esperant que l'un d'entre eux aura raison.
Franck@x86
04/02/2008, 16h35
Après explications de Fefe voici une traduction Fefe vers langage usuel :p
Partons donc de l'hypothèse que le NHM fût composé de 4 cores (8 threads avec SMT) et d'un gros L2 partagé entre les quatre cores. Dès lors qu'une majeure partie des 8 threads sollicite de façon soutenue le sous système de cache, se pose le problème au L2 de répondre à chacun le plus rapidement possible. La solution en première instance consiste à multiplier les ports d'accès au cache L2, càd de passer de 1 port à 2, ou mieux 4 ports. Impossible, car un cache à 4 ports aurait une surface entre 2 et 3x plus importante qu'un cache simple port.
D'où l'idée d'insérer des L2 pour éviter l'étranglement du L3. Comment ?
Supposons que chacun des L2 ait un taux d'échec de 50% (c'est beaucoup). Ca veut dire que 50% des requêtes sont gérées par le L2, et non par le L3. Ca le soulage donc de moitié les requêtes qui arrivent au L3. Si avec 1 port le cache partagé peut alimenter 2 cores sans pb, avec les L2 entre deux il peut en alimenter 4. Et ça c'est puissant.
Bon j'espère que c'est plus clair ainsi.
Pour les accès L2/L3 en parallèle : en fait ça ferait perdre tout l'intérêt de ce qui vient d'être expliqué, donc NHM ne le fait pas. Donc, la présence du L2 augmente quelque peu la latence d'accès au L3.
D'où l'idée d'insérer des L2 pour éviter l'étranglement du L3. Comment ?
Supposons que chacun des L2 ait un taux d'échec de 50% (c'est beaucoup). Ca veut dire que 50% des requêtes sont gérées par le L2, et non par le L3. Ca le soulage donc de moitié les requêtes qui arrivent au L3. Si avec 1 port le cache partagé peut alimenter 2 cores sans pb, avec les L2 entre deux il peut en alimenter 4. Et ça c'est puissant.
Donc ça sent le 8 cores dual-die...
Donc ça sent le 8 cores dual-die...
On ne change pas une équipe qui gagne... :p
PeGGaaSuSS
23/02/2008, 22h54
Photos d'un Nehalem et de sa mobo : http://www.xtremesystems.org/forums/showthread.php?t=178009
Et le cul : http://www.xtremesystems.org/forums/showthread.php?t=177122
newbie06
25/02/2008, 10h44
Un slide d'une presentation officielle : spec rate int/fp (http://img254.imageshack.us/my.php?image=nehalemtv6jw6.jpg)(Ref: Ace's hardware (http://aceshardware.freeforums.org/sun-intel-slides-have-nehalem-performance-projections-t385.html)).
Comme d'habitude ca peut etre un fake.
[Warning : je ne connais pas grand-chose aux chips serveurs, donc je raconte sans doute des aneries.]
J'avoue ne pas bien comprendre (chiffres extraits un peu au pif du site SPEC) :
- la ref de 1 est donnee pour un 5160 ; c'est un dual core qu'on peut trouver en dual socket ; SPEC int rate dans les ~60 pour quatre coeurs et SPEC fp rate ~45
- le 5365 a un SPEC int rate dans les 60 pour 4 coeurs et dans les 115 pour 8; SPEC fp rate dans les 37 (4) et dans les 62
Or sur le slide ci-dessus, le 5365 serait 1,5 x plus rapide que le 5160. A nombre de coeur egal, ou en doublant le nombre de coeurs, je n'arrive pas a voir le rapport.
En tout cas les chiffres du Nehalem sont clairement en 8 coeurs.
Je crois qu'il va y'avoir qq'un qui va morfler chez Sun ;).
Photos d'un Nehalem et de sa mobo : http://www.xtremesystems.org/forums/showthread.php?t=178009
Et le cul : http://www.xtremesystems.org/forums/showthread.php?t=177122
C'est vrai que du coup ça ressemble beaucoup à une carte pour Opteron.
Je me réjouis de voir les perfs. Ca va faire très mal à AMD qui du coup n'auras plus vraiment un plus dans le monde server (les controleurs mémoire des Opterons sont appréciés pour les machines qui ont un nombre très élevé d'I/O)
La question qui a rien à voir : c'est quoi le chip video? Rien qui ressemble à un Volari z7 (une daube infame), ou ATI ES1000 sur un bus PCI 32bits...
PeGGaaSuSS
26/02/2008, 21h05
C'est un proto Intel, ca doit être du Intel j'imagine...
Jusqu'à présent, il n'y a pas de gma intégré dans les chipsets serveur d'Intel...
J'ai un serveur Intel en test, c'est un ATI ES1000 pour le vga... (donc de l'AMD au sain même d'une config full Intel)
PeGGaaSuSS
26/02/2008, 21h15
Arf, j'ai toujours cru que c'etait les constructeurs de mobo qui chopait des vieux chips (pas idiot, moin cher, plus fiable).
Quoi qu'en fait, si les mobos sont une section séparé des CPU/chipset (chez Intel j'entends), ils peuvent faire ce qu'ils veulent...
Les mobos Intel ont parfois des choix bizarre la ou ca aurait pu être du full Intel!
Leak d'un bench de Nehalem sur SPEC fait par Sun :
http://www.matbe.com/images/biblio/divers/000000068526.png
image de http://www.matbe.com/actualites/imprimer/32471/
http://blogs.zdnet.com/Ou/?p=1025
newbie06
12/03/2008, 11h01
http://blogs.zdnet.com/Ou/?p=1025
Un truc me chiffonne (en dehors du fait des extrapolations faites pour obtenir les scores absolus par rapport aux scores relatifs du transparent de Sun) : le gars pretend qu'une partie du gain provient du SMT ; si c'est le cas, le score du Nehalem serait pour un 8 threads (SMT 2 x Nehalem EP 4 coeurs).
Si c'est bien le cas, on peut dire que cette comparaison ne tient plus la route.
Vu que le slides contient des comparaisons entre dual core et quad core, et donc compare la perf/socket, cela ne me semblerait pas anormal si ils comptaient SMT dans leurs chiffres (et ca expliquerait au moins en partie les perfs tres hautes que montre ce graphe).
newbie06
12/03/2008, 17h29
Et la consequence est : on ne peut rien deduire de cette comparaison sauf que c'est impressionnant pour un socket :)
Si tu consideres un efficacite du SMT a la Prescott =~ 20%, ca te donne dans les 130-140 a une frequence inconnue, qu'on peut estimer similaire aux autres membres de la famille core (meme si differente il est peu probable que ce ne soit pas marginal), c'est a dire toujours plus haut que le shangai montre dans les 120.
IMO ca n'a plus rien d'impressionant (ca reste bon). Apres pour ce qui est des conclusions a tirer ca depend de ce qui t'interresse. Si c'est les performances sur des jeux modernes de Nehalem, effectivement je doute que ce graphe puisse repondre a quoi que ce soit (par exemple le P4 etait tres bon a SPEC et ca ne se traduisait pas en un avantage sur les jeux).
newbie06
13/03/2008, 08h48
(par exemple le P4 etait tres bon a SPEC et ca ne se traduisait pas en un avantage sur les jeux).
Ce n'est pas necessairement une caracteristique de l'architecture, ca peut aussi venir d'un compilo tellement tune pour SPEC que la compilation du reste ne presente pas de bons resultats.
J'ai souvent eu des discussions sur icc vs gcc, des gens pretendant qu'icc etait largement superieur a gcc. J'imagine que sur SPEC icc baffe mechamment gcc. Mon experience est que les gains sont en general de quelques % ("quelques" < 5%) dans un sens ou l'autre (pour des programmes deja tunes niveau C).
icc est en general en avance pour la sortie d'optimisations correspondant aux archis des derniers microprocesseurs. La vectorisation SSE a ete disponible en premier sur icc dans mes souvenirs, mais aujourd'hui ce n'est plus un avantage parce que la majorite des compilateurs le font. L'architecture core/phenom n'a pas introduit de changements majeurs du point de vue du compilateur (par rapport a P6/banias/dothan/K8, il n'y a guere qu'a realigner le code pour des decodeurs 4-wide).
icc n'est pas vraiment meilleur que gcc sur les processeurs actuels, je suis d'accord, en pratique il est moins bon car il compile moins de codes que gcc (la compatibilite a ete amelioree mais ce n'est pas encore a 100%). Sur des benchmarks etablis il y a probablement un peu plus de tuning. gcc aussi est tune sur SPEC, mais je suppose qu'il y a tout de meme moins d'efforts faits que pour icc (AMD publie ses resultats SPEC en utilisant icc en general). Sur des gros codes j'ai vu 5 a 10% de perf pour icc avec PGO (rien de scientifique dans cette phrase), et l'effort necessaire a reussir a compiler ce code avec icc ne valait le coup que parce qu'on fait tourner des 10aines de milliers de process avec ce code.
Sinon , une fois mises de cote les optimisations specifiques des compilos pour SPEC, la plupart des programmes executes sur nos PC ont des caracteristiques tres differentes de SPEC. SPECFP rate a une tendance a etre limite par la bande passante memoire de la platforme alors que c'est le cas de tres peu d'applis client, SPECInt est a l'inverse extremement sensible a la prediction de branchement et a la taille du cache, bien plus que les jeux/encodeurs videos/logiciels de compression (peut etre autant que office, mais ce n'est pas comme si la performance sous office interessait encore grand monde).
newbie06
18/03/2008, 08h48
Puisque c'est le calme plat dans le secteur un petit lien :
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=3264&p=2
Reflexions apres lecture :)
Franck@x86
18/03/2008, 20h12
Première remarque à chaud : pkoi M. Anand prend-il des photos de son écran au lieu de faire des copies d'écran ?
newbie06
18/03/2008, 20h45
Première remarque à chaud : pkoi M. Anand prend-il des photos de son écran au lieu de faire des copies d'écran ?
Il y était, il se la pète :p
Ça fait plus authentique :p
Childerik
18/03/2008, 22h14
C'est pour démontrer la puissance de son reflex 27 mégapixels avec supermacro premium :p
PeGGaaSuSS
19/03/2008, 01h47
Il avait oublié sa clef USB ? :p
Les slides : http://download.intel.com/pressroom/archive/reference/Gelsinger_briefing_0308.pdf
Tic,Toc,blabla next....: http://www.intel.com/pressroom/archive/reference/whitepaper_Nehalem.pdf
Franck@x86
20/03/2008, 11h45
Première CM Bloomfield :
http://www.xtremesystems.org/forums/showthread.php?t=181181
newbie06
31/03/2008, 08h33
Les paris sont ouverts : http://realworldtech.com/forums/index.cfm?action=detail&id=88747&threadid=88747&roomid=2
:p
newbie06
03/04/2008, 09h30
Enfin des infos : http://www.realworldtech.com/includes/templates/articles.cfm?ArticleID=RWT040208182719&mode=print
Il detaille un peu les relations d'inclusivite/non inclusivite entre les caches :). C'est Franck qui va etre content.
newbie06
03/04/2008, 20h21
Il detaille un peu les relations d'inclusivite/non inclusivite entre les caches :).
Ca sent l'optim à la normande :
The L2 cache is neither inclusive nor exclusive with respect to the L1D cache. Like the Core 2, Nehalem can transfer data between the private caches of two cores, although not at full transfer rates.(Il est pas beau mon piège pour obtenir des infos ? :p).
C'est Franck qui va etre content.Il bosse chez Intel ?
Ca sent l'optim à la normande :
(Il est pas beau mon piège pour obtenir des infos ? :p).
Il bosse chez Intel ?
Non mais il aime les histoires de cache inculsif exculsif :).
C'est pas de l'optim a la Normande c'est de l'optim a la Corse! Quand tu evicte qq chose du L2 du core 2 il ne va pas aller s'emmerder a snooper/invalider les L1 qui pourraient avoir une copie pour maintenir l'inclusion.
Non mais il aime les histoires de cache inculsif exculsif :).
C'est pas de l'optim a la Normande c'est de l'optim a la Corse! Quand tu evicte qq chose du L2 du core 2 il ne va pas aller s'emmerder a snooper/invalider les L1 qui pourraient avoir une copie pour maintenir l'inclusion.et pour la cohérence ?
Si 'autre core a besoin de l'info il faut qu'il tape en ram c'est ça ?
et pour la cohérence ?
Si 'autre core a besoin de l'info il faut qu'il tape en ram c'est ça ?
Le probleme de la methode corse est que ca force a snoop a chaque lookup du L2. Tu ne vas pas rechercher la donnee en RAM mais dans le bon cache. Par contre tu consommes bcp de bande passante a snoop.
http://www.tgdaily.com/content/view/36758/135/
Plus de CPUs pour remplacer le GPU ? Mmm ca ressemble a du marketing agressif...
newbie06
05/04/2008, 15h52
Ouai et ça a du faire plaisir aux équipes qui bossent sur Larrabee :p
http://www.tgdaily.com/content/view/36758/135/
Plus de CPUs pour remplacer le GPU ? Mmm ca ressemble a du marketing agressif...
Même si c'est pas mal de marketing, je suis assez d'accord avec Fosner. DirectX/OpenGL sont vraiment devenu complexes et se détachent de plus en plus d'un modèle de programmation cohérent. Ca ressemble de plus en plus a un amat de solutions ad'hoc!
Cette semaine une vidéo à fait parler d'elle en illustrant les fonctionnalité apportés par DirectX10.1. Une des ces fonctionnalités utilisées à outrance est le rendu vers plusieurs cube map. Vas y que je te rajoute ça avec toute sa spec et qd ça peut être utilisé ou non, avec quel filtrage, quel état du pipeline, quel antialiasing, quel support est requis etc. Bref une fonctionnalité qui peut paraitre bien étrange pour quelqu'un qui code sur CPU (en se détachant de la spec des API) puisque lui il n'a pas eu l'idée qu'une Cube map ça devait être particulier (pour lui tout est un void*). La seule notion que je conaisse qui se rapproche de cette prog moins contrainte sont les Buffer Object d'OpenGL. (Un buffer object peut stocker n'importe quoi, Pixels, Textures, paramètres, Vertex etc.)
Bref tout ça pour dire que la prog sur CPU est qd même bien plus simple/souple. Par exemple, sur CPU, la notion de shader à la DX/OGL n'a pas lieu d'être en l'état puisque tout est programmable (Naïvement sur CPU, un shader = code ou milieu d'un boucle for). Le seul avantage des shader ala API graphique, c'est leur modèle de prog parallèle vraiment puissant (puisqu'invisible).
Puisque le GPU tend vers le calcul de plus en plus général et que le CPU tend à pouvoir accélérer du graphique ça ne me semble pas idiot de penser qu'a terme tout ça va s'unifier et qu'on aura donc plus d'API obscure ni de Proc dédié.
Sweeney soulignait dernièrement que le rendu soft était sans doute l'avenir (vu qu'il le dit depuis bientôt 5 ans ça atténue son impact). Je pense qu'il n'a pas forcément tord et qu'à terme, les CPU avec de plus en plus de cores vont pouvoir être utilisés pour avoir des très bonnes perfs en rendu soft et ce sans les limitations des API. Il faut bien comprendre que le rendu sur CPU n'a aucune limitation conceptuelle. Pas besoin d'attendre le matos et la spec qui va avec pour pouvoir profiter de tel ou tel algo.
Je suis d'accord avec toi que la 3D a besoin d'un retour vers un model de programmation plus souple. J'ai eu l'impression que les GPUs essayaient d'aller dans cette direction mais ils ne semblent pas encore tres pres. Le probleme est qu'il y aura forcement de la performance sacrifiee sur l'autel de la simplicite de programmation, et jusqu'a maintenant la performance etait ce qui faisait vendre des GPUs.
Le jour ou un CPU a assez de puissance pour permettre un rendu soft des applications du jour avec une penalite de performance raisonable pour un cout comparable, il est possible de voir la tendance s'inverser (le graphique revenir vers le CPU). En revanche le predire pour demain c'est etre un peu presomptueux quant au succes de Larrabee (puisque c'est a priori de ca dont il parlait sans le dire).
newbie06
06/04/2008, 17h56
Mouai... La roue de la metempsychose : le dédié c'est le mal, utilisons des trucs plus standard ; et dans 10 ans (voire moins), ralala il faut spécialiser ce machin, c'est pas assez efficace sur du standard :p
Mon point de vue sur le parallèle qui commence à devenir massif (OK, on est loin d'une Connection Machine, mais 80 coeurs ça peut se qualifier de massif) je l'ai déjà exprimé : il nous manque un langage adapté. Et il faut aussi rééduquer les programmeurs, moi le premier.
Si les CG font plein de trucs en parallèle c'est qu'intrinsèquement le problème est parallèle, même si les API ne le montrent pas forcément.
Quant à DX/OpenGL, j'ai l'impression que c'est le concept de la rasterization qui a été tellement poussé dans ses limites qu'on en est arrivé là. Et que je te rajoute un bidule parce que la CG elle sait faire du cube mapping, et que je te rajoute un truc parce que le mec de ma R&D il m'a fait voir un truc qui déchire sa race et qu'il le faut absolument sinon on va se faire bouffer par la concurrence.
Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.
Il y a un autre aspect qui plaide en faveur du processeur dédié : le rendement énergétique. On peut dire ce que l'on veut un dédié est toujours plus efficace, sauf si on commence à l'utiliser pour autre chose que ce pour quoi il a été conçu :p
Je suis d'accord avec toi que la 3D a besoin d'un retour vers un model de programmation plus souple. J'ai eu l'impression que les GPUs essayaient d'aller dans cette direction mais ils ne semblent pas encore tres pres. Le probleme est qu'il y aura forcement de la performance sacrifiee sur l'autel de la simplicite de programmation, et jusqu'a maintenant la performance etait ce qui faisait vendre des GPUs.
Oui. Il faudra sans doute sacrifier les performances, car le matériel deviendra moins spécifique (sauf pour quelques unités) mais cette perte de performance pourra être sans doute compensée (toute proportions gardées) par un accès au hard moins masqué (ce qui se fait par exemple sur PS3). Par exemple, outre la facilité de manipulation, ne serais ce que considérer un color buffer comme un void* permet pas mal d'optimisations comparé à un buffer formaté (RGB, RGB1, RGBA16F, RGBA32F... etc).
En revanche le predire pour demain c'est etre un peu presomptueux quant au succes de Larrabee (puisque c'est a priori de ca dont il parlait sans le dire).
Là c'est de la propagande marketing. Mais au moins ça a le mérite d'interroger les gens :)
Mon point de vue sur le parallèle qui commence à devenir massif (OK, on est loin d'une Connection Machine, mais 80 coeurs ça peut se qualifier de massif) je l'ai déjà exprimé : il nous manque un langage adapté. Et il faut aussi rééduquer les programmeurs, moi le premier.
Sans doute qu'un langage plus adapté permettra de faciliter la tâche du codeur. Ceci dit la programmation massivement parallèle existe depuis des années sans que ces fameux langages prophétiques n'émergent. Bref, ce n'est pas une condition absolu pour que les gens s'intéresse a la programmation parallèle. Mais il est vrai que ce qui a fait le succès du [GP]GPU c'est le fait que les gens programmaient // sans le voir.
Quant à DX/OpenGL, j'ai l'impression que c'est le concept de la rasterization qui a été tellement poussé dans ses limites qu'on en est arrivé là.
Un algorithme de rendu ne peut justifier le foutoir d'une API! De plus le rasterization n'est qu'une technique de rendu qui permet de faire des choses de plus en plus puissante. Il y a encore plein de chose à tirer encore d'un rendu par rasterization. Bref la rastérization n'est sans doute pas arriver à ses limites... Loin de là!
Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.
Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).
il y a un autre aspect qui plaide en faveur du processeur dédié : le rendement énergétique. On peut dire ce que l'on veut un dédié est toujours plus efficace, sauf si on commence à l'utiliser pour autre chose que ce pour quoi il a été conçu
Je ne suis pas contre le dédié! Les GPU ressemblent justement de moins à moins à un processeur dédié. Tout devient de plus en plus programmable ce qui le rend de moins en moins spécialisé. CUDA, Tesla & co illustre le fait qu'NVidia considère justement leur proc comme de plus en plus généraliste. Bref à l'avenir il est probable que les CPU auront quelques unités dédiées (au filtrage par exemple comme larabee) mais bien plus limitées que ce que l'on a aujourd'hui.
Et qui va standardiser le nouveau langage et/ou API graphique pour les coeurs plus ou moins généralistes ? Parce que je ne pense pas que qui que ce soit veuille revenir à l'époque pré DX/OpenGL et tout se palucher à la main.Effectivement, si on revient à l'époque du "on se retape tout à la main", je vois plus bien où est la meilleur facilité de programmation.
Il y aura donc bien une API/Middleware qui remplacera OpenGL/D3D tout en bénéficiant de la souplesse du matériel qui le fera tourner.
Mais si ce jour arrive, il y aura à tous les coups nVidia et AMD qui sortiront une puce dédié qui "accélèrera" cette API et on reviendra à la même situation qu'avant.
Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).Les programmeurs de consoles se paluchent tout à la main ? Il me semble bien qu'ils passent eux-aussi par des middleware et qu'il s'en plaignent quand celui-ci est pourri (perf, bug, fonctionnalité). C'est ce que j'avais cru comprendre avec la PS2 par ex.
Et encore, avec les Wii/XBOX/PS3 ce sont des GPU ATI/nVidia donc même problème que sur PC. La théorie du "je me paluche la 3D à la main" ne me semble plus d'actualité sur console.
Foudge, bien sur que certains développeurs de console utilisent des middleware. Ceci dit pas tous... Loin de là!!! Et je te parle justement de ceux là... ceux qui s'intéresse dans le développement de techno. Un IdSoftware ne se code t'il pas tout? (jusqu'a la compression décompression du format JPEG pourtant bien connu/optimisé!). Un EPIC Software ne se fait pas son propre middleware? Sans parler de ces 2 monstres, les dévelopeurs d'Uncharted aussi ont tout balayer de la main en disant que tout ce qui était proposé était trop compliqué/usine à gaz. Bref ils se sont dit que vu qu'ils avaient de bon codeurs ils allaient tout se faire sur mesure à la paluche donc!!!!!. Bref on pourrait continuer la liste pendant des plombes. Qt aux consoles et aux GPU effectivement ce sont quasi les même que sur PC. Sauf que sur PS3 l'API n'en est pas vraiment une et que tu peux passer à coder pour coder le GPU sans la lourdeur de son API. Bref coder ce que l'on veut à la paluche n'a jamais autant été à l'ordre de jour... Le Lancer de Rayon temps réel dont tout le monde parle s'il arrive un jour, est fait actuellement à la main justement et tous les codeurs qui s'intéressent vraiment au lancer de rayon veulent avoir la main mise sur le tout ou presque. Bref une petite API qui facilite la vie oui... une API monstrueuse à la DX/OGL peut être que non!
newbie06
06/04/2008, 22h36
Ceci dit la programmation massivement parallèle existe depuis des années sans que ces fameux langages prophétiques n'émergent.
Parce que, comme tu le dis, ils sont protégés par une *API* qui fait le boulot pour eux. Interroge autour de toi pour savoir si les programmeurs connaissent les différents types de locks qui existent et leurs avantages et inconvénients suivant l'OS et la hiérarchie mémoire derrière. Si un langage ne nous abstrait pas de ça, la moyenne des programmeurs (dont je parle ci-dessous) va nous pondre des merdes absolues.
Un algorithme de rendu ne peut justifier le foutoir d'une API! De plus le rasterization n'est qu'une technique de rendu qui permet de faire des choses de plus en plus puissante. Il y a encore plein de chose à tirer encore d'un rendu par rasterization. Bref la rastérization n'est sans doute pas arriver à ses limites... Loin de là!(Warning: point de vue hyper perso, non forcément argumenté...) La rasterization n'est pas un algorithme de rendu. Il s'agit plus d'un empilage de bidouilles pour que ça fasse joli. Et là on est au taquet, et tu l'as dit toi-même : DX/OpenGL sont devenus des empilages d'astuces pour faire des trucs qui en mettent plein la vue, sans avoir forcément derrière une volonté de cohérence, et voire même sans derrière une justification théorique. Je ne fais pas de programmation graphique, mais j'ai lu pas mal de trucs dessus ; autant je percute sur les algos genre ray tracing et illumination globale, autant les astuces de je te mets dans le pipeline une texture pour le lighting qui viendra par-dessus le reste sauf si j'ai des transparences, j'ai vachement plus de mal.
Il y aura peut être des libraire optimisées et des middleware. Mais il est fort probable que contrairement à ce que tu dis ceux qui veulent du lourd coderont tout à la paluche. Les programmeurs de console (surtout sur Playstation) le font déjà et je ne crois pas avoir entendu un Carmack ou un Sweeney se plaindre d'avoir du coder un raster soft bien au contraire. Ils se sont surtout plein quand les API ne se programmaient pas ou peu et que tout était formaté (époque T&L).Tu as tout dit : tu parles d'un Carmack ou d'un Sweeney, et pas de Durand de chez Ubi. Le problème n'est pas chez les bons, le problème est dans la moyenne des développeurs. Ces gens-là sont des exceptions. J'ai discuté avec des très bons dévs PS2 ; eux leurs problèmes c'était leurs collègues qui n'avaient pas le niveau, pas les middlewares.
Oui, il y aura toujours des kadors. Oui, y'aura toujours des programmeurs incroyables (par exemple, les demo makers). Mais ces gens-là seront toujours des exceptions.
Je ne suis pas contre le dédié! Les GPU ressemblent justement de moins à moins à un processeur dédié. Tout devient de plus en plus programmable ce qui le rend de moins en moins spécialisé. CUDA, Tesla & co illustre le fait qu'NVidia considère justement leur proc comme de plus en plus généraliste. Bref à l'avenir il est probable que les CPU auront quelques unités dédiées (au filtrage par exemple comme larabee) mais bien plus limitées que ce que l'on a aujourd'hui.Je voudrais bien que ce soit comme ça. Mais ce que je voulais dire, c'est qu'un jour le dédié reviendra en force pour de bonnes raisons, le rendement en étant une qui est imparable.
Je vais prendre un exemple : de plus en plus tu trouves des instructions multimedia sur les procs généralistes (SSEn sur x86, NEON sur ARM, etc.). Ensuite tu regardes ton domaine d'application ; ARM disons que ce sont des téléphones haut de gamme ; tu crois qu'il vaut mieux que ton processeur principal avec son jeu d'instructions tip-top multimedia fasse le décodage de ton prOn ou bien vaut-il mieux que ce soit un processeur dédié qui le fasse ? C'est ta batterie qui va dicter le choix, et le choix est clair.
On pourra toujours dire que je parle d'un domaine particulier, l'ultra-portable. Mais ce genre de considération arrive jusque dans les fermes de calcul où l'on commence à se dire que la note d'électricité dépasse le coût du matos...
Newbie06 je ne suis pas d'accord avec toi :).
Parce que, comme tu le dis, ils sont protégés par une *API* qui fait le boulot pour eux
Non! Je ne parlais pas de prog graphique ou autre de même nature qui sont parallélisé automatiquement à travers leurs API. Les gens programment en // avec des langages en C/C++, Java etc. depuis longtemps sans passer par des API qui leur mâchent le travail. Depuis que le // est devenu grand public, il semblerait que ce soit les gens crois (je ne te vise pas hein ;)) que c'est le truc tout neuf inconnu des développeurs! Lancer de Rayons, Traitement d'image, Décodage vidéo/Audio, Base de données etc. n'ont pas attendu l'émergence d'un langage particulier pour se paralléliser. Ceci dit un langage qui simplifierait la tâche du développeur tendrait à démocratiser d'avantage ce type de programmation.
Interroge autour de toi pour savoir si les programmeurs connaissent les différents types de locks qui existent
Justement, les programmeurs autour de moi ont tous appris la programmation // (cursus général universitaire). mutex, semaphore, lock free (Plus difficle de trouver des gens qui connaissent) etc. toutes ces notions sont connues. L'influence du sous système mémoire, l'OS & co est sans doute moins connues par contre
Si un langage ne nous abstrait pas de ça, la moyenne des programmeurs (dont je parle ci-dessous) va nous pondre des merdes absolues.
Sauf qu'on ne parle justement pas de la moyenne des développeurs mais de ceux qui vont pondre des techno de rendu :). Et on en arrive à la partie que je préfère (J'ai noté ton Warning mais je vais faire comme s'il n'y était pas :p)
La rasterization n'est pas un algorithme de rendu. Il s'agit plus d'un empilage de bidouilles pour que ça fasse joli.
Si... c'est un algorithme de rendu très efficace pour régler le problème de "rayons" primaires! L'empilage dont tu parles n'est pas foncièrement lié à la rasterization. Enfin effectivement un raster est présenté sous forme de pipeline et donc par un enchaînement d'étapes successives qui peuvent faire penser à un empilement d'opération mais l'empilage dont tu parles semblait plus faire référence à un amas de techniques foireuses et là ce n'est pas lié à la rastererization
tu l'as dit toi-même : DX/OpenGL sont devenus des empilages d'astuces pour faire des trucs qui en mettent plein la vue, sans avoir forcément derrière une volonté de cohérence, et voire même sans derrière une justification théorique
Oui et j'ai dit aussi qu'un algorithme de rendu ne peut justifier l'aspect obèse pas propre de ces API. Qt aux justifications théoriques je ne vois pas trop ce que tu entends par là mais d'un point de vue purement conceptuel le pipeline est assez bien passé. C'est juste les API qui le spécifie qui devienne trop monstrueusement complexes et pas toujours cohérente.
Je ne fais pas de programmation graphique, mais j'ai lu pas mal de trucs dessus ; autant je percute sur les algos genre ray tracing et illumination globale, autant les astuces de je te mets dans le pipeline une texture pour le lighting qui viendra par-dessus le reste sauf si j'ai des transparences, j'ai vachement plus de mal.
Le ray-tracing est conceptuellement plus simple à comprendre. Par contre ce dont tu parles à propos des lightmaps etc. n'ets pas lié exclusivement au Raster! Tu peux faire des light-maps (baking) en lancer de rayons! On fait souvent l'amalgame dégueulasse = raster sauf que c'est faux. Le raster est utilisé dans les jeux qui sont gourmands de performances et donc des astuces (des hacks) sont utilisés pour simuler certains effets et ce rapidement. D'où cet amalgame douteux (qui n'a pas vraiment lieu d'être vu que même une lightmap simule un éclairage [indirect] impossible en rendre dynamiquement en temps réel!). Le raster a ses limitations (Transparences, reflets...Etc) mais peut faire rapidement des choses propres (Je peux linker des articles sur la tesselation, les ombres etc. qui illustre tout ça). Le Lancer de rayons a aussi ses techniques que tu pourrais considérer comme douteuse. Et pour conclure là dessus, un path-tracing avec intégration de Monte-Carlo est propres dans son concept (Non biaisé, résout tout etc.) mais a aussi ses limitations (variance, flickering, temps de calcul prohibitif etc.)
Tu as tout dit : tu parles d'un Carmack ou d'un Sweeney, et pas de Durand de chez Ubi. Le problème n'est pas chez les bons, le problème est dans la moyenne des développeurs. Ces gens-là sont des exceptions. J'ai discuté avec des très bons dévs PS2 ; eux leurs problèmes c'était leurs collègues qui n'avaient pas le niveau, pas les middlewares.
Oui, il y aura toujours des kadors. Oui, y'aura toujours des programmeurs incroyables (par exemple, les demo makers). Mais ces gens-là seront toujours des exceptions.
On ne parles justement pas du développeur moyen. Pour lui rien ne changera puisqu'il aura un middleware qui lui fera le travail (que ce soit du soft // ou accéléré par OpenGL ou du CUDA pouet pouet il ne le saura même pas ou il s'en foutra). Les technos du renderer en lui même intéresse une poignet de développeurs, un noyau dur près à développer du neuf et là c'est de quelques dev chez ID, Epic, Naughty Dog, Gamebryo etc. dont on parle. Ce qui sont pret a se retrousser les manches pour bosser sur du neuf pour faire du neuf. Ubisoft ou EA c'est un peu particulier (contrainte bien plus forte d'un éditeur/développeur avec N titres sur X plateformes). A noter qu'Epic a proposé pendant très longtemps un raster soft avec leur Unreal engine. Bref on peut toujours considérer ces devs comme des exceptions mais c'est justement ces exceptiosn qui guident/popularisent des technologies de rendu (qui avait entendu parler des "mega textures" avant l'id-tech4/5?).
Pour finir sur le dédié je suis d'accord avec toi sur quasi tout. (rendement & co). Ceci dit, un GPU (qui se dit dédié au rendu graphique) consomme énormément car justement il est de moins en moins dédié (et simple). bref si tu vires le GPU et que tu gardes que ton octo coeur la consommation va chuter brutalement :). Ce que j'essaie de te faire voir c'est qu'un GPU n'est plus un processeur dédié à quoique ce soit (sauf certaine petites parties qui se disent vouer à devenir programmable (sic!)). Certes c'est une archi spécialisé pour la programmation par flux mais il est bien loin le temps ou il ne faisait que transformer, éclairer des sommets et interpolés des attributs. Bref pour un GPU l'argument de la consommation ne tient plus vraiment. Celui des perfs par contre oui (cf le post de fefe)
Pour finir sur le dédié je suis d'accord avec toi sur quasi tout. (rendement & co). Ceci dit, un GPU (qui se dit dédié au rendu graphique) consomme énormément car justement il est de moins en moins dédié (et simple). bref si tu vires le GPU et que tu gardes que ton octo coeur la consommation va chuter brutalement :). Ce que j'essaie de te faire voir c'est qu'un GPU n'est plus un processeur dédié à quoique ce soit (sauf certaine petites parties qui se disent vouer à devenir programmable (sic!)). Certes c'est une archi spécialisé pour la programmation par flux mais il est bien loin le temps ou il ne faisait que transformer, éclairer des sommets et interpolés des attributs. Bref pour un GPU l'argument de la consommation ne tient plus vraiment. Celui des perfs par contre oui (cf le post de fefe)C'est un peu contradictoire ce paragraphe. Tu dis que le rendement est meilleur mais que l'argument de la conso ne tient pas ?
nVidia&ATI ne vendent pas que des GPU qui consomment plus de 100W. Je dirais même qu'en terme de vente ça doit pas représenter grand chose.
Je suis persuadé qu'un dualcore + un petit GPU serait plus perf qu'un octocore tout en consommant moins.
Tu peux aussi avoir qq CPUs et qq texture samplers sur un meme die. Cote power ca n'a aucun sens de dupliquer les fonctionnalites parce que tout ce qui est generique leakera que ce soit cote CPU ou GPU...
C'est un peu contradictoire ce paragraphe. Tu dis que le rendement est meilleur mais que l'argument de la conso ne tient pas ?
Oui enfin je dis pas exactement ça hein ? :)... Dire qu'il faut garder les GPU parce que c'est dédié et que ça consomme moins n'est plus vraiment d'actualité car ce n'est plus vraiment dédié et qu'ont ne peut pas dire que ça ne consomme pas (ou peu).
nVidia&ATI ne vendent pas que des GPU qui consomment plus de 100W. Je dirais même qu'en terme de vente ça doit pas représenter grand chose.
Effectivement mais c'est justement ces GPU qui nous intéressent vu que l'on parle des techniques de rendu à venir! Bref en se détachant de ce modèle CPU + GPU, un développeur remarque que bcp de machines disposent d'un CPU correct épaulé par un GPU cramoisi. Virer ce GPU et penser un rendu soft n'est vraiment pas idiot surtout si tu ajoutes quelques fonctionnalié au dit CPU.
Je suis persuadé qu'un dualcore + un petit GPU serait plus perf qu'un octocore tout en consommant moins.
Tient ça serait intéressant de bencher tout ça. Une config à prix égal sur unreal 2004. L'un bourré au taqué côté CPU l'autre moins bourré au taqué mais avec un GPU. On teste en rendu GPU et en raster soft (avec les même paramètres de rendu). Il est plus que sur que le GPU va défoncer la config CPU mais il serait intéressant de connaître dans quelle proportion. Il serait intéressant aussi de savoir quelle serait la perte de perf sur une config donnée, avec puis sans GPU. Ca permettrait de mettre en perspectives ces résultats avec la consommation de la configuration.
Cf le compte rendu de Sam sur l'IDF et la demo de Quake en RT.
90 fps c'est pas mal pour une scène de jeu (dynamique donc), même si Quake IV n'est pas très chargé en polygones. Par contre:
Benefit of ray tracing:
[...] per pixel exact shadows [...]
C'est plutôt marrant qd on sait que l'ID-tech4 derrière quakeIV (l'original) est justement l'un des rares moteurs qui utilisent les shadow volumes; shadow volumes qui ont pour principal avantage de générer des ombres exactes au pixel près <_<. Le bénéfice du RT sur ce point est donc nul (sic!).
newbie06
08/04/2008, 20h35
D'après ce que j'en sais la démo de Quake RT de chez Intel n'est pas un jeu complet, juste un viewer. On m'aurait menti ?
En plus à une époque il me semble qu'il n'y avait même pas de rayons secondaires hormis l'ombrage.
J'avais montré une capture à une connaissance développeur chez IO (Hitman) et en deux secondes il m'a prouvé à quel point les ombres n'étaient pas si réalistes en me montrant une scène issue de rasterization classique.
Pour ceux que ça intéresse un mec a posté des patches sur la ML ioquake3 pour faire du RT.
On a encore dérivé, non ? :p
EDIT: pour le truc ioq3 http://www.youtube.com/user/Stereo1984
D'un point de vue théorique les ombres d'un Lancer de rayons ou d'un volume d'ombre sont en fait plus réaliste que les "ombres douces" utilisées actuellement en raster. En raster, ce ne sont rien de plus que des filtrages qui ne veulent pas dire grand chose. Un volume d'ombre ou un Lancer de Rayon sont eux corrects si l'on considère que la source lumineuse n'est pas surfacique mais s'assimile à un point. Même d'un point de vu pragmatique les ombres actuelles des raster ne sont pas super soignées car soumis à bcp d'artefacts (ombrage d'une surface par elle même, biais en Z trop important pour justement éviter l'artefact précédent etc...), trop d'aliasing... Pourtant il y a bien des algo puissant pour arriver à faire du propre mais il semblerait que ça ne soit aujourd'hui pas suffisant :)
newbie06
08/04/2008, 23h11
Un volume d'ombre ou un Lancer de Rayon sont eux corrects si l'on considère que la source lumineuse n'est pas surfacique mais s'assimile à un point.
Si tu considères ta source lumineuse comme ponctuelle, n'obtiens-tu pas une ombre au bord trop franc avec du RT ? J'avais cru comprendre qu'il fallait justement prendre une source lumineuse comme un disque et envoyer plusieurs rayons depuis une même intersection.
(Je suis novice, pas taper :p)
Si tu considères ta source lumineuse comme ponctuelle, n'obtiens-tu pas une ombre au bord trop franc avec du RT ? J'avais cru comprendre qu'il fallait justement prendre une source lumineuse comme un disque et envoyer plusieurs rayons depuis une même intersection.
(Je suis novice, pas taper :p)
Peut-être qu'ils modélisent aussi la diffraction en RT ?
:)
Effectivement si tu assimiles ta source à un point le problème de l'ombre est binaire: un pixel voit la lumière ou non (=> contour franc). Le RT et les volumes d'ombres permettent de résoudre cette problématique au pixel près. Les shadow map non (problème de discrétisation). Avec une source étendu le problème est plus complexe puisque chaque pixel peut ne pas voir la lumière (ombre) la voir en totalité (lumière) où la voir en partie (pénombre).
Pour simuler cette pénombre les jeux d'aujourd'hui filtrent le conteur des ombres franches (généralement calculé par shadow-map) ce qui n'a aucune signification d'un point de vue "physique". Avec un lancer de rayons, on ne filtre pas mais on lance plusieurs rayon vers des échantillons de la source lumineuse afin d'intégrer numériquement l'éclairage direct: chaque échantillon peut alors soit apporter de la lumière (le rayon n'intersecte pas de géométrie ) soit non (la rayon est bloqué par une géométrie). En raster il existe un algorithme basé sur les volumes d'ombre qui permet de calculer ce type de résultat en temps réel/interactif.
EDIT: faut que j'arrête le hors sujet!
Non on n'arrete pas le hors sujet !, c'est interressant et on peut toujours deplacer ces qq posts vers le topic Larrabee :p.
Je me demandais aussi si on avait des models de rendu qui modelisaient la diffraction et si la refraction/reflexion/absorbtion etait modelisee de maniere apropriee: toute surface a ces 3 proprietes (en fait l'air aussi) et ce sont les principales contributions aux ombres douces de notre monde reel si je ne suis pas completement a l'ouest en optique.
Mais bon dans mes souvenirs le raytracing employe pour faire les designs optique et en infographie sont sensiblement differents.
Paf encore du hors sujet!
L'équation de rendu (qui est encore loin d'être résolue en temps réel) est basée sur une approximation des équations de transfert radiatif de Maxwell. Comme elle est basée uniquement sur l'optique géométrique (principe du lancer de rayons) elle ne peut donc pas simuler la diffraction. Par contre la réflection et la réfraction oui.
(Très?) Grossièrement,en infographie les ombres ne sont rien de plus que le résultat de requêtes de visibilité entre 2 points A et B. Si A voit B alors A éclaire B (pas d'ombre) sinon B n'est pas éclairé par A (ombre). Considérons maintenant le cas ou A éclaire B. Si A est un échantillon sur une source lumineuse alors A contribue à l'éclairage direct de B (éclairage reçu directement de la source de lumière). Si A est une surface alors A contribue à l'éclairage indirect de B (éclairage reçu indirectement de la source lumineuse: ie après qu'un rayon lumineux ai rebondi sur A).
L'indice de refraction de l'air est employe, ou tout est traite comme etant dans le vide ? (de maniere generale)
en fait je vais essayer repondre un peu tout seul: vu que je suppose que la refraction est geree lorsqu'un rayon rencontre une surface, je doute que l'air soit gere comme un volume ayant un indice de refraction donne. Right ?
Ben en fait ça dépend :). L'air est généralement considéré comme du vide. Par contre la fumé, le brouillard...etc bref tous les milieux participants peuvent être traités. Ceci dit, rien n'empêche a priori de traiter l'air comme un milieu participant (perf--!). A noter cependant que l'équation de rendu est souvent utilisée dans sa formulation surfacique. Hors les milieux participants ne sont pas surfaciques et nécessitent donc des algorithmes/traitements spécifiques.
newbie06
09/04/2008, 16h46
Et voila, je suis largue, on peut pas revenir au sujet histoire que j'ai l'air moins ridicule :p
Sans rire, je trouve tout ca interessant. Cependant a priori tout ce qui se fait en RT temps reel (RTRT quoi :)) n'utilise pas de formules d'eclairage avancees. Comme je le disais precedemment, la plupart des trucs qu'on nous montre n'utilisent pas de rayon secondaire, c'est du pipotage ala Intel Atom benchmark en somme.
C'est vrai que le RTRT ala Intel n'utilise pas pour le moment d'éclairage avancé. Par contre ils ont bien des rayons secondaires (reflets+ombres). Cependant, à l'avenir (proche l'avenir) des algorithmes comme le Metropolis Instant Radiosity (paf... (http://bat710.univ-lyon1.fr/~bsegovia/papers/mir.html)) ne semblent pas impossibles. Bref pour l'heure on voit 3/4 effets rigolos comme les reflets et des ombres franches ala doom3 mais ce n'est pas ça qui va démocratiser le RT c'est sur. Ce qu'il faut c'est du mega lourd comme de l'illumination globale en temps réel (laissez moi rêver) et là tout le monde sera vite d'accord... Sauf bien sur si le raster propose d'ici là de la GI en temps réel sur scène dynamiques <_<
Je ne pense pas qu'on puisse dire que les demos sont du pipotage a partir du moment ou on les interprete comme une preuve du concept qu'on commence a s'approcher du RTRT de qualite raisonable avec du hardware generique.
Il n'y a pas de comparaison entre des pommes et des oranges dans ce cas la (contrairement au cas atom) ou alors tous les tests d'appli 3D qui n'emploient pas la qualite maximum disponible sont sans interret. J'ai peut etre mal lu mais je n'ai pas vu de claim pretentieux/douteux disant que un DP Nehalem allait remplacer les GPUs.
Je serais plutot interresse par des commentaires qualitatifs sur la demo. Si la qualite du rendu est jugee mauvaise alors effectivement on en a rien a f. que ca soit du RTRT, mais si ca rend bien ca devient interressant. Sam m'a dit impressionnant, je n'ai pas vu je ne peux pas juger et je suis interresse par des avis experts, mais j'ai tendance a faire confiance a Sam.
newbie06
10/04/2008, 09h08
Bon OK, j'ai ete sans doute excessif en disant que c'etait du niveau de l'atom :)
Ce qui serait interessant, ce serait de coller deux machines cote a cote, faire du RTRT sur l'une, de la rasterization sur l'autre et observer ce que les gens en pensent.
Si j'arrive a me bouger ce WE, je testerai sur ioq3, mais en screenshots, mon 3500+ va pas pouvoir faire du RT :)
Franck@x86
10/04/2008, 13h18
Ah Nehalem fusionne aussi en mode 64-bit. Pkoi c'était pas le cas avec les Conroe ?
C'est seulement la macro-op fusion qui est désactivée en mode 64 bits non ? Il y a un semblant de justification ici (http://developer.intel.com/design/processor/manuals/248966.pdf) à la page 2-8 :
Intel Core microarchitecture is capable of one macro-fusion per cycle in 32-bit operation (including compatibility sub-mode of the Intel 64 architecture), but not in 64-bit mode because code that uses longer instructions (length in bytes) more often is less likely to take advantage of hardware support for macro-fusion.
Qu'est-ce que ça leur coûtait d'ajouter le support en 64 bits en fait ?
Au hasard, on peut essayer:
-des transistors, donc du power et des $
-du temps de design donc des $
-du timing dans les decoders qui est un endroit difficile du design, donc de l'effort, du power et du $
Tout ca pour faire de la macro fusion qui a une probabilite plus faible de se produire en 64 bits qu'en 32 (les instructions sont plus longues donc moins de chances qu'on ait ce qu'il faut dans les 16 bytes), et surtout sachant que la machine a une probabilite tres importante de ne jamais voir l'ombre d'un code 64 bits.
Donc la version courte de la reponse est probablement "$".
POV-Ray Real-Time Raytracing sur des machines contenant 2 à 8 cores :
http://www.legitreviews.com/article/690/10/
newbie06
10/04/2008, 18h40
Au hasard, on peut essayer:
-des transistors, donc du power et des $
-du temps de design donc des $
-du timing dans les decoders qui est un endroit difficile du design, donc de l'effort, du power et du $
Tout ca pour faire de la macro fusion qui a une probabilite plus faible de se produire en 64 bits qu'en 32 (les instructions sont plus longues donc moins de chances qu'on ait ce qu'il faut dans les 16 bytes), et surtout sachant que la machine a une probabilite tres importante de ne jamais voir l'ombre d'un code 64 bits.
Donc la version courte de la reponse est probablement "$".
Ca me fait penser : quelqu'un a-t-il des liens présentants des benchmarks 64 bits à la fois sur des Intel récents et des AMD récents ?
J'ai bien ça http://gmplib.org/gmpbench.html, mais c'est quand même spécialisé (enfin pour le multi-précision Intel ça pue trop :p)
PS - Ouai je sais le multi-précision c'est un marché si étroit que ça vaut pas les $ investis ;)
Ca me fait penser : quelqu'un a-t-il des liens présentants des benchmarks 64 bits à la fois sur des Intel récents et des AMD récents ?
J'ai bien ça http://gmplib.org/gmpbench.html, mais c'est quand même spécialisé (enfin pour le multi-précision Intel ça pue trop :p)
PS - Ouai je sais le multi-précision c'est un marché si étroit que ça vaut pas les $ investis ;)
Je ne pense pas que ce soit ca,
c'est juste que ces algos sont tres dependants de la latence du Mul ou AMD excelle et la latence du divide ou AMD excellait (Penryn devrait changer de maniere significative les chiffres du core2)
Pareil sur les flottant denormaux, plus ton appli en fait, plus tu veux un AMD.
newbie06
10/04/2008, 19h12
Je ne pense pas que ce soit ca,
c'est juste que ces algos sont tres dependants de la latence du Mul ou AMD excelle et la latence du divide ou AMD excellait (Penryn devrait changer de maniere significative les chiffres du core2)
Oui mon poste n'était pas explicite, j'ai fait croire que ça venait du 64 bits. Je vais me flageller en repentir...
En tout cas en specfp rate, 4 cores, OS 64 bits et en baseline les Opteron sont pas si mal que ça, je m'attendais à bien pire. Bon va falloir creuser !
newbie06
19/04/2008, 12h07
Est-ce du vent ? http://www.pcinpact.com/actu/news/43165-premier-supercalculateur-GPU-France-Tesla.htm
Si c'est le cas ca sera interressant de regarder les stats d'utilisation CPU vs GPU. Ca ressemble a une bonne news pour ceux qui font du GPGPU en tout cas.
Møgluglu
20/04/2008, 14h04
Est-ce du vent ? http://www.pcinpact.com/actu/news/43165-premier-supercalculateur-GPU-France-Tesla.htm
Peut-être pas totalement...
Ils ont du se dire : tiens, tant qu'à claquer 20 milions dans un supercalculateur, si on en profitait pour mettre quelques GPU, c'est à la mode et en plus ça va doubler notre nombre de teraflops, comme ça on montre qu'on en a une plus grosse que les américains...
Actuellement il y a quelques autres projets de calculateurs "pétaflopiques" à base de GPU/Tesla.
On trouve aussi quelques AMD FireStream en circulation (il semble que ça existe vraiment...)
Si c'est le cas ca sera interressant de regarder les stats d'utilisation CPU vs GPU.
<mode rabat-joie>
Ou déjà regarder les stats d'utilisation tout court des calculateurs existants et calculer le prix/gigaflop réel.:(
</mode rabat-joie>
Dans la mesure où c'est utilisé pour la recherche, ça ne sera pas forcément représentatif des applis/besoins de calcul réels. J'imagine qu'on va avoir des chercheurs en GPGPU qui bosseront juste sur leurs GPU, et tous les autres sur le reste de la machine...
Ca ressemble a une bonne news pour ceux qui font du GPGPU en tout cas.
Dans la mesure où on parle de nous dans PCI, certes ;)
Mais ce genre de brontosaure est quand-même en train de passer de mode (enfin depuis 20 ans en fait). La tendance est plutôt au grid-computing hétérogène distribué à base de PC et réseaux standards, et le GPGPU correspond bien à cette idée d'exploiter le marché de masse. Dans un supercalculateur, je vois mieux des FPGA/FPOA...
newbie06
20/04/2008, 14h17
Mais ce genre de brontosaure est quand-même en train de passer de mode (enfin depuis 20 ans en fait). La tendance est plutôt au grid-computing hétérogène distribué à base de PC et réseaux standards, et le GPGPU correspond bien à cette idée d'exploiter le marché de masse.
J'imagine qu'une énorme partie de la consommation va à des programmes Fortran dont des parties ont probablement des dizaines d'années. Ca m'intéresserait bien de savoir quelle est la proportion de F77 ;) Tant qu'on ne sortira pas de ça, certains brontosaures survivront.
Ma remarque ne s'applique peut-être pas (plus ?) au monde des chercheurs, ou à certaines parties de ce monde (j'avais quand même l'impression que les numériciens s'accrochaient toujours à Fortran quand j'étais au CNRS).
Dans un supercalculateur, je vois mieux des FPGA/FPOA...Cray bosse là-dessus non ?
Møgluglu
20/04/2008, 16h23
J'imagine qu'une énorme partie de la consommation va à des programmes Fortran dont des parties ont probablement des dizaines d'années. Ca m'intéresserait bien de savoir quelle est la proportion de F77 ;)
La plupart des physiciens que je connais programment en Fortran 77 ou 95, effectivement. Et les autres en Matlab.
Mais un programme de physique typique, c'est un paquet de code qui formatte des entrées pour les mettre dans des grosses matrices, appelle du Blas/Lapack pour les multiplier/inverser/trianguler/etc. puis formatte le résultat en sortie...
(enfin c'est l'impression que j'en ai)
Les FPGA, Cray a commencé à les intégrer dans ses supercalculateurs à partir du XD1, mais c'est surtout depuis l'ouverture de l'HyperTransport que c'est devenu intéressant (solutions de DRC, XtremeData et Celoxica sur HTT).
D'ailleurs, est-ce qu'Intel va permettre d'utiliser QuickPath pour ce genre de choses?
newbie06
20/04/2008, 16h27
D'ailleurs, est-ce qu'Intel va permettre d'utiliser QuickPath pour ce genre de choses?
Apparemment oui : http://edageek.com/2007/10/24/intel-quickpath-nallatech/
Salut, je me demandais ce que ça allait changer point de vue OC sur le nehalem de ne plus avoir le FSB mais un nouveau bus de donnée ???
newbie06
14/05/2008, 17h32
Pfff je voulais poster avant que tu aies le temps de le faire :p
http://www.pcinpact.com/actu/news/43208-Intel-Nehalem-overclocking-absence-bloomfiel.htm
PCI n'arrive pas encore a faire la difference entre 8 cores et 4 cores + hyper threading. Pourtant leur tableau est correct de ce point de vue...
Pfff je voulais poster avant que tu aies le temps de le faire :p
http://www.pcinpact.com/actu/news/43208-Intel-Nehalem-overclocking-absence-bloomfiel.htm
Mais voleur de question !!!
Si non chez moi ton lien est mort...
newbie06
14/05/2008, 17h42
Mais voleur de question !!!
Je voulais juste anticiper ta question en mettant la reponse...
Si non chez moi ton lien est mort...
Belgique powaaa ? Ca marche tres bien d'ici...
PCI n'arrive pas encore a faire la difference entre 8 cores et 4 cores + hyper threading. Pourtant leur tableau est correct de ce point de vue...
J'avais pas fait attention, mais en effet. Du coup je me suis demande s'ils ne s'etaient pas trompes en utilisant le nom Bloomfield, mais vus qu'ils parlent de socket 1366, ca a l'air bon.
Belgique powaaa ? Ca marche tres bien d'ici...
Ouais a mon avis c'est ça...
Ca dis quoi en gros ?
newbie06
14/05/2008, 18h01
Ouais a mon avis c'est ça...
Ca dis quoi en gros ?
Que tu peux oublier l'OC:
Le site FudZilla affirme que pour l'instant, Intel pense à bloquer l'overclocking de certains modèles de ses futurs processeurs Nehalem.
Selon notre confrère, Intel se préparerait donc à changer de politique (http://www.pcinpact.com/actu/news/43208-Intel-Nehalem-overclocking-absence-bloomfiel.htm#), après avoir été très souple sur l'overclocking de ses actuels Core 2, grâce à une architecture à fort potentiel en la matière. Les prochains Nehalem pourraient bien limiter les possibilités des utilisateurs en milieu de gamme.
Que tu peux oublier l'OC:
héééééééééé merde
Paul Verveine
14/05/2008, 18h26
En fait quand nos a posé la question, sans même avoir vu la news de pcinpact, je me suis dit qu'il y avait un truc pas net avec l'intégration de la gestion du bus...
Espérons qu'intel poursuive sa politique actuelle.
En fait quand nos a posé la question, sans même avoir vu la news de pcinpact, je me suis dit qu'il y avait un truc pas net avec l'intégration de la gestion du bus...
Espérons qu'intel poursuive sa politique actuelle.
Intégration du bus ??? Je comprend pas :ninja:
Les Cpus Intel actuels derivent leur horloge de la frequence du FSB (avec un multiplieur), Nehalem enleve le FSB, integre le controleur memoire et emploie un lien point a point vers l'exterieur (QPI). L'archi des Nehalem devient donc similaire a celle des AMD K8 et posterieurs.
Les multiplieurs etant bloques systematiquement hors extreme edition, si tu n'as plus la possibilite de changer la frequence de base, tu ne peux plus overclocker. La question est de savoir d'ou Nehalem tire son horloge de reference, et si il sera possible de changer celle-ci.
La reponse permettra de savoir si/quels Nehalems seront overclockable, sachant que a priori si ils n'ont pas fait d'efforts specifiques pour les rendres overclockables ca ne sera probablement pas facile...
Salut, je me demandais ce que ça allait changer point de vue OC sur le nehalem de ne plus avoir le FSB mais un nouveau bus de donnée ???La différence, c'est que tu OC le CPU en augmentant la fréquence de référence à la place du FSB.
Un peu comme on l'a fait sur les A64 (qui je le rappelle n'ont pas de FSB).
Pour l'histoire de l'OC "bloqué" chez Intel, ça ressemble plus à une rumeur qu'autre chose. Au pire, on modifiera le microcode du CPU ^_^
Franck@x86
14/05/2008, 21h59
J'imagine mal Intel imposer des BIOS sans la moindre option d'oc, ce serait pour le moins difficile à contrôler.
Cela dit, il est tout à fait possible au processeur de moduler le ratio de cycles de bus actifs, et c'est tellement possible que ça existe déjà, ça s'appelle le DynFSB et ça équipe les laptops récents. En gros, la carte mère continue de générer 200 MHz mais le proc module en ne "drivant" qu'un cycle sur deux, et le proc tourne comme s'il était en FSB 100. Techniquement c'est donc pas du tout un souci.
Maintenant j'y crois pas trop, l'o/c est devenu un tel enjeu commercial que ça reveindrait à se tirer une balle dans le pied. Eventuellement ça se concevrait si AMD était définitivement hors course, et ... euh ...
Paul Verveine
14/05/2008, 22h15
J'ai du mal à saisir ton concept Franck.
en gros la cm se tourne les pouces une fois sur deux dans ton exemple ? Quel est l'intérêt de ne pas synchroniser les deux ? d'abaisser la fréquence de la carte mère ?
pour les portables, oui.
Ca permet de simuler facilement un CPU à 800 MHz dans les Core 2 Duo, au lieu des 1200 minimum en SpeedStep classique.
Paul Verveine
14/05/2008, 23h13
Ok, mais y'a pas une perte d'énergie ? pourqio ne pas faire descendre la fréquence de la cm pour la synchroniser ?
Franck@x86
14/05/2008, 23h59
Beaucoup de fréquences sont liées à celles du FSB (PCI / PCI-E / AGP, et d'autres), toute grande variation à la volée est donc délicate. L'idée est donc de moduler le FSB qui sert de fréquence de base au cpu sans toucher au reste).
Le concept de "duty cycle" est assez ancien en réalité, les premiers P4 l'utilisaient en cas de throttling (TM1).
newbie06
15/05/2008, 00h10
J'imagine mal Intel imposer des BIOS sans la moindre option d'oc, ce serait pour le moins difficile à contrôler.
(mode parano) Je pense que c'est au contraire quelque chose de tout à fait possible : il suffit qu'Intel menace d'arrêter de faire des ristournes sur ses chipsets et les fabricants de CM fileront droit. Il a été prouvé que MS le fait, et il me semble qu'Intel avait menacé Dell de ne plus leur faire de remise sur les procs s'ils utilisaient de l'AMD.
On est dans un monde capitaliste avec pleins de monopoles :p
Plus il y a d'horloges differentes derivant de l'horloge de base, plus il devient difficile de la changer. Il est quasiment impossible d'empecher les fabriquants de carte mere de changer cette horloge de base, et ne presente pas d'interet pour Intel pour qu'ils le fassent. En revanche Il est tres possible qu'a cause du nombre d'horloges qui en derivent et du manque de marges d'OC dans certains de ces domaines d'horloge (PCIe ? QPI ? ...) la marge d'overclocking devienne faible, nettement plus faible que le potentiel d'OC du CPU.
Pour "permettre" des overclock important il faut donc fournir aux utilisateurs (donc aux Bios) la possibilite de changer tous les multiplieurs qui permettent de deriver ces horloges qui pourraient limiter un OC de l'horloge de base. Hors on sait tres bien que Intel si il le desire peut bloquer ces multiplieurs (ou offrir trop peu de ratios differents pour permettre de bons OC).
Donc je doute de l'impossibilite d'OC, la seule maniere d'y arriver est de controler tous les fabriquants de cartes meres, hors le premier qui desobeirait deviendrait riche a force de vendre ses cartes a des overclockeurs, donc il y a peu de chance qu'Intel puisse imposer ce genre de choses.
En revanche il est tout a fait plausible que beaucoup de multiplieurs seront bloques dans le CPU et limiteront considerablement le potentiel d'overclocking moyen des CPUs. Mais dans ce cas, il y aura forcement un modele avec des ratios qui seront plus appropries a l'OC et ca se saura assez vite sur le web.
Comme le dit Franck l'enjeu commercial de l'OC est trop gros pour qu'in constructeur fasse des efforts pour le bloquer. En revanche rien ne l'empeche de ne pas se fatiguer et avoir des cpus pas tres pratiques a OC ou alors avec moins de marges qu'aujourd'hui. Je n'ai pas vu grand monde dire d'AMD qu'ils etaient le mal parce que leurs CPUs actuels n'etaient pas tres overclockables. En effet tout le monde sait qu'il y a une bonne raison technique... Si les Nehalem s'OC peu pour des raisons techniques, ou est le probleme ? (A part que ca fait chier ceux qui preferent payer un cpu bas de gamme et avoir des perfs haut de gamme comme moi :))
Désolé, mais la grosseur de l'enjeu commercial de l'OC dans vos évaluations me semblent un peu exagérées. A part les power-users - et même chez eux - l'OC est pas énormément répandu. Et il me semblerait plus pertinent d'un point de vue marketing de supprimer
l'OC sur les séries normales, et de le réserver aux Extreme Edition (quitte à en élargir la gamme vers le bas). Ca driverait les powerusers vers ces séries, en justifiant d'une prime. C'est ce que font déjà en partie les fabricants de CM (en jouant sur les fonctions du BIOS), pourquoi Intel n'étendrait pas le concept aux chipsets/CPU?
Ce serait assez facile d'empêcher tout en OC en intégrant une horloge directement dans le CPU, il serait alors asynchrone avec la CM (sauf pour le contrôleur du bus, coté CPU).
Ca permettrait une gestion plus fine du power, que par ajustement du coef fbus/fCPU.
On avait déja parlé à un moment ici de l'asynchronisme CPU, mais au niveau de ses différentes unités (découplage de leur fréquence de fonctionnement). La aussi, ca permet de s'ajuster finement aux besoins du code en cours d'exécution, mais l'asynchronisme nécessite des buffers entre unités découplées, donc des transistors et de la latence supplémentaire.
Désolé, mais la grosseur de l'enjeu commercial de l'OC dans vos évaluations me semblent un peu exagérées. A part les power-users - et même chez eux - l'OC est pas énormément répandu.
Oui mais tu te trompes sur l'enjeu commercial indirect. Le potentiel d'overclocking correspond a une publicite massive, a fort impact et gratuite. Il en est de meme pour les extreme editions, aucun enjeu commercial direct, il ne s'en vend pas ou quasiment pas, et pourtant la performance relative des extreme editions avec ceux du concurent a une influence majeure sur le reste du marche.
Les gens achetent un celeron qu'ils n'overclockent pas, parce qu'ils ont entendu par un canal ou un autre que Intel etait plus performant. L'OC est un de ces elements aujourd'hui.
fefe: OK pour ces arguments, mais dans ce cas-là, le limiter aux EE (en adaptant un peu le message et en élargissant un peu la gamme) reviendrait quasiment au même.
fefe: OK pour ces arguments, mais dans ce cas-là, le limiter aux EE (en adaptant un peu le message et en élargissant un peu la gamme) reviendrait quasiment au même.
Oui, et nous discutons sur une rumeur qui semble dire que seuls les produits derives de Bloomfield seraient overclockables (la version avec QPI) et pas les autres. Apres il faudra voir les gammes qui sont couvertes avec Bloomfield. Il est possible que la rumeur soit vraie et que cela se produise pour des raisons de differences techniques entre Bloomfield et les autres. Cela ne me semble pas etre une partition EE/le reste a premiere vue. Si la rumeur est fausse, de toutes facons l'overclocking sur Bloomfield sera different des autres plateformes Nehalem (QPI vs PCIe).
La raison aujourd'hui pour ne debloquer le multiplieur que sur le plus haut de gamme, est que la gamme de produit reste immunisee au remarquage de CPUs, mais ca n'empeche pas d'OC toute la gamme, meme si c'est un peu plus dur que sur un EE.
Franck@x86
15/05/2008, 11h34
ce qui est certain c'est que le Nehalem bénéficiera (soyons optimiste) d'une gestion assez inédite des fréquences et tension. Il semblerait que l'externalisation des FID/VID soit abandonnée, au profit d'une gestion orientée power. En gros, le processeur adapte lui-même fréquences (au pluriel car il y aura plusieurs plans de fréq) et tension en fonction du power visé.
C'est bien, mais ça veut aussi dire que le CPU contrôle désormais certains paramètres liés à l'o/c. Je ne serais pas étonné que toute augmentation de tension soit impossible, sous couvert de protection de la dissipation. Ca suffirait à limiter le potentiel d'o/c.
Je viens de discuter avec qqu'un de chez Asus, il semblerait que la rumeur ne soit pas complètement infondée quand même...
Je viens de discuter avec qqu'un de chez Asus, il semblerait que la rumeur ne soit pas complètement infondée quand même...
Je suis convaincu qu'il va y avoir des changements significatifs pour les overclockeurs lies aux changement de l'architecture systeme sur Nehalem, et si on considere l'etat actuel de l'overclocking sur CPU intel cela ne peut guere aller que dans le mauvais sens (le rendre plus difficile). Mais ca ne veut pas dire non plus que tout sera impossible.
Maintenant j'y crois pas trop, l'o/c est devenu un tel enjeu commercial que ça reveindrait à se tirer une balle dans le pied. Eventuellement ça se concevrait si AMD était définitivement hors course, et ... euh ...
J'ai plus l'impression que le 'blocage' de l'O/C concerne comme toujours une mauvaise lecture par Fudzilla.
Tout comme AMD effectivement, le CPU va intégrer un PLL pour la génération du clock de la mémoire, et peut-être un second pour la génération du clock CPU.
Je penche plutot vers un mécanisme de blocage des deux PLL ensemble et/ou de contrôle que l'un fiat pas n'importe quoi.
La "limitation" de l'O/C serait a mon sens plutot une limitation de déconnage complet avec de la désynchro dans tous les sens et/ou de blocage d'un PLL pour les mécanismes d'i/o avec les autres puces sur une CM (en gros, un blocage de la fréquence du PCI-Ex ^_^) vu que si tout le monde utilisait le PLL du CPU, ca deviendrait n'importe quoi
Franck@x86
15/05/2008, 17h38
On dirait bien qu'Intel souhaite segmenter le marché avec l'overclock en le réservant aux versions haut de gamme (Bloomfield 1366). La version Lynnfield 1160 serait ainsi privée de toute modif, mais ça reste au conditionnel car les intégrateurs ne l'ont pas encore eue en main.
newbie06
03/06/2008, 11h12
Score CPU 3dmark: http://forums.vr-zone.com/showthread.php?t=283772
32KB de L2 il semble que soit cpuz a un probleme soit la plateforme testee,,,,
Ca va faire mal à AMD :
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3326
Résumer en français : http://www.hardware.fr/news/lire/05-06-2008/
newbie06
05/06/2008, 11h28
Y'a au moins un bug dans l'article : vitesse sur x264 ; soit il a inverse les chiffres, soit le Nehalem est plus lent ; je penche pour la premiere hypothese :p
En tout cas, impressionnant ! Esperons que d'ici 2009 la DDR3 aura suffisamment baisse :)
Ca va faire mal à AMD :
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3326
Résumer en français : http://www.hardware.fr/news/lire/05-06-2008/
C'est vrai que... wow. :o
Newbie => Non y'a pas de problème, le graphique est en FPS !
newbie06
05/06/2008, 11h47
Trop fort, il vient de corriger le bug x264, les barres etaient inversees...
Et puis si tu me crois pas, lis les commentaires :p
Ah ok, j'ai vu que la bonne version, moi :p
Franck@x86
05/06/2008, 12h57
Esperons que d'ici 2009 la DDR3 aura suffisamment baisse :)
Je viens de visiter qques sites et les prix ont déjà pas mal baissé.
Tu peux trouver 2 Go de DDR3 PC10600 pour une 100aine d'euros, et pas de la noname :
http://www.materiel.net/ctl/PC_de_bureau2/31212-DDR3_2_x_1_Go_PC10666_Gold_Edition.html
ou encore
http://www.materiel.net/ctl/PC_de_bureau2/33443-Kit_Extreme3_2_x_1_Go_PC8500_NQ.html
Ca devient abordable, même si bon les vitesses vont encore beaucoup augmenter.
A priori ce sont tous des benchs ou HT est on, donc l'augmentation de perf sans HT sur ces tests est probablement entre 10 et 30%.
Ca en reste assez joli, surtout que le power a tendance a descendre avec les steppings (cf Penryn), et meme sans ca ils ne partent aps d'une mauvaise situation.
newbie06
05/06/2008, 13h00
A priori ce sont tous des benchs ou HT est on, donc l'augmentation de perf sans HT sur ces tests est probablement entre 10 et 30%.
J'ai surtout ete impressionne par la bande passante et les perfs des caches, et la je ne pense pas que le HT joue. Le reste je m'en tape, c'est du Windows et c'est pas recompile :p
Je viens de visiter qques sites et les prix ont déjà pas mal baissé.
Ha oui en effet, donc d'ici 2009 ca devrait devenir franchement interessant !
Bof 13GB/s quand la RAM peut en debiter 24 ? C'est loin de m'impressioner... Quant a la latence memoire, ils ne comparent pas a un C2Q avec un FSB a 1600 et de la DDR2 avec de bons timings... Donc la latence du Penryn est tres conservative.
En revanche la DDR1066 qu'ils ont utilisee n'est pas demente non plus donc NHM n'est pas super avantage non plus.
Autre chose Anand en extase devant un cache de 8M avec 39 cycles de latence je ne comprends pas.
Penryn 6M 15 clocks, Conroe 4M 14 clocks, un core 2 avec 8M de cache aurait probablement fait 16 clocks. Maintenant oui c'est un L3, le L2 qu'ils ajoutent fait 11 clocks.
11+16 ca donne 27 chez moi (en pratique il y a possiblite d'avoir au moins 3 ou 4 cycles recouverts donc a peu pres n'importe quelle latence entre 25 et 30 cycles me semble raisonable pour un L3 de 8M.
39 ? Non, ce n'est pas bon. Et ce n'est pas parce que le L3 du Phenom est pire que ca rend la latence bonne.
Bien entendu il est probable que comme pour le Phenom le cache soit sur un different domaine de frequence et de voltage, ce qui force des latences supplementaires pour passer de l'un a l'autre. 10-14 clocks pour ca (changer de domaine de clock/voltage) me semble un peu haut mais apres tout peut etre que je suis trop exigeant ?
newbie06
05/06/2008, 15h23
Ils ne se seraient pas aussi laisse un peu de marge pour augmenter la taille de cache sans avoir a changer les latences ?
Et puis oui tu es trop exigeant, je prefere voir en terme d'evolution.
(mode parano) Et le marketing d'Intel aussi, donc ils se donnent de la marge pour sortir un truc encore mieux a peu de frais (peu de frais d'engineering mais plein de frais pour les clients) :p
Et puis oui tu es trop exigeant, je prefere voir en terme d'evolution.
(mode parano) Et le marketing d'Intel aussi, donc ils se donnent de la marge pour sortir un truc encore mieux a peu de frais (peu de frais d'engineering mais plein de frais pour les clients) :p
C'est aussi ce que se demande Anand dans sa conclusion : qu'est-ce qu'Intel va pouvoir nous trouver pour son prochain tock avec Sandy Bridge, pour arriver à garder ce rythme.
C'est quand le prochain coup qu'ils déçoivent ? :) (question que doit se poser AMD...)
Edit :
Ah, on me répond "Atom" dans mon oreillette.
:)
Childerik
05/06/2008, 16h01
C'est quand le prochain coup qu'ils déçoivent ? :) (question que doit se poser AMD...)
Jamais : AMD et Via auront coulé d'ici là :siffle:. Ou ils se seront reconverti à temps dans les puces pour périphériques sideshow :p
Bon, je viens de faire un peu de maths (Little's law pour ceux qui connaissent) et je crois que je comprends ce qui se passe pour la bande passante. La question fondamentale est est-ce que Everest utilise des streaming read vers un espace write combine pour leur test de bande passante en lecture ou non.
Si oui alors les prefetchers ne trigger pas et il y a gachis de bande passante pour les plateformes qui sont limites par les fill buffers (buffers qui track les requetes en cours vers la memoire). Dans le cas de Penryn ca ne se voit pas trop parce que le FSB devient vite un probleme, dans le cas de Nehalem, pas de FSB qui limite donc ce sont les buffers qui limitent.
Sur les plateformes a FSB utiliser des read qui peuvent etre reordonnes (vers WC space) permet d'augmenter la bande passante parce qu'on utilise mieux le FSB, quand on enleve le FSB ils deviennent plus problematiques qu'autre chose.
Bref, sur des reads normaux je m'attends a au moins 17GB/s avec un thread sur cette plateforme et 22-24 GB/s avec 2 threads.
Si je me trompes sur l'histoire du bench, alors Nehalem sux vraiment pour la bande passante memoire.
Je laisse qui le veut traduire mon Mandarin vers qq chose de plus interpretable.
Je laisse qui le veut traduire mon Mandarin vers qq chose de plus interpretable.
OK, pas de problème.
Je viens de procéder à quelques savants calculs (la loi du Petit pour ceux qui la connaissent) et je crois avoir identifié la source du problème de la bande passante. La question fondamentale est de savoir si Everest utilise des lecture en flux vers un espace d'écriture combinée pour leur test de bande passante en lecture, ou non.
Si oui, alors les préchargements ne se déclenchent pas et il y a gâchis de bande passante pour les plateformes limitées par les registres de remplissage (registres qui suivent les requêtes en cours vers la mémoire). Dans le cas de Penryn, cela ne se voit pas trop parce que le bus devient vite un problème, dans le cas de Nehalem, pas de bus qui limite, donc ce sont les registres qui limitent.
Sur les plateformes utilisant un bus limité, utiliser des lectures qui peuvent être réordonnées (vers l'espace toilette) permet d'augmenter la bande passante parce qu'on utilise mieux le bus. Quand on enlève le bus ils deviennent plus problématiques qu'autre chose.
Bref, sur des lectures normales je m'attends a au moins 17GB/s avec un fil sur cette plateforme et 22-24 GB/s avec 2 fils.
Si je me trompe sur l'histoire du banc, alors Nehalem est vraiment décevant pour la bande passante mémoire.
Voila, je pense que c'est bien plus clair comme ça.
De rien.
(et désolé de pourrir ce topic) :)
Edit :
Ah, je crois que je suis battu par Google. J'ai tenté une traduction français vers anglais vers français, le résultat est au delà de toute espérance. Je ne vous le colle pas ici parce que ca risque de faire beaucoup de flood pour un seul post, mais je vous mets la conclusion quand même, qui a elle seule mérite le détour :
Si je tubes sur l'histoire de la magistrature, puis Nehalem sux vraiment pour la bande passante mémoire.
newbie06
05/06/2008, 17h11
T'as oublie de traduire les GB/s. Tres decevant... :p
Et puis l'histoire du chiotte au lieu de Write combine...
J'ai bien aimé aussi l'espace toilette :)
Oui, il ne manquait plus que quelques flush
(=> chasse d'eau)
J'ai bien aimé aussi l'espace toilette :)
Pareil, je m'y attendais vraiment pas à celle-là :D
Le pire pour AMD dans cette histoire, c'est qu'au final entre Conroe et Nehalem, avec assez peu de modifications au niveau µarch (ce qui est probablement le plus complexe, comparé à la conception d'un contrôleur mémoire, d'un bus point à point, etc), Intel parvient à un +30%, alors qu'entre K8 et K10, avec 4 ans de développement quasiment exclusivement sur sa µarch, AMD ne parvient qu'à la moitié, +15%.
Moi j'vois plutot le passage Core->Nehalem comme le passage K7->K8 chez AMD.
Oui, si on compare ce qui a été fait comme modifications, c'est effectivement les transitions qui se ressemblent le plus.
Alors si AMD a une transition d'avance sur Intel :), la logique sera respectée si Sandy Bridge est 15% plus performant que Nehalem/Westmere.
Edit :
Ce que j'ai voulu dire avec ma comparaison Conroe-Nehalem / K8-K10, indépendamment de ce qui a été modifié de chaque coté, c'est que si on met en rapport les efforts investis avec les résultats obtenus, c'est bien moins bon du coté d'AMD. En un peu moins de 2 fois de temps, Intel obtient 2 fois mieux (rapport de x4 donc).
Bon, comme tu le fais remarquer, les 2 transitions ne sont pas vraiment comparables, et de plus, les efforts investis ne se mesurent pas en durée mais en jour.homme (si Intel y met 2 fois plus de monde, alors il peut y mettre 2 fois moins de temps).
Bref, juste pour dire que les ingés d'AMD doivent avoir les boules...
Le pire pour AMD dans cette histoire, c'est qu'au final entre Conroe et Nehalem, avec assez peu de modifications au niveau µarch (ce qui est probablement le plus complexe, comparé à la conception d'un contrôleur mémoire, d'un bus point à point, etc), Intel parvient à un +30%, alors qu'entre K8 et K10, avec 4 ans de développement quasiment exclusivement sur sa µarch, AMD ne parvient qu'à la moitié, +15%.
30% si tu comptes le SMT, en tout cas pour ce que j ai vu publie. Si tu comptes les 2 cores additionnels et les ameliorations d'IPC le K10 a gagne plus de 30% a frequence egale avec unK8x2, mais il reste un peu poussif en frequence...
Oui, si on compare ce qui a été fait comme modifications, c'est effectivement les transitions qui se ressemblent le plus.
Alors si AMD a une transition d'avance sur Intel :), la logique sera respectée si Sandy Bridge est 15% plus performant que Nehalem/Westmere.
Edit :
Ce que j'ai voulu dire avec ma comparaison Conroe-Nehalem / K8-K10, indépendamment de ce qui a été modifié de chaque coté, c'est que si on met en rapport les efforts investis avec les résultats obtenus, c'est bien moins bon du coté d'AMD. En un peu moins de 2 fois de temps, Intel obtient 2 fois mieux (rapport de x4 donc).
Bon, comme tu le fais remarquer, les 2 transitions ne sont pas vraiment comparables, et de plus, les efforts investis ne se mesurent pas en durée mais en jour.homme (si Intel y met 2 fois plus de monde, alors il peut y mettre 2 fois moins de temps).
Bref, juste pour dire que les ingés d'AMD doivent avoir les boules...
Cherche un peu sur Internet de quand date les premieres mentions de Nehalem. Cela invalidera tes calculs.
PeGGaaSuSS
09/06/2008, 21h09
On est quand même assez loin de ce que le premier jet de Nehalem devait être non ?
Ils avaient pas modifiés la chose quand les Core 2 sont sortis ?
De ce que j'avait compris, le Nehalem est un peu un Atom-like, y'a des bouts de ce qu'etait l'idée de base, mais pas tout.
Enfin ca devient de plus en plus courant visiblement, la réalité à l'air de rattraper les ingénieurs assez souvent ces temps ci.
On est quand même assez loin de ce que le premier jet de Nehalem devait être non ?
Ils avaient pas modifiés la chose quand les Core 2 sont sortis ?
De ce que j'avait compris, le Nehalem est un peu un Atom-like, y'a des bouts de ce qu'etait l'idée de base, mais pas tout.
Enfin ca devient de plus en plus courant visiblement, la réalité à l'air de rattraper les ingénieurs assez souvent ces temps ci.
Clairement, mais est ce que le temps passe a se planter ne compte pas ?
Je me demande un peu comment Intel/AMD et autres peuvent bosser en même temps sur une architecture prévue pour une année n, sur une autre prévue pour n+2 et une autre prévue pour n+4 alors que chacune capitalise toujours sur la (donc les) précédente(s). Ça doit être un sacré casse-tête...
C'est pareil pour nvidia par exemple, c'est pas Intel qui travaille dans son ensemble, c'est plusieurs équipes, chacune dédiée à une architecture. Disons que l'équipe n+2 capitalise sur n-2, n+1 capitalise sur n-3, etc :) De plus, j'imagine que:
- intel a un système de knowledge management et de documentation qui va bien
- intel met en place des sessions de "lessons learnt" entre les équipes pour justement
transmettre ce genre d'expérience
Quelqu'un (fefe en fait ;) ) a les effectifs R&D d'intel? et juste pour comprendre, une équipe sur un projet, ça représente combien de personnes (FTE) sur combien de temps? Si c'est public bien sûr... au moins l'ordre de grandeur :)
newbie06
10/06/2008, 08h42
Je me demande un peu comment Intel/AMD et autres peuvent bosser en même temps sur une architecture prévue pour une année n, sur une autre prévue pour n+2 et une autre prévue pour n+4 alors que chacune capitalise toujours sur la (donc les) précédente(s). Ça doit être sacré casse-tête...
Oui c'est un casse-tete, mais pour rester competitif tu n'as pas le choix.
Intel travaille sur des cycles de deux ans il me semble, dans chacun de ces cycles tu as deux grosses sorties : du tuning (petites ameliorations architecturales, nouvelle finesse de gravure) et une amelioration architecturale plus poussee.
Le pattern de dev/release de CPUs Intel ressemble a peu pres a ca:
T=Toc=ameliorations de l'archi
C=Tic=compaction=fait l'intro du process.
Chaque lettre est 1 annee, sachant que les projets durent de plus en plus longtemps
1:TTTTT
2:___CCC
3:__TTTTT
4:_____CCC
1 et 3 sont forcement faits par 2 equipes differentes et forcement de grosses equipes. 2 et 4 peuvent etre faits par les equipes 1 et 3 ou alors en collaborant avec de plus petites equipes.
Intel a dans les 100k employes mais je n'ai aucune idee de la repartition exacte, mais beaucoup travaillent dans les fabs et le soft.
newbie06
10/06/2008, 09h19
mais beaucoup travaillent dans les fabs et le soft.
Et personne sur l'Itanium ? :p
Franck@x86
26/06/2008, 12h11
Qques nouveaux tests :
http://www.xtremesystems.org/forums/showthread.php?t=190762&page=5
et voir les pages suivantes.
Le tout commenté par François.
Il semblerait que l'IMC tourne en single channel dans ce cas précis.
PeGGaaSuSS
06/08/2008, 20h32
http://www.maximumpc.com/article/features/exclusive_we_build_first_nehalem_system_dont_tell_ intel
D58XSO Smackover + Cheap Bloomfield + 3 x 2GB DDR3 pour Noël :o ?
Vu les prix actuels de la DDR3, et le futur prix probable de la Smackover, ca risque plutôt d'être 2x2GB.
Childerik
08/08/2008, 12h02
http://en.expreview.com/2008/08/08/nehalem-to-become-core-i7-processor/
Expreview est un peu trop sûr qu'on ne ravira pas la fraicheur de son information :siffle:.
Dans tous les forums, on cherche à savoir pourquoi le nom i7 : à mon avis, c'est plus une énigme marketing dont Intel se joue pour créer la nouvelle sensationnelle chez les geeks : qu'en pensez-vous ? Je ne crois pas à la relation générationnelle du x86 (786 par exemple)
Minuteman
08/08/2008, 13h18
Mais merde, on a des iCPU maintenant aussi.
Je préférais de loin Core 3/4...
newbie06
08/08/2008, 16h00
Vous n'y etes pas du tout : en langage djeunz "i7" ca fait "IT". Genre "1337" = "Leet" = "elite".
Ils ont du recruter des nouveaux marketers avec morve au nez et tout.
Minuteman
08/08/2008, 16h17
Non en fait i7 = ice even = produit cool comme de la glace, yeah.
Childerik
09/08/2008, 00h11
Je préférais de loin Core 3/4...
C'était logique :). Faut croire qu'on se lasse très vite des noms de marque chez les marketeux.
Ou alors AMD projetait secrètement de renommer ses futurs Phenom pour "coller" aux n° de génération des Core et ça s'est su chez les espions d'Intel :p.
Au vu des infos qui sortent sur le Turbo Mode du Nehalem, y'a quand même un point qui me chiffonne, c'est que à l'heure actuelle l'IDA (Intel Dynamic Acceleration) sur les Dual Core mobiles marche globalement pas.
Il faut que l'un des deux cores passe en état C1E pour que ca soit activé, et malheureusement, l'OS gère ca n'importe comment, résultat, ca n'arrive quasiment jamais. Il manque peut-être des drivers CPU pour que ca se comporte correctement, mais il est évident qu'il faut plus qu'une simple solution logicielle basée sur un état CPU pour activer l'O/C.
Conséquence, j'espere pour Intel qu'ils ont effectivement prévu une accélération purement matérielle par redirection des instructions balancées par l'OS sur chaque core pour pouvoir réellement désactiver les CPU et accélérer la vitesse d'un core
Malheureusement c'est l'OS qui gere sur quel core un thread tourne et pas le hardware... Donc tant que l'OS schedule de maniere inefficace tu es dedans.
Justement, ne serait-il pas envisageable d'avoir un redirecteur de threads vers un core différent géré au niveau du microcode/bios/hw et non pas par l'OS ?
Parce que franchement, j'ai très peur si ca marche comme sur les Core 2 Santa Rosa. Et j'espere que les tests sérieux étudieront ce point en détail (qui n'a été que survollé dans les tests Santa Rosa, aucune étude à 'fond' pour vérifier le comportement de la chose).
Résultat, l'IDA c'est dans les specs, mais ca n'est jamais utilisé et tout le monde s'en fout :/
Résultat, l'IDA c'est dans les specs, mais ca n'est jamais utilisé et tout le monde s'en fout :/
Si personne n'a teste comment peux tu dire que ca n'apporte rien ? Cela me semble un peu contradictoire ;). C'est utilise sur la majorites des portables modernes, donc c'est plutot tout le monde qui l'utilise aujourd'hui que personne - sans le savoir je te l'accorde.
Non parce que le passage en mode C1E d'un seul des deux cores se fait au final pas comme il faut, résultat, l'IDA s'active pas :)
Le répartiteur des threads sur un OS va toujours équilibrer entre plusieurs cores ses threads, et il y'a toujours plusieurs threads qui demandent du CPU.
Je ne demande qu'a être contredit hein ... ca serait tellement bien :(
Disons que je l'ai observe sur mon T61, et IDA se met en route. Avec un peu de chance lors de dumps CPUz j'ai meme reussi a avoir IDA on... Donc je sais qu'il s'active (c'est tout).
Apres je n'ai aucune idee de ce qu'une plateforme identique avec IDA off et avec IDA on donnerait comme difference de performance, et c'est la partie interressante. Je n'ai pas repere de benchmarks visant a montrer ces benefices, ni d'Intel ni des sites de hard, ce qui peut laisser penser que ton opinion est la bonne ("si c'etait bien il y aurait de la pub autour" sonne comme un argument raisonable).
Au final tu gagnes un multiplieur, donc grosso modo 10% de frequence. Si le mecanisme etait parfait et s'appliquait tout le temps ca ferait ~5% de performance en moyenne sur des applis single thread, a diviser par l'efficacite du mecanisme. C'est peut etre pour ca que les foules ne se sont pas precipitees pour le benchmarker...
Complètement HS mais je viens de voir ton grade, fefe :lol:
PeGGaaSuSS
23/08/2008, 01h11
Design final de la SmackOver : http://www.pcinpact.com/actu/news/45469-Intel-IDF-X58-SmackOver-DX58SO.htm
C'est con qu'il y'est que 4 ports DIMM quand les autres en ont 6 :
http://www.hardware.fr/news/9896/x58-asus-gigabyte-msi.html
Un article de chez Anandtech : http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382, on y apprend plein de choses intéressantes notamment l'utilisation de cellulles SRAM à 8 transistors pour les caches L1/L2 en revanche le cache L3 semble toujours utiliser une technologie à 6 transistors, Intel semble prendre très au sérieux la consommation au repos de ces cores et prend soin de réduire au maximum le leakage des composants en sommeil.
Un article de chez Anandtech : http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3382, on y apprend plein de choses intéressantes notamment l'utilisation de cellulles SRAM à 8 transistors pour les caches L1/L2 en revanche le cache L3 semble toujours utiliser une technologie à 6 transistors, Intel semble prendre très au sérieux la consommation au repos de ces cores et prend soin de réduire au maximum le leakage des composants en sommeil.
Waw, nehalem utilise des trucs découverts dans l'Atom :|
Waw, nehalem utilise des trucs découverts dans l'Atom :|
Des électrons ?
=>[]
Minuteman
23/08/2008, 22h27
Elle est bonne quand-même :p
Le L1 à 4cycles, ça sent un peu sous les aisselles IMHO.
C'est peut-être une conséquence du passage à la 8T-SRAM, dont je ne pense pas qu'Intel soit l'inventeur d'ailleurs (référence au commentaire sur l'Atom).
Dans le sens où ça joue sur les latences, ou dans le sens où ça les masque ? Parce que dans le deuxième cas ok (quoiqu'en single thread on s'en fout) mais dans le premier je vois pas.
Le SMT a un impact direct sur la latence, les ressources comme les Load buffers/Store buffers ont ete considerablement changees (comme explique dans l'article d'Anand), et il faut forcement de la logique pour garantir aucun deadlock entre les 2 threads, ou meme gerer les priorites entre les 2 threads, et l'envoi de donnees a qui il faut.
Des que les ressources ne sont pas partagees de maniere completement thread-agnostic SMT a tendance a complexifier le controle de maniere non negligeable.
Ca, combine a une amelioration du traitement des acces non alignes (demande du buffering et des rotators), un remodelage des TLB (qui sont sur le chemin du L1 chez Intel) et un passage du cache en Register File me semble tout a fait suffisant pour justifier 1 cycle .
OK, donc la latence supplémentaire est due aux modifications du pipeline induites par le SMT, mais pas au L1 lui-même ?
En general les cells 8T ne sont pas moins rapides que les cells 6T (les 8Tsont employees dans les bancs registres). Elles tiennent mieux la frequence aux bas voltages donc en pratique on pourrait presque dire qu'elles sont plus rapides (et plus grosses).
A mon avis ca vient du SMT et un peu des modifs des TLBs, apres cela importe peu d'ou ca vient ils semblent savoir exactement combien ca leur a coute en performance, donc le choix n'a pas ete fait au hasard et il y avait forcement un retour sur investissement.
Oui j'imagine qu'ils ont pas fait ça pour le plaisir de faire un truc plus lent ^^
Sinon j'ai vu des tests dans lesquels Nehalem se montrait un peu moins rapide que Penryn dans les jeux, certains imputent ça à une plateforme pas tout à fait mature, d'autres à la différence de taille du cache, qu'en penses-tu ?
Comme tous les changements d'architecture significatifs il y aura des cas ou a frequence egale l'ancienne sera plus rapide, mais en general isoles. Il y a eu des cas ou P4 allait plus vite que core2 mais on l'a vite oublie.
Les applis qui etaient optimisees pour un gros cache rapide (donc qui etaient optimisees pour favoriser Intel vs AMD) vont souffrir le plus, mais modifier un algo blocke pour une taille de cache X ou Y n'est pas la mort etant donne que AMD et Intel ont toujours eu des tailles differente donc c'etait une flexibilite a avoir. Maintenant que les hierarchies de cache des 2 constructeurs se ressemblent beaucoup (surtout Shangai avec ses 6M de L3) ca devrait meme simplifier la tache d'optimisation (et de maniere generale probablement meme favoriser les possesseurs d'AMD).
Il est possible que des plateformes soient immatures et que ca affecte les performances graphiques aussi, en effet le chemin vers les IO (le PCIe) a pas mal change avec le passage a QPI donc il est possible qu'ils aient des bugs la aussi, mais ca disparaitra a la release alors que les problemes de cache non.
Finalement il y a HT, si le scheduleur de l'OS merde lors du scheduling des threads il y a de bonnes chances de perdre de la perf sur des applis a faible nombre de threads (donc les jeux par ex). Ca c'est plus dur a dire comment MS s'en sortira. Ce qui est certain c'est que si un thread de jeu passe sur un CPU avec un autre thread en HT au lieu que ce dernier soit sur un autre CPU les performances devraient etre legerement inferieures a Penryn ou pas mieux.
Si cela se produit beaucoup, et c'est possible qu'a la release MS ne soit pas super pret (ca fait un moment que HT a disparu de leur radar donc je doute que Vista ait ete particulierement concu avec HT a l'esprit). Si c'est le cas tout les joueurs desactiveront HT et le probleme disparaitra.
Conclusion, je ne pense pas qu'il y ait de glassjaws qui ne soient pas fixes relativement aisement, mais je doute qu'il n'y en ait pas (je connais peu de CPUs qui n'en aient pas eu, et tous ne comportaient que des modifs mineures).
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. Tous droits réservés