Reprise du message précédent :

ddr555 a écrit a écrit :     si on peut faire en sorte de placer les instructions de façon à améliorer la prédiction de branchement, mais là franchement ça devient une monstrueuse usine à gaz

 
ben oui c bien ca l'idee
19 niv de pipe, placement des instructions pour l'exécution
et la prédiction
c compliqué (et c un faible mot)
du coup qd on parle d'optimisation pour 686 je veux bien, on cree un compilateur pour une classe de processeur. Maintenant creer un compilo juste pour le p4 j'y crois pas
trop d'argent en jeu pour un resultat qui a bien moins d impact sur le public que de dire "mon bo p4 à 3,5Ghz" il est plus rapide qu'un povre proco a 1.6Ghz...
n'oublions qd meme pas que le p4 vise avant tout le grand public, il faut des données simple qui marque, pas des optimisations qui marchent
sur ce terrain il est clair qu'intel est le plus fort

ixemul a écrit a écrit :       DDR55: tu me l'a demandé, la voila   n'empeche, ca fait bien rire mon entourage

 
rhooo, c'est petit ça.....
on n'est pas là pour se fighter ixemul ...

PicaTEAM!!! a écrit a écrit :     ben oui c bien ca l'idee 19 niv de pipe, placement des instructions pour l'exécution et la prédiction c compliqué (et c un faible mot) du coup qd on parle d'optimisation pour 686 je veux bien, on cree un compilateur pour une classe de processeur. Maintenant creer un compilo juste pour le p4 j'y crois pas trop d'argent en jeu pour un resultat qui a bien moins d impact sur le public que de dire "mon bo p4 à 3,5Ghz" il est plus rapide qu'un povre proco a 1.6Ghz... n'oublions qd meme pas que le p4 vise avant tout le grand public, il faut des données simple qui marque, pas des optimisations qui marchent sur ce terrain il est clair qu'intel est le plus fort

 
pour moi c'est la complexité de ce genre d'optimiseur qui me parait démentiel, plus y'a de niveaux de pipeline plus il faut prévoir de cas de figure et là  

 
oui, enfin AMD devient bon aussi dans le domaine marketing "mon XP PR+++ il accélère vos gravures sur internet"

 
j'lai pas entendue celle là    
clair que c'est pas top comme truc, mais bon si ils font ça c'est pour se mettre au niveau d'intel sur ce terrain là  

Je compile tous les jours en 686 pour la simple et bonne raison qu'en dessous, les perfs sont moindre sont une seule et meme machine...
 
Pour le P4, ben, pô grave pour l'instant, j'suis patient de nature (cf ma config), j'ai pas encore l'utilité de compiler pour P4, le parc de machine n'est pas encore assez consequent

Allez xmul, fait moi rire vraiment. Décris moi en qq lignes le fonctionnement d'un pipeline (pika, le P4 c'est 20 pipelines, l'XP c'est 10).

ixemul a écrit a écrit :   DDR55: tu me l'a demandé, la voila n'empeche, ca fait bien rire mon entourage

 
bon on va faire dans le simple : http://www.hardware.fr/html/articl [...] 249&page=3
 
le pipeline sert a decompose une instruction complexe en plusieurs instructions simple (en gros)
 
mais la ou ddr555 n'a pas tord c qu'une des limites des la montee en frequence de proc vient justement des unites de pipeline chargées d'exécuter leur instructions simple... elles fonctionnent jusqu'a une certaine vitesse et apres rideau
 
du coup en augmentant la profondeur du pipeline, a instruction constante, l'unite de pipeline a plus de temps pour executer sa tache et on peut donc continuer a monter en frequence.
Les problemes apparaissent qd il faut vider le pipeline (branchement incorrect par exemple) et il faut alors le remplir avant de recommencer...

 
c'est clair qu'en 3 lignes c'est pas facile, fo rien oublier
j'aurai pu aussi expliquer l'historique des processeurs et l'intérêt de faire un pipeline, mais 3 lignes c'est vraiment très short  

 
c'est clair qu'en 3 lignes c'est pas facile, fo rien oublier
j'aurai pu aussi expliquer l'historique des processeurs et l'intérêt de faire un pipeline, mais 3 lignes c'est vraiment très short  

taratata, xmul il s'y connait, il sait lui comment fonctionne un proc alors attendons les explications de notre petit robert de l'informatique, juste pour rire

ha ben merde
j'ai gache le suspens!

Au fait le proc 32/64 bit d'AMD a une profondeur de pipeline de 12

maxi17> pour les problemes de GF3 (que je connais sur du via), 2 choses:
 
- d'une part c pas limité aux chipsets via
- d'autre part, c plutot nvidia qui serait a blâmer vu que la stabilité est variable selon les detonator, et ensuite parce que lorsqu'on sort un produit ultérieur a un autre, on s'assure que ce soit compatible a 100%. nvidia est toalement coupable a mon sens, meme si via bosse sur le probleme egalement

ouai ouai ouai  
tout ca pour dire qu'on a bien devié du sujet...
 
