Reprise du message précédent :
http://www.presence-pc.com/actuali [...] -EX-39758/
 
Rien à voir mais la dernière phrases

c'est bien beau les conférences... mais nous on veut des bench intel SB Vs Bulldo

Eh, il va falloir attendre, l'échéance n'arrivant qu'en Août (le 23 et le 24 plus précisément, d'après le site) .

Néanmoins c'est une bonne nouvelle, AMD va ENFIN présenter son Bulldozer ! On peut peut-être s'attendre à un benchmark, non ? Sandy Bridge fonctionne déjà (on en a déjà vu faire tourner Windows), je pense que pour Bulldozer ça ne devrait pas tarder .

+1            

mais en gras la dernière phrase de l'article de ton post en quote, et ....
... EFFACE-MOI CE LIEN PROFANATEUR DE TOMBE DE SATAN  

Personne ne me croira après    

 
   
 
Pas très légal tout ça, il y a des lois de propriété intellectuelle en vigueur, et ça marche même pour une phrase .

'ben pour sa kej'lui é dit

Je parlais de supprimer le lien .

Une question qui ne restera j'espère pas sans réponse... Une idée approximative de l'écart de performance entre un X6 1090T et la génération Bulldozer ?? 20% 50% 100%    
J'espère que mon attente sera récompensé, mon AMD 64 3000+ j'aime bien mais c'est assez lent  

A la louche, +132.6% de perfs entre un 1090T à stock et un quadmodule Bulldozer à la même fréquence (avec 8Mo de L3 pour BD) .

Du trollage de L ça  

 
T'a fini de me dire que je suis un L ?

Jamais  
/HS

Très mauvaises nouvelles en perspective .  
C'était ce que je craignais de pire, et c'est arrivé .
 
FTC Vs. Intel : l'anticoncurrence à l'amiable
 
Intel va gentiment glisser dans la poche de la FTC un gros chèque, qu'Intel se remboursera en moins d'un trimestre, sans aucune contrainte particulière . En gros, il va même pouvoir continuer à brider les CPUs AMD avec ses compilateurs ... Super .  
 
Il nous reste cela dit un espoir, l'accord étant confidentiel, on peut encore imaginer Intel reconnaître ses torts et promettre à la FTC de ne plus recommencer (toujours avec un gros chèque) .
Mais on peut toujours rêver .
 
Salopards de capitalistes .

 
  Comme d'hab la justice fait nawak...
 
C'est bien beau d'avoir des noms à rallonge avec des beau mots pour faire staÿle, mais ça sert à rien tout comme les décisions finale...
 
Un chèque et on s'refait la même c'est reparti..  

je part sur du 50-66% pour le même nombre de thread, donc 6 sachant qu'il pourrait y en avoir 8, le calcul est à vous

 
Ce qui est dommage, c'est surtout que c'est partout comme ça Pourquoi, mais pourquoi les gouvernements n'imposent-ils pas leurs lois et se contentent d'être passifs dans ces cas pareils ...  
 

 
Explique ?  
 
Avec un hexacore Thuban face à un trimodule Bulldozer, je ne suis pas sûr que ce soit la machine de démolition qui gagne ...
En tout cas les pipeline jouent en faveur de Thuban, par contre le reste est à l'avantage de BD : jeux d'instructions et mode Turbo .

Oui, enfin si on ne se référait qu'à ça, les processeurs d'architecture Nehalem seraient à la rue face aux Phenom II, or c'en est loin...
 
Il faudra en connaître plus sur l'archi dans un premier temps, et savoir ce qui a été amélioré.

 
J'ai pas les notions bien complètes justement, comment ça se fait que Nehalem soit plus perf que K10.5 (sans HT) ?

Tout ce qui est lié à l'exécution OoO est meilleur principalement, et c'est une chose qui peut changer énormément avec BD.

L'exécution Out-of-Order ?

Et c'est quoi, ça ?
Je ne comprend rien à ce que dit Wikipédia
EDIT : apparamment l'OoO sert à réorganiser les instructions afin d'optimiser leur traitement, c'est bien ça ? Il les optimise par rapport à quoi ? Merci

 
Out of order = Hors service ou en dérangement    
 
   
 
 

   
ça permet d'executer des tâches, qui arrive bien souvent dans le désordre, dans l'ordre dans lequel elles arrivent en effctuant uniquement la réorganisation nécessaire au calcul en multi-pass.
ça permet, notamment, un net gain sur les applis gourmande en calcul distant (Cf. 3D, processing, tabling).
à contrario, AMD, bien qu'il a récemment acquis la capacité de traiter de telles demandes, et notamment plus éfficace sur des structures de calculs simplifié (calculs ordonnés voire avec l'adjectif complexe) en entier comme en flottant, avec n"anmoins une hausse de la latence inter-coeurs, posant de gros problème de linéarité du traitement des infos..
En gros

 
Et ça n'est pas très au point chez AMD, c'est bien ça ? (je comprend ça vu que ma question partait de la différence K10.5/Nehalem)

