Reprise du message précédent :
Ma préférée sur x86
 
"Quoiqu'il en soit, le prescott ne semble pas être la "simple" évolution technologique qu'Intel voudrait bien nous faire croire, mais malgré tout, si le prescott inclura probablement dés sa sortie une arme de destruction massive anti-AMD caché au fin fond de ces transistors, il faudra attendre le bon vouloir d'Intel pour qu'elle soit activée..."
 
http://www.x86-secret.com/index.ph [...] sd&nid=691

A l'epoque le Prescott était pas aussi bien connu...
 
Fallait le deviner que le "double core" n'était autre que le doublement des ALU mais synchro avec le CPU plustot que des ALU à 2x la freq...

 
Lors de la sortie du Prescott, tout le monde s'interrogeait sur le nombre de transistors inutilisés.... http://www.hardware.fr/articles/48 [...] scott.html
 
Sachant que la news de X86 que tu cites est paru + d'1mois avant la sortie officielle du Prescott, et qu'à l'epoque personne ne s'attendait a un tel echec de la part d' Intel  

 
me semblait que c'était pour le support de l'AMD64

Quand tu developpe ton jeu avec le moteur novodex, tu fais en sorte que le gameplay soit le même pour tout le monde (qu'on ai une physx  ou pas). Si tu veux tirer partie du surplus de puissance apporté par la physX tu rajoute des effets qui ne changeront pas le gameplay comme des branches qui s'écartent quand tu t'enfonce dans la jungle (un peu comme sur la démo du CryEngine 2) ou des ragdolls super réalistes.
J'ai bien compris que le SDK d'AGEIA permet d'utiliser le physX pour la "physique de gameplay", le problème c'est que cette physique doit aussi tourner sur les machines de pauvres sans que le gameplay soit modifié. donc au final tu utilises le surplus de puissance apporté par le physX pour des trucs cosmétique.
 

C'est marrant, je suis passé à la fnac hier et je les ai pas vu
 

on saura jamais

A priori c'est ce qui en est resorti depuis ... et ça parait le plus plausible en fait en y reflechissant

D'une part on écrit pas "arme de destruction massive anti AMD" sur de simples spéculations.
D'autre part le site chip architect, tenu par des ingés cpu me semble t il, avait déjà réalisé depuis un moment (avril 2003, et x86 écrit son actu en décembre...) une excellente analyse du prescott, où ils spécifient bien que la seconde paire d'ALUs double ne peut servir à un super HT, mais bien au 64bits : "Second integer core for 64 bit processing  (not for multithreading) : [...] The reason that we can be so sure that the second core is not  used to boost the 32 bit Hyper threading capabilities is the scheduler. This unit is by far the biggest entity on the Pentium 4 die. It is larger then all the Floating Point, MMX and SSE hardware together. It is not only big but it also consist mostly out of very timing critical optimized macro cells laid out by hand. It takes a lot of time and effort to change the scheduler. We've looked to it in detail and concluded that it has mainly remained unchanged on Prescott's die. This means that the maximum uOp throughput remains six per cycle using the same dispatch ports as the Pentium 4."
http://chip-architect.com/news/200 [...] part2.html
 
Enfin peux tu m'expliquer, toi, ce qu'est un "cpu massivement bi-core" comme le prescott ? (je ne fais que citer les mots employés par the Mad ici même )
 

Il me semble aussi

C'est l'hypothèse qui a été faite par chip-architect un an avant la sortie du prescott en se basant sur des photos du die extraite d'une présentation powerpoint d'Intel et qui a été reprise par a suite par la plupart des sites de matos .  
Après, personne ne s'est posé la question de savoir où était passé les 16Ko de cache L1 de l'unité de calcul suplémentaire ou pourquoi les ingés d'intel ont adopté une solution aussi capilotractée plutot que d'"élargir" l'unité de calcul existante à 64 bits

LE problème est que le Netburst a été conçut uniquement en vue du 32bits (pour le 64, payez l'Itanic plein pot). Le succès du K8 fut une surprise. Intel a été FORCE de suivre AMD, et de sortir en urgence un Xeon 64bits.
Le p4 fonctionne avec deux ALUs qui tournent à deux fois la vitesse du cpu (donc 6Ghz sur un 3 Ghz, vous avez dit consomation/dissipation ?). Si elles tournent aussi vite, c'est parcequ'elles traitent uniquement les instructions courtes. Une ALU simple vitesse traite le reste.
Il n'était sans doute pas possible d'élargir les ALUs avec les fréquences atteintes par le prescott (3.8*2=7.6 Ghz...). Ils ont donc doublé le matos d'exécution. Le second cache est donc aussi là pour çà j'imagine.
 
Ils ont fait rapide et bourrin. Enfin c'est une interprétation perso.

Cette hypothèse c'est du n'importe quoi... Faudrait m'expliqué comment avec 2 ALU 32-bit on pourrais faire 1 ALU 64-bit en les couplants, sinon y'aurai longtemps qu'on serait en 64-bit voir même 128-bit tiens...
 
Les gars de chip-architect se sont trompé et c'est tout. Car pour avoir un support EMT64/AMD64 y'a pas besoin de tout refaire le CPU...
 
L'hypothèse de 2x ALU(1x) au lieu de 1x ALU(2x) est bien plus problable au final. Surtout qu'il me semble que c'est pas une hypothèse mais une affirmation d'une source Intel. Car à la base, le Prescott à quand même été pensé pour la monté en fréquence et est bien différent du Northwood.

D'une part tu te contredis toi même.
Ensuite :
1. Le p4 quelle que soit sa rév fonctionne avec 2 ALU double vitesse + une simple, c'est une donnée Intel connue depuis le Williamette.
2. Le 64bits existe depuis des lustres sur les RISC. Cà fait donc longtemps qu'on l'a. Ensuite Intel voulait cloisonner l'offre IA32/IA64 et AMD est venu jouer les troubles faits.
3. Je ne saurais pas entrer dans les détails, mais le K8 est dédié au 64bits depuis sa conception, pas le Netburst.
 
Enfin le gars de chip architect s'est trompé ? Je pense qu'en tant qu'ingé cpu, il en connait un petit peu plus que toi sur la question.

Le Prescott à 4x ALU simple vitesse. C'est pour ça qu'on a deux "pseudo" core d'excution l'un à côté de l'autre.

4 ALUs double vitesse !

Vous pouvez être sceptique, mais ça expliquerai plein de chose comme :
- la surconsommation excessive, même lorsque l'on est pas pas en mode EMT64.
- le "2e cache L1" qui n'est pas repercuté comme utilisable.
- le fait que les performances ne soit que malgré tout du même niveau qu'un Northwood contrairement à ce que l'on était en droit de s'attendre.

Le nombre de transistor du prescott est massif. La dissipation est massive. Tout est massif dans ce processeur. C'est pourtant simple, non?
 

Ca n'expliquerait pas les deux premiers idems. Quant aux performances du Prescott, elles sont probablement mises à mal avant tout par la latence des caches.
 
J'ai sous les yeux un PDF qui indique que le Prescott a le même débit en 64 bits et en 32 bits pour les opérations les plus simples. Par contre, le débit est moindre pour des opérations plus complèxes. Ca irrait plutot dans le sens du doublement des alu simples pour le calcul sur 64 bits, même si ça ne constitue pas une preuve absolue.

 
Tiens c'est marrant que tu dises ça, en tp d élec en 1ere année d école d ingé on a réalisé un espece de nano ordinateur 4 bits (avec 2 alus et des fils partout pour matérialiser les bus etc, un truc pour démystifier le hard, ca faisait compteur ou des opérations de base, le tout cadencé à la main) et quand on en mettait deux ensemble en joignant faisant passer le bit de retenue de l un à l autre ben ca nous faisait un ordinateur 8 bits...

Ca explique les deux premiers item car :
- Dans cette hypothèses, ces 4 ALU seraient alors toujours alimentées, alors que dans l'autre cas, en 32-bit elles pourraient être désactivée, or ce n'est pas le cas... et pourtant Intel est fort en économie d'energie.
- Ici le cache L1 ne seraient pas repercuté car ce ne serait qu'une copie de l'autre, afin d'eviter de trop modifier l'archi je pense.

 
oué mais pour la division, la multiplication et l'adressage, tout de suite c'est moins faisable (très pète couille rapidement)
 
 
 

 
et quand on a commencé a faire que des jeux -que- 3Dfx, que Direct3D ou OpenGl ?
oui même si le chip dépote, il y a beaucoup de chances que les premiers jeux soient alignés sur le budget de la solution logicielle.
 
bon de toutes façon c'est du wait & see, vu qu'on ne connais toujours la magnitude de perfs que peut développer l'asic face a une solution 100% logicielle.
 
ceci dit, pour peu que le chip soit efficace, ça peut déjà commencé a être utilisé par les serveurs dédiés de jeux...  
d'autant plus que ça pourrait être assez facile de répartir la charge sur plusieurs ASICs dû à la décomposition spaciale implicite et explicite de la scène physique.

Si la 2ème unité d'execution n'était utilisée que pour le 64 bits, elle ne chauferait pas en mode 32 bits donc la dissipation thermique devrait être moins élevée

ça prouve pas grand chose

En suivant ta superbe démonstration, on se demande pourquoi ils on a pas eu de CPU x86-64 plus tot rien qu'en allignant 2 CPU identiques
généraliser le comportement d'un CPU moderne à partir du fonctionnement d'un additionneur fait en TP c'est assez hasardeux.

mouais, ça me semble bancale comme raison. ça fait beaucoup de transistors gachés pour pas grand chose

Car inutile et entrainant un surcout ?  

Ca dépend s'il y a des mécanismes pour mettre en veille des morceaux du processeur, mais j'en doute. Le prescott n'a pas été conçu avec les économies d'énergie en tête
 

Le double L1 reste mystérieux dans le cadre de ton hypothèse, tout comme avec la mienne.
 

Ca tombe bien, le P4 n'utilise pas les alu dont il est question ici pour les opérations complexes
 

Mais s'il n'y avait pas de matériel rajouté pour le 64 bits, le Prescott ne devrait pas présenter les mêmes performances (latence et débit) en 32 et 64 bits. Or, pour les opérations simples, les performances sont identiques.

 
ben merde moi c'était un CPU 1 bit qu'il fallait concevoir
mais pas cadencé à la main , et pas d'implémentation physique (même si yen avaient qui traînaient, cartes électroniques à la con)
TP en binôme largement téléguidé puisqu'on nous faisait arriver tous au même truc, mais sympa qd même
 
le plus long et chiant, faire le diagramme avec mon binôme, chez lui sous corel draw -> des heures et un peu d'énervement

(me suis légèrement planté avec les portes logiques tout à droite, yavait un signal d'horloge à faire qui devait être 8 fois plus lent que celui fourni par le compteur, mais bon . pis pas entièrement documenté)
 
m'enfin pas mal le CPU nan?  
huit inputs/outputs et huit registres internes.
émulé sur un 386 sous DOS (avec debugger) avec l'I/O en port parallèle, et programmé en assembleur (avec EDIT. j'ai rajouté ansi.sys dans le config.sys pour avoir l'affichage sur 50 lignes ). au final, pilotage de perceuse électrique et petit train.
 
si je ressors cette vieille merde c'est que je resuis tombé sur le graphe, sur mon HDD, dans un "répertoire poubelle", et vu le temps que ça a mis à faire j'ai eu des scrupules à tout effacer..

bon.....j'aurais besoin d'infos,jusqu'ou un processeur peut nuire au bon fonctionnement d'une carte graphique,avez-vous des site,test a me suggerer ...merci  

pour la dissipation et perfs du Prescott, me suis toujours contenté des explications classiques :  
process 90nm sans SOI avec beaucoup de courant de fuite, caches plus gros mais à plus grande latence, et le monstrueux pipeline à 31 étages.
Intel voulait aller plus haut en fréquence probablement, au moins sortir le P4 à 4ghz pour sauver l'honneur mais ça a pas été possible

Le process 90nm d'Intel était très bon (cf Dothan) mais ne compense pas le fait que Prescott ait 2.25 fois plus de transistor que le Northwood.

effectivement, la devise d'HFR n'a jamais été aussi vraie
Personnellement, je ne crois pas trop au succès du physX, la solution me semble trop chère pour devenir vraiment grand publique.

C'est une utilisation à laquelle je n'avais pas pensé et qui pourrait être viable. Après je sais pas si Ageia rentrerait dans ses frais en n'équipant que les serveurs dédiés.

juste pour dire qu'il y a des malades dans ce monde:
http://www.youtube.com/watch?v=HUG [...] Dpantallas

il y a eu des P4M prescott donc les technos d'économie d'énergie sont inclues dans le prescott.

ben il fait l'adressage 64bits comment alors ?
Parce que c'est ce qu'il y a de plus intéressant dans le passage à une architecture 64 bits

Ben justement si les unités de calcul sont "élargies" pour travailler su 64 bits, elles peuvent égallement travailler en 32bits avec des performance identiques. Pas besoin de rajouter une unité d'execution pour ça.

Si le processeur est mort, la carte graphique ne peut plus travailler mais à part ça je voit pas en quoi il peut nuire à son fonctionnement.

 
oué enfin on verra. au pire si ça marche pas et qu'ils boivent pas le bouillon, ils auront toujours de l'expérience pour switcher sur une implémentation cpu/gpu... (ou de l'expérience a faire valoir pour un nouvel employé si ils font quand même plouf )

 
Assez hasardeux certes, mais tu noteras que ca n'avait rien d une démo et que ca tenait plus de l anecdote. Enfin bref je disais juste ça en passant, pas la peine de monter sur tes grands chevaux
 
Edit : auto modération.

nan mais le deuxième pseudo-core, c'est juste une ROM de 2Mo qui contiens une clé d'encryptage & d'identification pour le TCPA

Tient, mon voeux s'est réalisé mais ce n'est ni HFR, ni PPC, ni X86  
Microprocesseur, 3D, moteur physique. Qui est le chef du PC ?

c'est pas plus mal

Certains sites commencent à s'interroger.
 
 

Ah ah alors là va falloir m'expliquer. Je voulais faire un screen d'un ptit bug que je me tape, cf la taskbar :
 

 
Et pendant que j'étais dans irfanview, et même après avoir enregistré l'image et l'avoir rouvert avec paint, j'avais la vidéo qui apparaissait dans mon image  

c'est normal c'est de l'overlay on ne peut pas faire un screenshot d'une vidéo en overlay
 
Sois tu demande à ton player de passer par une autre sortie de rendu que l'overlay, sois tu uilises les fonctions de capture d'image de vidéo de ton player

Nan ça je sais que j'allais pas avoir d'image. Ce que je trouve rigolo, c'est que le fichier image comprenne bien le fait que ce soit une surface overlay.

Comment démolir sa propre thèse en 2 phrases.

ah oui ok, oui c'est assez fun comme effet