Reprise du message précédent :
la OUYA  

 
on va s'emmerdait cette année , quelle misère , un dernier soubresaut d'AMD vs Intel , ensuite ce sera Intel vs Intel    

http://www.overclockingmadeinfranc [...] seurs-amd/
 
Alors les pros-intel ?

 
Je dirais qu'un moment il faut arrêter la provoc?

bon voila bye bye kaveri l'A8 6500 monté et testé pour le fun sous bf3 la 1ere partie gros lag de 2 ou 3s surement des accès disque il n'est pas tout jeune en plus (2010) et la config n'a que 4go de ram
 
la 2eme c'était mieux mais en 720p low sur un 27" 1080p ca manque de netteté le 7600 avec 8go de ram aurait été plus à son aise mais quand ca ne lag pas à 30 40 fps ca reste jouable
 
bon de toue façon la frangine de fou de bf3 comme de l'an 40

Le lag c'est une latence réseau trop grande.

disont que ca ressemblait plus à des arrêts sur images   merde j suis mort  

un peu de lecture ne te fera pas de mal : http://forum.hardware.fr/forum2.ph [...] 0#t9078555

 
Le rédacteur ne vas pas plus loin qu'une bête description d'un bench en rajoutant des énormités.
Franchement, est-ce utile de poster ce genre d'article ?

MAIS le compilateur opencl (donc hsa ) vient a peine de sortir !!

opencl donc hsa ?

 
 
Le fait de compter les Compute Units (bloc de 64 Stream Processors) comme des Compute Cores (au même titre que les CPU Core) c'est AMD qui le dit, le rédacteur ne l'a en aucun cas inventé.
De plus il précisait cela juste après :
"Cette notation avait un goût de pur marketing jusqu’à ce que soient testées les performances en applicatif des APU Kaveri."
Le rédacteur ne dit aucune "énormités"

Pour rappel :
 

 
Ce n'est pas tellement "les computes core" qui me dérange.
Mais ta conclusion hâtives sur des benchs un peu plus douteux.
Il n'est pas possible de vérifier quelle version d'OpenCL tourne sur ces benchs et sur quelles cibles (CPU, GPU ou CPU + GPU ?).
Donc aucune comparaison n'est possible, ces benchs sont biaisés.

De toute façon, activer OpenCL uniquement sur l'APU/CPU qu'on a envie de mettre en avant... v'là le protocole en mousse.

 
juste une question , ce compilateur opencl fonctionne t-il pour du desktop classique ? genre FX 8xxx + HD 7950 , connaissant la puissance opencl de cette carte graphique , je vais faire un carton    

Bien entendu, ça fait des années qu'OpenCL tournent sur des CPU/GPU. La seule nouveauté de Kaveri à ce niveau c'est HSA mais tu as une grosse contrainte c'est d'être limité à de petits GPU... et HSA n'est pas encore disponible.
Si tu veux tester par toi-même, inspire toi d'HFR par ex.
 
edit: ya aussi GPU Caps Viewer qui te permet de lancer des démos sur ton CPU ou sur ton GPU (sur ma machine les perfs varient entre un facteur 2 et un facteur 20)

 
Merci , comme je pensais , j'arrive très loin devant (LuxMark 2.1/Sala)  (le double du meilleur GPU+CPU du test référence Steamroller/Haswell)
 
je vais voir pour les autres  benchs  
 
LuxMark 2.0 Sala(medium) / CPU=470/GPU=1787/GPU+CPU=2115

Quand je lis ça j'ai envie de pleurer.

Tout ce boucan HSA pour rien présenter, et dire euh bon, on prends opencl et on dit que c'est à nous XD

Moi je voulais des putins d'instructions x86-64 qui s'executent sur le GPU WTF

genre tu balances tes instructions SSE directement dans le GPU, et hop voilà, quitte à avoir une latence en plus mais bon avoir un débit de brute. Et sans rien recompiler bordel. Recompiler c'est 5 ans minimum pour que ça marche.

