Reprise du message précédent :

 
Oui oui, même AMD se trompe : http://www.freepatentsonline.com/20080209173.pdf  
Intel se trompe, AMD se trompe, DEC se trompe, tout ceux qui ont fabriqué un CPU se trompent sur la définition d'un core.... a part toi et le marketing d'AMD bien sur !  

So pour linpack

 
Sauf a ceux qui ne font pas de différence entre les marques  

 
Je crains que ca ne se termine comme ça en réalité.   Les fanboys se sont d'abord battu à coup de "fake" dans les leaks, puis à coup de stepping miracle qui ne représentaient pas les "vraies" performances, aprés le launch, ce sera sur les applis testées :-/

Moyenne générale

 
Linpack AVX précompilé officiel d'Intel avec modification hex pour qu'il se lance sur Bulldozer. Tu n'as qu'a remplacer GenuineIntel par AuthenticAMD et vice-versa dans le code. Ceci dit, je ne suis pas persuadé que les instructions AVX ait été utilisée réellement, j'ai modifié 2/3 autres trucs pour essayer de feinter

Donc en gros tu prends linpack compilé POUR sandy bridge (avec exactement les tailles de cache qu'il faut quoi) et tu t'étonne que ça marche bof bof sur bulldozer ?  

 
Rappel : On parle d'un test de power la.

 
j'ai répondu sur le sens du message de corleone    
 
Une moyenne générale c'est bien.  
 

Donc tu risque de sous évaluer le power du bulldozer.

 
Tu propose quoi précisement pour Linpack et Bulldozer ?  

 
J'ai testé avec plusieurs softs et j'ai choisi celui qui montait le plus haut en power : c’était linpack, optimisé pour Intel ou pas.

Il y a un code source pour linpack.
 
Le problème de linpack c'est que pour grappiller le moindre dixième de performance, les tailles des buffers de calcul sont calculés exactement pour remplir les caches, donc exactement pour un type de processeur.  
 
Évidement si ça dépasse d'un tout petit peu les performances diminuent.

 
Pédale d'accél. à fond et tu bloques une fonction hydraulique en buté, et là il va chauffer et consommer comme un salaud
 

 
C'est pas une réponse a ma question  

Et si on considérait un core comme étant le plus grand motif d'une architecture?
 
Bon avec un tel raisonnement le Q6600 devient un dual core (edit: quoi que, le E6600 étant un dual core même avec ma méthode de noob, le Q6600 est donc bien un 2+2, ça colle )

Je propose de ne pas utiliser linpack vu que personne passe ses journées sur linpack.
 
Je propose les mêmes benchs utilisés pour mesurer les perfs voilà tout. Comme ça ça fera un perf/watt.
 
On en revient toujours à la même histoire... on mesure la conso sur des benchs synthétiques genre prime95 & co là où les phenoms font jeux égal avec SB. Puis on mesure les perfs là où les phenom sont beaucoup moins efficace. Et après on dit que les phenom ont un mauvais perf/watt, sauf que c'est faux.

 
Ok. Le GenuineIntel suffit p-e pas si le dispatch utilise les numéro de modèles en sus
 

Non tu parlais des perfs plus haut sous linpack aussi

Tu nous remet les perfs/watts sous Cinebench qui disent pourtant le contraire ?

Non c'est juste que les jeux ont des threads asymétriques, ce qui fait que même si on a 8 threads, on utilise peut être en fait en pratique que 3 ou 4 coeurs.
 
Mais c'est aussi du au fait que le jeux vidéo c'est du temps réel, contrairement au cas avec des threads symétriques et qui ont un scaling parfait qui eux ne sont pas temps réel.
 
Il en résulte que pour les jeux vidéos le but du multithreading est de pouvoir faire le plus de choses différentes possibles dans une unité de temps. Cependant ça implique aussi que l'échelle ne soit pas trop large, le but c'est que tout le monde puisse jouer. Du coup en pratique aujourd'hui un jeu est conçu pour scaler de 2 à 4 coeurs +/-.
 
Les programmes non temps réel, le but eux c'est de pouvoir faire un traitement donné dans le moins de temps possible. Et là du coup, on peu scaler avec une infinité de threads ou presque suivant les algorithmes.

Ouais mais cinebench aussi avantage Intel et nuit gravement à la santé d'AMD    
 
 
 
 
 
 
 
A toute question, le fanboy trouve réponse    

Y'a t'il un soft qui ne nuit pas gravement à la santé d'AMD en matière de perfs/conso ?

Linpack c'est un algo. Donc oui on a des sources pour faire du Linpack.
 
Mais le Linpack qu'on parle communément c'est l'implémentation d'Intel dans sa Intel Math Library, et là forcement on a pas le source.

 
Ecoute le solitaire je pense  
 
(Penser quand même à désactiver toute les fonctions qui bouffent des ressources sous win)

Oui, c'est moi qui ne connais pas ma table de 6 (24 était déjà plus logique)
Mais 500mm², je trouve ça énorme pour du 28nm

 
Faudrait faire un petit effort...

Toute façon au Canada ce sont des faux

Euhhhhhh c'est qui le communément ?
 
Linpack est surtout utilisé pour classer les supercalculateurs et c'est pas la version Intel qui est utilisée Pour le reste c'est pas vraiment utilisé sauf la vieille version  Intel qui passe sous AMD comme teste de stabilité

Tu ne manques pas d'air

LinX c'est ca ?

Bah les benchs de stab. ils utilisent la version Intel...

Par exemple

C'est pas la vraie utilisation de linpack à la base, c'est à la marge...

 
et ce dernier indique les GFlops généré il me semble non ??? Il ne peut pas servir donc ni de test de chauffe/conso, ni de test de performance car "optimisé" Intel c'est ca ???
 
(corrigez moi si j'me trompe)

Y'a facilement 100-200 pages, une personne avait posté un slide, avec un historique de la taille des Dies de CPU de ces dernières années (je crois que ca remontait jusque avant le K6), par le plus grand des hasards, quelqu'un aurait gardé ce slide et pourrait le reposter svp?  

Marc, si tu veux je peux te créer un bench qui va tester de façon impartial le Buldo et le Core i7.
Évidemment, puisque je suis pauvre je vais utiliser un compilo gratuit: x86 Open64 Compiler Suite.
Note: Je devrait émuler les instructions FMA4 et XOP sur le Ci7 vu que ce proco n'est pas compatible avec ces blocs d'instructions.

Et on sera tous surpris !

Et Lapack n'est il pas plus sensé pour effectuer des benchs sur des systèmes dont la micro architecture est différente ?
=> http://www.netlib.org/lapack/
A moins qu'il n'y ait pas de programmes de benchs qui se basent dessus ?
 
The original goal of the LAPACK project was to make the widely used EISPACK and LINPACK libraries run efficiently on shared-memory vector and parallel processors. On these machines, LINPACK and EISPACK are inefficient because their memory access patterns disregard the multi-layered memory hierarchies of the machines, thereby spending too much time moving data instead of doing useful floating-point operations. LAPACK addresses this problem by reorganizing the algorithms to use block matrix operations, such as matrix multiplication, in the innermost loops. These block operations can be optimized for each architecture to account for the memory hierarchy, and so provide a transportable way to achieve high efficiency on diverse modern machines. We use the term "transportable" instead of "portable" because, for fastest possible performance, LAPACK requires that highly optimized block matrix operations be already implemented on each machine.

Draknet, sors de ce corps !!!

c'est ta première phrase pertinente sur ce topic !

en conversion brute ? p'têt pas non.

ça reste une étude préliminaire et sans drawing alors

Si vraiment t'es pauvre tu fait ça sous GNU/Linux avec gcc...