Reprise du message précédent :

slyde a écrit a écrit :       Le PIV est bon graçe à sa bande passante, au contraire elle ne l'handicape pas. J'ai codé des trucs hautement bp intensifs qui sont plus rapides sur systèmes DDR et particulièrement sur PIV.   Par contre le pipeline à 20 niveaux reste handicapant, parce qu'a mon avis il y a peu de programmeur qui doivent et peuvent ingurgiter un guide d'optimisation de 933 pages parfaitement. Il suffit de regarder des perfs brutes FPU non SSE2 sous Sandra et la conclusion est rapide

 
Minute, on a pas le meme point de vue
 
le PIV serait une bombe enore + majestueuse si on avait de la mémoire + rapide que celle actuelle... qui coute déjà cher ( RDRam), d'ou mon post

slyde a écrit a écrit :     J'ai aussi codé des trucs hyper pas performant sur Athlon alors que ca l'était sur PIII   "Simple" manière d'organiser le code et optimisations utilisés par le compilo.

 
probleme :
 
Athlon 600 Slot a @ 600 (juste changé la fréquence) : indice : 200 Minimum.
 
Intéressant non ?
 
Et quand je cause de kernel, je parle compilation du kernel (évidemment)

slyde a écrit a écrit :     J'ai aussi codé des trucs hyper pas performant sur Athlon alors que ca l'était sur PIII   "Simple" manière d'organiser le code et optimisations utilisés par le compilo.

 
Avec quel compilo ?

mais entre 133et 166 de fsb  

 
bon ben je retourne coucher moi.
 
Qu'est ce que j'ai encore pondu comme connerie
 
Dans mon souvenir les perfs du PIV étaient encore tres dépendantes de la memoire... bref.
 
Par contre, le coup de l'athlon, j'en suis sur : meme marc avait pas su répondre a l'épok.

 
oui je doute aussi...

 
Ouh la, pas du tout ce que j'ai lu. Va voir les tests DDR400 sur x86-secret. La différence en FPS est plus grande que ca

 
Ah ben je comprends mieux alors

je vois une nette difference entre un fsb de 16 et de 220
jai reussi a lancer des games a 220 cas2 synchro bien sur et jav une bonne diff
gain + net avec les futurs procs

Sois dit en passant, les compilos intel font effectivement un excellent travail...C'est sans doute aussi pour ca qu'ils peuvent se permettre de lancer l'Itanium et qu'AMD se voit contraint de garder des inno strictement hardware...
Juste une question d'argent et de poid

 
ben le cache du PII est cadencé plus bas... donc voilà.
 
Mais mine de rien ca m'a fait halluciner de remplacer mon athlon undercloké par un PII et de gagner en perf grave

attend je v foutre des benchs de litanium 1GHz
faut que je retrouve ca

 
Prend les en 64 bits que ca a ait un intéret par rapport à ce que je raconte...:sarcastic:

Ca va arracher

 
Ah, je me disais aussi que j'étais pas si con que ca

slyde a écrit a écrit :     De bons compilos optimisés AMD, j'en ai pas vu des masses. Enfin si, l'intel   Parce que rien qu'en changeant ma manière de coder les perfs sont remontées sur les K7.   J'ai testé deux méthodes pour un traitement repetitif :   - Beaucoup de boucles et utiliser 2 registres mm. - Peu de boucles et utiliser tous les 8 registres mm.   Je vous laisse deviner laquelle est plus rapide et laquelle est catastrophique par rapport au PIII.

c tj mieux peu de grosse boucle en k7

ça va cooter bonbon tout ça

slyde a écrit a écrit :     De bons compilos optimisés AMD, j'en ai pas vu des masses. Enfin si, l'intel   Parce que rien qu'en changeant ma manière de coder les perfs sont remontées sur les K7.   J'ai testé deux méthodes pour un traitement repetitif :   - Beaucoup de boucles et utiliser 2 registres mm. - Peu de boucles et utiliser tous les 8 registres mm.   Je vous laisse deviner laquelle est plus rapide et laquelle est catastrophique par rapport au PIII.

 
Marrant, parce qu'au niveau du compilo pur, VC++, me sort quasiment toujours le même code assembleur avec un code C++ que mon code soit crade ou optimisé. Cela dit, j'ai jamais fait de test très poussé en cochant des cases d'optimisation ni d'ailleurs en changeant de langage...
Il faudrait comparer tout ca avec les compilo Intel etc.

slyde a écrit a écrit :     raté

  ca m'etonnerai le contraire...

je comprend rien a vos histoire de codeur cai normal ???

On veut savoir le prix

Ben les gars disent qu'AMD a joué la prudence sur ce coup là et que le radiateur n'était pas trés chaud après utilisation.