Regardez, il y a encore des gens qui installent des systèmes x86 en 32 bits alors que le premier CPU Athlon64 est sortit en SEPTEMBRE 2003 !!! ( 11 ans après c'est pas encore totalement assimilé ... )

( et les gains applicatifs sont proches de zéro. le vrai gain c'est la fin de la limitation mémoire ... )

Arrête de raconter des bêtises avec tes instructions x86_64 sur Gpu(tu reviens encore avec ça...).
 
Le but d'HSA est d'uniformiser les accès mémoire et de pouvoir utiliser gpu et cpu en "abstraction"  de la gestion de la mémoire dans le code.
 
Je ne crois pas que ma pensée est claire avec cette phrase. Disons qu'un traitement sur un même objet pourrait passer par le cpu et/ou le gpu sans devoir être dupliqué. Cpu et gpu ayant accès tout deux aux mêmes choses.
 
En principe avec du code adapté ça devrait apporter un certain gain...
 
 
Un autre gain du 64bits c'est qu'en 32bits les dates vont coincer en 2036 pour windows et 2038 chez les unix-like.
 
 
Le 64bits n'a pas un gain de l'ordre de zéro...déjà il faut avoir une appli qui l'exploite sinon ça ne sert à rien. Il y a plutôt un gain de 7-15% en moyenne et parfois plus.

en théorie en 64 bit y a déjà un gains car y a doublement des Registres par rapport à x86-32 bit, après j'avais ouïe dire que 64 bit utilisait plus les SIMD sur les flottants qu'en 32 bit, l'avantage du SIMD étant pour une seul instruction 64 bit ou 128 bit ou 256 Bit, on pouvait instrumentaliser plusieurs donnée 32 bit ou 64 bit ou 128 bit et cetera...
 
d'ou le gains théorie de performances, après bien sur si le compilo est con, ou qu'il est mal programme et que le code sources est à chier Forcément le Gain peut être nul ou très faible.
 
En suite y a un autre soucie, c'est 64 bit ne veux absolument pas dire plus performant, mais plus précis, en gros c'est comme de la Full HD par rapport à de la SD, donc en fait c'est plus lourd car plus détailler et plus jolie.
 
En suite je suis désoler, mais si tu fais un truc en 64 bit, pour dire je me la prête alors que se que tu veux faire aurai été aussi efficace en 16 bit autant le faire en 16 bit( genre calculer 2+2, ta pas vraiment d'utilité de le faire en 64 bit), ça sera forcément plus rapide qu'en 32 ou 64 bit, ceux d'autant plus vrai si les Unités de calculs travail en interne en 80 Bit de précisions ou en 128 bit pour les unités de calcul moderne voire 256 bit, mais à une époque pas si lointaine les FPU travaillait au mieux sur 80 bit par cycles d'horloge, après avec l'arriver des SIMD les FPU 64 bit puis 128 bit sont arriver.
 
 
 

 
Y a confusion la, les calculs FP auront une precision de 64bit en SSE2 et 80bit en X87,
que le CPU soit 32 ou 64bit ne changera rien a l affaire, en CPU 32bit les registres
sont quand meme 64-80bit...

de toute manière le code SIMD massivement parralélisable est très facilement portable vers du OpenCL
 
le gros problème demeure qu'on ne peux pas accélérer une application plus que le sa partie sériel. Si 10% du code est sériel, tu ne peux pas avoir plus que 90% de gain, peut importe le nombre de processeurs. Et le code sériels et ou avec branchement est encore très très nombreux et beaucoup de truc ne peuvent simplement pas être parallélisé.  
 
Les performances single thread sont toujours crucial aujourd'hui et c'est aussi une raison pourquoi on ne vois pas des 16/32 cores grand public. Il pourrais très bien le faire, mais au détriment de la performance single thread et ça serait catastrophique en général.

comme si on voulait faire un processeur 8 cores alors que 4 suffisent ?

 
Bien dit, Mieux vaut 4 cores très rapide que 8 cores asthmatiques.

En applicatif, plus de coeurs c'est mieux

non, si les applications sont pas prévues pour.
80 cores qui performent à 1/10 d'un core plus péchu, je suis pas sûr que ça soit mieux qui plus est

de plus en plus d'application sont prévus pour
et les jeux aussi ...

oui oui.
la stratégie d'AMD est la meilleure donc : des cores asthmatiques, qui surconsomment et qui prennent une place monstre sur le die.

 
Oui, c'est cela oui : .

 
 
  les cores jaguar des PS4 et Xbox One c'est du nougat !!!?
 
les FX8x00 aussi Bon quad modules mauvais eight-core!!

oui

En applicatif, il faut faire attention. Des processeurs 4 cores ne sont souvent pas très loin derrière des processeurs 8 "cores" ou 4 modules asthmatique.
 
Est-ce que ça vaut tous les transistors ? peux être que oui, peux être que non.  
 
Mais au final, tout ce qui se traite facilement sur plus de 4 cores risque de faire des merveilles en OpenCL/HSA/CUDA etc.
 
Donc il faut toujours améliorer les performances Single Thread. (d'ailleurs AMD la compris puisque la plupart de leur modifications ont porté la dessus sur le SteamRoller)

C'est pas comme si on était passé au multicoeur parce que les performances monocœur stagnaient trop  
 
Et que les poweruser n'en auront jamais assez de coeur.  
 
Plus il y en a  plus c'est rapide pour les applis multithreadées

on est au multicoeur parce qu'il est plus facile d'améliorer les performances globales via ça qu'en augmentant encore les performances single thread (Qui trop longtemps ont seulement reposer sur la puissance)
 
Intel l'a compris depuis plus longtemps qu'AMD que les performances single thread demeurait plus importante que le multithread (ce dernier étant tout de même important).
 
C'est pour ça qu'ils ont augmenté l'IPC de le coeur continuellement depuis les premier "core" (les "centrino" )
 
Personne ne bouderais les BD et cie s'ils avait de bonnes performances Single thread.  
 
Parce que de bonne performances single thread, ça aide en multithread (vu que chaque core exécute plus rapidement ce qu'il fait), mais l'inverse n'est pas nécessairement vrai.
 
Concernant les apps qui utilise plusieurs cores, elles sont tous destiné à être porter éventuellement vers OpenCL et cie. Autant Intel qu'AMD s'en vont vers un model avec GPU intégré. Ce n'est qu'une question de temps.

Euh, moi je raconte des bétises ... juste que j'ai un diplome dans le domaine ma cou*lle.  

Et c'est techniquement tout à fait possible, En changeant le micro-code des macro-instructions, et en mettant un lien physique entre le cpu et les unités de calculs du gpu autre que le bus  

Et temps que les calculs flottants seront poussif, AMD restera dans les choux sur nos applications.

Si AMD veut changer de voie et faire du ARM, grand bien leur fasse. Mais c'est pas demain la veille que les éditeur vont recompiler ça sur sur ce genre de machines. Les cpus ARM seront vachement utile pour fiare du serveur linux et basta. Et je pense que ça vise plus le stockage et les bases de données de petite taille qu'autre chose.

Bref pour le moment, j'aimerais bien les voir sortir une tuerie, mais de plus le temps passe et plus ça semble impossible.

au cas ou vous l'auriez fait exprès d'être nul au point d'en oublier les bases les plus élémentaires, les FX-8 sont des quad cores, des quad cores dual-cluster, donc dual thread. C'est du CMT, à contrario d'intel qui use du SMT. "Module" viens du service marketing, qui eux ne savent pas faire la différence entre de la mousse et macchiato, dans un café.

Diplôme <> compétence

Il n'y a pas forcement besoin de revolutionner l'architecture des CPU  et des GPU pour avoir une FPU qui marche bien.

Les projets d'AMD en matiere ARM, ca tombe bien, cela concerne bien cela, dans un premier temps.

... disent les mecs sans diplome.  

 
Et intel leur a fournit la licence x86 pour faire ça ?    
 
à nvidia aussi ?    
 
C'est bien beau la théorie mais la pratique est toute autre.
 
 
QUand aux arm là tu parles de boule de cristal, si les arm continuent de monter les éditeurs compileront pour arm ça ne fait aucun doute.

Bonne question sur l'aspect de la licence x86, mais j'avoue ne rien connaitre du detail de celle-ci.
Sinon, AMD rachete la division puce de VIA pour disposer de l'avantage de la licence Cyrix.

non
observation terrain, malheureusement...
(j'en ai des diplômes, pour ce à quoi ça sert au final...)