L'idée, c'est d'exécuter les instructions dans l'ordre le plus efficace possible, en respectant bien sur le déroulement attendu du programme  
C'est à dire de trouver dans le programme de quoi alimenter les unités de traitements (il y en a plusieurs, capables de fonctionner simultanément) au lieu de les laisser se tourner les pouces.
 
Exemple : t'as un proc avec 1 unité pour faire des additions et 1 autre pour les multiplications, et les instructions suivantes :
(1) : a=b+5
(2) : a=a+7
(3) : c=c*5
(4) : d=a*c
1ère solution (sans OoO) : tu envoies l'instruction (1) à l'unité d'addition (celle de multiplication ne fait rien), puis la (2). Ensuite, tu envoies la (3) puis la (4) à l'unité de multiplication -> 4 cycles pour traiter le programme
2ème solution (avec OoO) : tu envoies l'instruction (1) à l'unité d'addition et la (3) à l'unité de multiplication, simultanément. Puis la (2) et la (4) -> 3 cycles
La (3) aura été traitée avant la (2), contrairement à ce qui est dans le programme mais ... ça n'a aucune importance. Par contre, on ne pouvait pas mettre la (4) en même temps que la (2), la (4) ayant besoin du résultat de la (2).
Le gain d'un cycle, il vient du fait qu'au 1er cycle, on a eu 2 instructions traitées en parallèle  
 
Ca a des limites. On estime il me semble qu'on peut trouver en moyenne 2,5 à 3 instructions "parallélisables". Inutile donc de mettre 10 unités dans le proc, on ne saura pas les exploiter.
Sauf à étendre ce concept en allant chercher le parralélisme dans ... un autre thread : c'est le principe de l'Hyper-threading

 
Explication très complète, merci beaucoup  
 
Par contre il existe encore une ou deux zones d'ombre ...
Pour la deuxième solution (avec OoO), vu qu'il y a deux instructions de chaque, ça doit faire 2 cycles logiquement, non ? Ou alors il faut un troisième cycle pour réorganiser les instructions dans l'ordre ?
 
Ensuite, dans tes exemples, il s'agit bien d'instructions+données, hein ? Je sais pas si c'est lié au fait que ce ne sont que des exemples, mais un CPU peut-il gérer des inconnues, des lettres ou encore effectuer des opérations aussi impossibles que celles que tu as mise ?
 
 

A, b, c et d, ce sont des registres  
J'ai mis des cas simples (opération entre registre et constante), c'est toujours plus complexe quand y a de l'adressage.
 
Dans le cas "avec OoO", les instructions (1) et (3) sont effectuées en même temps, durant le même cycle.
Par contre, on ne peut pas traiter simultanément les instructions (2) et (4) puisque la (4) doit attendre le résultat de la (2). On à donc les traitements suivants :
- cycle 1 : (1) et (3)
- cycle 2 : (2) (l'unité de multiplication ne fait rien puisque le proc n'a pu trouver d'instruction indépendante à exécuter)
- cycle 3 : (4) (cette fois, c'est l'unité d'addition qui n'a rien à faire)
 
Une remarques : ce que j'appelle ici "instruction" ne correspond pas directement au code compilé x86/x86-64. Les processeurs modernes commencent par effectuer un décodage de ce code source et le traduisent en une suite de micro-instructions, plus simples à traiter (c'est un merdier phénoménal, le x86 )

OOOoooK ! J'y étais pas du tout pour les lettres !  
 
Et genre ce sont quoi les registres à ce niveau-là ? C'est de la mémoire cache ?
Ou alors simplement les cases où sont stockées d'autres instructions démêlées préalablement

Les registres, ce sont les zones de données dans lesquelles travaille le processeur et sur lesquelles portent les instructions.
Y a 3 types d'instructions :
- charger un registre depuis la mémoire
- faire une opération impactant un/des registre(s)
- écrire en mémoire depuis un registre
(plus les sauts et les tests)
 
Mais là, mieux vaudrait que tu regarde un cours de programmation assembleur

Autant dire simplement qu'un registre est un scratchpad de capacité très limitée (1 donnée), ce qui diffère légèrement d'un cache
 
C'est la zone de stockage dont la latence d'accès est la plus faible dans le CPU.

j'aime beaucoup tes explications, mrbebert

J'ai un peu feuilleté Wiki, mais j'ai encore des progrès à faire !  
D'ailleurs, pourquoi il n'y a pas ce genre de tuto sur Hfr ?

Pcq le tuto est sur Wiki !

Mieux vaut que ce soit le site qui dispose de sa propre base de tuto qu'il soit obligé de renvoyer vers un site tiers pour les explications, non ?

Tu voudrais quoi, au juste ? Un tutoriel de programmation en assembleur x86 ?

Je commence tout juste à apprendre les bases du C en console, je vais pas m'attaquer à ça pour le moment

siteduzero je présume

Oui, c'est bien cela .  
 
Et maintenant, fin du HS .

petit joueur