et ce bench du northwood alors?
question (j'ai des doutes) : le northwood il apporte koi?
512Ko de cache et fsb 133 c ca?
plus plateforme ddr bien entendu
 
j'ai bon ou pas?

tetechatte, si tu es là, j'ai commencé a reflechir sur ton pb de benchs entre le P3 et le K7 à 350 Mhz sous une compil linux. Mais je manque d'infos concernant le K7 et le P3. Le K7 avait quoi comme cache L2 et à quel vitesse était la sram ? Ton coef etait de 3.5 avec un bus à 100 mhz et une mémoire à 100 ? Idem pour le P3, c'était le P3 à 512 ko de l2 à 1/2 vitesse avec gtl+ à 100 et mem à 100 ? Merci de répondre aussi à ca : dans tes benchs, à 350 Mhz, tu avais P3=2*perf K7 mais à 700 tu avais K7>P3 ?
 
Parce qu'à la base, le l1 du K7 a un bus de 64 bits, une latence de 3 cycles, une taille de 64 ko pour les données. Son l2 a une latence de 7*coefficent du cache et un bus de 64 bits, et la ram une latence type de 7.1.1.1 en premier acces aléatoire avec un bus 32 bits. Le hit rate moyen est de 95% sur L1, 80 % sur L2. Reste plus qu'a retrouver qq chiffres pour confirmer tes benchs.

 
Euh jean mimi c'est pas celui qui fait des volants genre moumoutte au volant c'était celui qui régle de façon plus fine
   
 
je pense que si y avait pas AMD, Intel dormirait beaucoup
et vis et versa sauf qu'Amd dort pas trop c'est eux les
outsiders non de diou
 
regardes le choix d'intel prendre de la DDR ce qu'Amd a pris le first leur sera profitable, c'est pas parce que on est le premier que l'on doit ne pas avouer ces erreurs de choix, foutre des procés au petit concurrent Via parce qu'il va sortir un chipset gérant de la DDR pour P4 avant Intel, c'est petit
Et je suis sûr Qu'intel gagnera bq + Avec la montée en Fréquence
de la ddr qu'avec leur Rambus avec bouchon intégré
 
Peugeot vends + de voitures que Jean mimi mais cela ne les empêches pas de rappeler les tutures qui ont des défauts

 
euh non ...
c'est la gravure plus finer (0.13).
la mémoire c'est pas le proc qui gère ça mais le chipset.
donc le northwood n'a rien à voir à ma connaissance avec la DDR.

k7 => 512 ko de L2 a 1/2 ou 1/3 ché plu ( depend de la frekence du proco )

Ben justement, selon le modele, je crois jusqu'a 700 le K7 était à 1/2, puis à 2/5 jusqu'à 850 et 1/3 jusqu'a 1000 mais j'ai besoin de savoir le coef de son K7 au moement du cache (avec la BAB on agissait sur le coef et sur ce coef il me semble)

 
en effet c con la ddr evidement c le chipset
donc gravure 0.13, 512Ko cache
et la FSB elle bouge ou pas?

 
c ca

A pika, trace cache 12 ko, data cache 8ko (idem), cache l2=512 Ko, bus quadpump d'abord à 4*100 puis au mois de mars 4*133=533 Mhz. Le reste RAS

 
precise komprend rien

 
à ma connaissance non.

northwood, ca veux pas dire processeur en bois du nord. Je savais pas que Ikea faisait des proco  
 
 
       

 
à 133 en mars ??  
une nouvelle évolution du chipset alors ou c'est déjà géré par le 845d ?

Normal c'est limite HS mais pas trop. Tetechatte a fait la lecon à ddr555 concernant les pipelines du P4. Il a pris dans un autre post l'exemple d'un K7 et d'un P3 qu'il avait underclocké à 350 et avait trouvé que les perfs du P3 était 2*supérieur au K7. Par contre, les perfs du K7 augementait avec l'augmentation de la fréquence. Tout cela pour dire qu'à 3 Ghz, le P4 pourrait subir le même sort, c'est à dire avoir une 'scability' >1 du P4 et expliquer pourquoi aujourd'hui ce proc est une daube.
 
Je sais c'est un peu HS mais bien dans la ligne des benchs P4

 
c parait fortement improbable ...

 
pas encore le 133

 
il est impossible quelquesoit l'architecture d'avoir un gain en puissance supérieur au gain en fréquence, ça c'est ce que je dit et que tetedeiench contredit

 
pour moi c'est impossible

 
j'osais pas le dire  

Tangzzz a écrit a écrit :     j'osais pas le dire

 
le fréquence d'horloge conditionne le fonctionnement du processeur, 50 % de hausse, le proc traite 50 % d'info en plus et ce quelquesoit l'architecture du proc, on peut certes faire moins, mais jamais au grand jamais plus, ou alors celui qui invente ça il fait fortune  

Sachant qu'a l'époque un K7 500 etait à peu près équivalent à un PIII 550 , ça veut dire qu'en 150 Mhz le PIII n'augement presque pas sa puissance de calcul alors que le K7 l'explose.
 
Je trouve ça très bizarre...

[edtdd]--Message édité par seblamb--[/edtdd]

thecoin a écrit a écrit : northwood, ca veux pas dire processeur en bois du nord. Je savais pas que Ikea faisait des proco

Ben,et le bureau de Windows,il est pas en boi?s
 
d

 
en condition normale c'est impossible les résultats de tetedeiench, je ne met pas en doute sa bonne foi, il doit y avoir anguille sous roche c tout

[edtdd]--Message édité par ddr555--[/edtdd]

bah ca peut etre les benchs qui etaient foireux
sinon je me demandais juste pourkoi avait un comparatif a 350Mhz et pas a 500Mhz?
a mon avis y a une couille dans la facon dont les frequences de ces procs sont descendues...

 
surtout que le multiplicateur 3.5 n'a jamais été officiel sur athlon, je pense qu'il n'ont pas testé et que le résultat des benchs vient de là