salut,
 
a mon sens le P4 doit petre amélioré sur 3 eléments.
 
l'architecture cache :
 
la taille du cache L1 fait qu'il reporte presque tout le boulot du cache sur le L2, or celui-ci est trop lent pour obtenir un bon niveau de perf en particulier en calcul. 3 sols
 
1 - augmenter la taille du cache L1 au moins 32 Ko et augmenter le cache L2 1Mo
 
2 - Augmenter la vitesse du cache L2
 
3 - faire sol 1 + 2 , la ça devrait fritter un peu mieux.
 
Les conditions de branchments.
 
Le P4 c'est vraiment pas ça, j'irai pas jusqu'a dire qu'il mouline dans la semoule, mais dans certaine situation il est dépassé par les evenements. La seule solution viable c'est d'améliorer leur algo statistique de branchement.
 
 
Vitesse de calcul FPU/SSE2.
 
Elle est dépendante de l'organisation et de la vitesse des caches, donc dans quelle mesure les changements possible des chache peuvent influer positivement dessus je ne sais pas trop, mais je crains que ça ne soit pas suffisant. refaire une FPU performante ? augmenter le nombre d'unités de calcul ? Là je ne voie pas comment faire.
 
 
Dernière chose, ne vous attendez pas a des miracles de la part de hyper-threating. C'est efficace pour des bon gros threat, mais pour des touts petit thread répétitif, je n'y crois pas trop.

lol oki  

slyde a écrit a écrit :     Ah non j'ai ressorti mes sources et c'est effectivement en bloc que ca va + vite (utiliser les 8 registres)   Par contre avec deux registres c'est -30% dans la gueule

merci kan meme a mon cerveau de ne pas s'etre laisser influence par ton message douteux  
sinon @ 800 je pense 70/80 watt

http://www.hardware.fr/html/news/i [...] ws_id=4893
 
Moi j'en pense ca
 
mmm faut que je rajoute un Wait & See !

a kuake 3 le 1.6a fait si peu  

faut arreter vr-zone cpull    

Problème : augmenter la taille du cache L1 c'est augmenter sa latence, s'il est si petit c'est pour conserver cette latence à 2 cycles justement contre 3 sur les Athlons. 1 cycle ça peut sembler ridicule mais si intel a fait tellement d'efforts pour atteindre un tel chiffre c'est que ça doit être utile étant donné l'architecture Netburst (ce qu iserait pas étonnant vu la longueur du pipeline). Pour le cache L2 pourtant celui du P4 est en déjà théorie nettement supèrieur à celui de l'Athlon (je n'ai plus les latences en tête) et même à celui du PIII Coppermine qui était déjà excellent, dans la pratique les différences avec le PIII ne sont pas aussi flagrantes qu'on aurait pu y croire par contre il s'avère meilleur que celui de l'Athlon.

magicpanda a écrit a écrit :   faut arreter vr-zone cpull

pkoi  

MONTECITO  

cpulloverclock a écrit a écrit : MONTECITO

ba ouai  
vivement le 0.003 micron et les 20ghz promis par ibm

le p4 devrait largement bouffer le k7 en opengl

magicpanda a écrit a écrit :   le p4 devrait largement bouffer le k7 en opengl

 
Le truc qui veut rien dire ...

Ce que j'aime bien avec intel c'est qu'ils comparent toujours leur gamme Itanium aux Ultra Sparcs, je veux bien que les US soit leur plus gros concurrents aux niveaux des ventes vu que Sun est leader sur le marché des 64 bits mais niveau perfs s'ils voulaient nous impressionner ce serait à un Alpha ou encore mieux à un POWER4 qu'il faudrait comparer leur Itanium

enfin un p4est meilleur q'un xp a pr egal sans o/c a quake3
c d'ailleur l'un des seul ou c comme ca

cf:http://www.onversity.com/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&M=informat&O=touslesmots&P=a1101#121
 
alors, il est bon ou pas cet algo de branchement?

slyde a écrit a écrit :     Quant tu fais une demo commercial, t'a pas l'habitude de descendre ton produit   En tout cas cette demo est très prometteuse, reste à voir en pratique à combien ils sortiront en fréquence l'an prochain.

helas    

magicpanda a écrit a écrit :   enfin un p4est meilleur q'un xp a pr egal sans o/c a quake3 c d'ailleur l'un des seul ou c comme ca

 
Ouais a 2.0a vs 2000+ et au dessus
 
En dessous non. Et en plus tecchannel ct pas un northwood mais un willi
 
Sinon, ca veut rien dire plus rapide en OGL ... l'API n'a rien à voir la dedans (enfin, pas beaucoup).