AMD annonce de nouveaux APU et se moque un peu du monde

Guinnness a écrit :



A la rigueur si j’étais méchant je dirais que dans l’optique de consoles “low cost” le choix d’AMD pour les CPU/GPU était parfaitement logique " />





Leur archi est positionnée sur la moyenne gamme, oui. Mais ils peuvent délivrer à prix comparable énormément plus de puissance que la concurrence une fois que les dévs auront optimisé leur code pour l’archi HSA.







vampire7 a écrit :



Tu devrais justement jeter un coup d’œil à ces “nouvelles instructions à la noix”. L’AVX2 apporté par Haswell devrait permettre un bon de performances aussi important que l’a permis le SSE2, grâce à des instructions qui étaient attendues depuis longtemps.





Ca fait plus de deux décennies que je programme et j’ai fait à peu près de tout. Y compris nombre d’applis où les performances étaient un vrai défi. Sais-tu combien de fois j’ai utilisé ces instructions SIMD ? Une fois. Une fois en plus de deux décennies. Ce fut la seule et unique fois où j’en ai eu besoin. A contrario la majeure partie de mes projets depuis plusieurs années incluent des systèmes massivement parallèles.



Alors, oui, cette unique fois-là c’était important. Pour les 0,1% de programmes qui font des calculs vectoriels par groupes de 4 ou 8 sur le CPU (de plus en plus rare), ça permet un joli gain. Mais autant dire que AVX2 me laisse complètement froid et que même dans dix ans ça n’aura qu’une utilité marginale.





A côté de ça, il y a les accès à la RAM qui continuent de se faire laborieusement en 64 bits par canal, d’où l’intérêt primordial de “ces caches démesurés”.



En fait les accès se font par 128 bits avec le dual channel et le cache est surtout là pour pallier la latence plutôt qu’un défaut de bande passante. Le problème c’est que malgré une multiplication par douze du cache, ces nouvelles instructions et des circuits beaucoup plus complexes, on n’a que ce facteur 3 sur les perfs. Parce que faire des pieds et des mains pour gratter les miettes n’empêche pas les rendements décroissants. Et ça ne va pas s’améliorer. Dans le même temps les performances parallèles ont été multipliées par 100. Alors quelle est la bonne direction ?





Tu n’as qu’à proposer ta super nouvelle architecture à AMD, je crois qu’ils en auraient bien besoin. " />



Je ne critiquais pas l’architecture d’AMD, au contraire puisque eux ont choisi une direction intelligente au lieu de se concentrer comme des boeufs sur les perfs mono-coeur.



Maintenant si en général l’industrie du CPU n’a pas (encore) pris la direction que je suggérais c’est parce que le couple industrie matérielle - industrie logicielle évolue leeeeeeentement. L’inertie est énorme. Et puis il suffit de regarder ce fil pour voir que les consommateurs ont une courte vue.

vampire7 a écrit :



Dans ce cas, pourquoi suggérer “Et remplaçons les par mille pentium 2 et unités SIMD.” ?





Par SIMD je ne voulais pas dire trois instructions spécialisées pour effectuer telle ou telle opération très particulière, je me référais aux unités de calcul du GPU, capables d’effectuer n’importe quel algorithme en parallèle sur N jeux de données.





Windows 8.1 nécessite aujourd’hui le SSE2, et une grande partie des applications réclamant des performances en profite, comme la cryptographie, les applications de traitement de l’image, la vidéo, certains jeux…



Bien sûr. Mais ça reste marginal.





Bon nombre d’algos ne sont pas vectorisables à cause du fait que certains résultats intermédiaires sont utilisés comme indices de tableau (très fréquent en crypto). Et c’est justement le gros changement apporté par l’AVX2.



Formidable nouvelle pour les trois algorithmes de crypto qui en auront besoin. Je suis sûr que çà accélérera de 30% la partie crypto de la gestion du réseau qui elle-même représente 10% de la gestion du réseau, qui elle-même représente 5% de l’activité de navigation. Soit un fabuleux gain de 1,5%.



Ou le minage de… Ah, non, on mine sur GPU.





Tout n’est pas parallélisable



J’ai longtemps dit ça, et puis j’ai réalisé que c’était faux. Oh ! Il y a des algorithmes non-parallélisables, comme les parcours de listes chaînées, mais ces algorithmes sont les solutions imaginées pour résoudre efficacement sur nos archis séquentielles des problèmes qui, eux, sont parallélisables. Il suffit d’utiliser un autre algorithme.



Plus j’y réfléchis, plus j’ai l’impression que, si, on peut bel et bien trouver des algorithmes parallèles pour presque tous les problèmes.



Bien sûr nous devrons conserver quelques unités séquentielles rapides. Mais gaspiller autant de silicium pour si peu de gains alors que dans le même temps on pourrait avoir mille fois plus de puissance, c’est ridicule.





et même quand ça l’est, il faut tenir compte des coûts en temps d’exécution dus à la synchronisation des threads, des accès séquentiels à la RAM, etc. Dans certains cas, paralléliser peut même donner un résultat plus lent.



Oui, si tu as quatre cœurs. Pas si tu en as mille. Quand tu en as mille, tout change. Soudain les plus prohibitives des solutions deviennent très rentables, tant qu’elles sont échelonnables (scalable).



Bon, cela dit pour utiliser mille coeurs tu as intérêt à avoir une autre architecture mémoire justement. L’évolution joue au tic-tac entre matériel et logiciel.





Je ne connais par exemple aucun algo de hash permettant le moindre parallélisme sur un seul flux de données.



Je t’invite à chercher “block-based hasing” ou “Merkle tree”. A vrai dire ce sont des compositions de hash. Mais je te rejoins pour dire qu’on doit encore inventer nombre d’algos.

vampire7 a écrit :



Windows c’est marginal ? Pourquoi réclamer le SSE2 comme prérequis à Windows 8.1 si c’est juste pour 2 ou 3 bricoles isolées ?





Pourquoi pas ? Tous les CPU depuis des années supportent SSE2. Ce n’est pas le gain qui est décisif, mais le coût ridicule.





La cryptographie aussi n’a plus rien de marginal, et la majorité des librairies et applications actuellement maintenues dans ce domaine utilisent au moins des instructions SSE2.

Les jeux aussi c’est marginal ? Tu en connais beaucoup, des moteurs 3D récents qui n’utilisent pas la moindre instruction SIMD ?

La lecture de vidéo est marginale aussi ? FFmpeg, présent dans les principaux lecteurs actuels, utilise un grand nombre d’optimisations SIMD.



Par marginal j’entends en termes de performances gagnées. Oui, tous les jeux utilisent SSE2. Mais ils l’utilisent à un ou deux endroits. Sans SSE2 les performances des jeux n’en seraient pas grandement affectées parce qu’ils ne se résument pas à un algorithme particulier mais à une riche collection d’algos et de structures de données. Même chose pour les autres applis.



Ton exemple de Serpent sonne bien mais en réalité c’est un cas particulier parce que 99% du temps CPU doit être occupé par un code de 20 lignes, ce qui est exceptionnel. Et de toute façon les perfs restent inférieures à celles obtenues sur GPU, de très loin.





Quant au minage… Litecoin utilise scrypt avec comme paramètres N=1024, p=1, r=1. C’est ridicule, ça enlève tout l’intérêt de cette fonction qui a justement été conçue pour être pratiquement impossible à utiliser sur GPU.



Oui, une exception faîte exprès pour ça. Doit-on optimiser nos architectures matérielles pour ce genre d’artifices ?





Ben moi, plus j’y réfléchis, plus j’arrive à la conclusion inverse.

Tu crois que c’est juste de la flemme de la part des développeurs s’il y a autant d’applications qui, malgré leur besoin en performance, n’utilisent jamais plus de 2 ou 3 threads actifs ?



Ils ne le font pas parce que la programmation parallèle est aujourd’hui difficile et dangereuse, j’en sais quelque chose. Mais ça ne va pas durer, les sémantiques d’isolation, de flux asynchrones, d’acteurs et la mémoire transactionnelle arrivent en renforts, et avec elles un support intégré du GPU.



Dans quelques années la programmation concurrente sera dans bien des cas très accessible et sans grand risque. Et puisque la différence de puissance disponible entre CPU et GPU se creuse à vitesse exponentielle, il ne fait aucun doute que la demande sera là. Ceux qui ne pourront pas s’adapter finiront au chômage. Ou chefs de projet.



Quant à l’appli avec trois threads actifs, c’est un mauvais exemple : c’est soit une simple tâche de fond plutôt qu’une tentative d’utiliser tout le CPU, soit des jeux limités par d’anciens matériels ou d’anciennes version de DirectX. Les jeux de demain n’auront pas cette limite.

Nithril a écrit :



Il ne faut pas non plus tomber dans l’exageration avec le “n’importe quel algorithme”. Une unité de traitement “GPU” est très loin d’être aussi polyvalent qu’un CPU.





Oui, même si c’est de moins en moins vrai.





La différence de puissance CPU/GPU se creuse à la même vitesse que les fondeurs ajoutent des unités de traitement. Rien de miraculeux à mon sens, cela reste du silicium…



Mais la loi de Moore EST miraculeuse… ;)

L’approche horizontale en profite (davantage d’unités de calcul), pas l’approche verticale.







vampire7 a écrit :



En comparaison, Serpent est au contraire bien plus complexe que AES ou Twofish, et même une version compacte prendrait entre 200 et 300 lignes de code.





Tiens en voici une sur moins de 100 lignes de code, dont un tiers seulement constitue la boucle d’exécution. Comme tous les algos c’est uen boucle compacte, un algorithme pur. Si tu peux accélérer une toute petite partie le résultat est tout de suite énorme. Sauf que dans la réalité ce genre de choses n’est pas l’application finale mais un sous-composant de l’application. Voilà ourquoi dans la réalité SSE2 et consorts sont quantité négligeable.





Tu pourras toujours dire que c’est à cause des transferts de données sur PCIe, que les APU d’AMD vont résoudre ça… Et je serai bien content qu’un jour ce soit le cas. Mais pour l’instant, quiconque a besoin de performance ne se penchera pas sur ce genre de puce.



Non, je t’ai dit et je te répète qu’un algorithme conçu expressément pour être inefficace sur GPU n’est pas représentatif. Ce qui est l’évidence même.





Quant aux perfs sur GPU, tu devrais peut-être jeter un œil ici. Et encore, si le gars avait disposé des instructions AES, son implémentation CUDA aurait été plus lente dans tous les cas.



Parce que le type utilise une antiquité (datant probablement d’avant le support des entiers sur CG) et que l’implémentation est sans doute mauvaise. Les implémentations modernes d’AES sur GPU crachent des dizaines de Gbps contre les quelques dizaines de Mbps sur CPU de ton lien. Aujourd’hui tous ceux qui font du déchiffrement de mdp en masse le font sur des boîtes à GPU contenant environ huit CG alignées. Les perfs sont tout simplement incomparables.

vampire7 a écrit :



AES n’a pas été conçu pour être inefficace sur GPU. Tu ne serais pas en train de confondre avec scrypt ?





La façon dont j’avais réorganisé les quotes m’a fait croire que ta citation concernait Serpent.





En implémentation software de AES, mon i7 2600k crache dans les 900 Mo/s. Et des “dizaines de Gbps”, quand tu ramènes ça à des octets, ça fait tout de suite moins impressionnant…



Je trouve que des performances des dizaines de fois supérieures pour le GPU alors que le CPU s’est doté d’une nouvelle instruction pratiquement juste pour ce cas, c’est au contraire assez parlant.





Si tu veux comparer une machine avec plusieurs cartes graphiques, fais la comparaison avec une machine multi-CPU. Sinon, comme tu le dis, c’est incomparable, parce qu’il n’y a rien à comparer.



Oui enfin les types auraient pu choisir d’aligner des CPU (s’ils avaient été stupides). Ils ont au contraire aligné des GPU.

vampire7 a écrit :



Pour le SSL, sachant que la taille des paquets IP est au plus de 1500 octets, on est largement en-dessous du point où utiliser le GPU est rentable. Et même en chiffrement de fichier (pratique plus courante que tu sembles l’imaginer : il n’y a qu’à voir ce qu’il s’est passé avec la fin de TrueCrypt), il n’est pas rare d’avoir des requêtes de 4 Ko ou moins.





Si tu dois en tout et pour tout chiffrer quelque chose de tellement petit que le lancement d’un thread GPU n’en vaut pas la peine (puisque c’est presque le seul surcoût restant avec HSA), de toute façon c’est insignifiant.



SI en revanche ton problème est que tu dois traiter de nombreux paquets de 4ko, le GPU peut tout à fait s’en occuper et avec HSA tu dois pouvoir laisser un thread GPU en attente pour le réveiller à l’arrivée d’un paquet, après quoi il pompera tous les paquets en attente. Aucune différence avec le CPU (voir ci-dessous).





Bien souvent, le parallélisme massif n’est efficace que sur des grosses quantités de données. Pour le GPU, c’est facile à comprendre :

• fonctions de synchronisation avec éventuellement réveil d’un thread (et donc chargement du contexte)
  


• appel d’une API qui elle-même va adresser une requête au pilote
  


• transfert des données de la RAM vers la VRAM
  
  Il n’y a que ce dernier point qui est résolu avec les APU. Étant donnés les temps d’exécution affolants des 2 premiers points, c’est peu, et du coup, intéressant seulement pour les grosses requêtes.
  
  
  
  Quelques petite remarques :
  
  * Attention à ne pas amalgamer APU et HSA. C’est l’architecture HSA qui supprime le troisième point, pas la vague appellation APU qui peut aussi bien désigner une simple superposition de CPU et GPU.
  
  
  
  * De toute façon les paquets réseaux ne sont pas traités par le thread réseau qui les réceptionne. Donc le changement de thread se produit aussi avec un traitement sur CPU.
  
  
  
  * Une bascule vers un autre thread n’entraîne pas forcément de changement de contexte : même inactif ce thread pouvait toujours occuper ce coeur, à moins qu’un autre thread n’en ait eu besoin pendant ce temps.
  
  
  
  * Reste uniquement le surcoût de l’appel au pilote (pas forcément nécessaire si celui-ci a tout compilé à la volée lors de la création du thread GPU) et le passage par PCIe pour l’envoi des commandes (même si ces commandes sont abrégées grâce à la mémoire partagée). Mais encore une fois, en simplifiant, peu importe le surcoût incontournable de la programmation parallèle quand tu as l’équivalent de 1k unités de calcul : ce surcoût est largement amorti.
  
  
  
  
  
  Au fait, comment as-tu utilisé les instructions SIMD la fois où tu as eu à le faire ? ASM ou intrinsics ?
  
  
  
  Asm. A vrai dire ne suis même pas sûr que les intrinsics correspondants existaient à l’époque. Et de toute façon les compilateurs étaient très mauvais dans leur gestion de ces instructions vectoriels il y a encore peu de temps, donc l’asm était la seule voie raisonnable.
  
  
  
  
  
  
  
  Nithril a écrit :
  
  
  
  Certain classes d’algorithmes sont tout simplement difficilement implémentable efficacement sur ce genre d’architecture.
  
  
  
  
  
  Comme je le disais plus haut, il ne faut pas confondre problèmes et algorithmes. Les algorithmes sont les solutions imaginées pour résoudre efficacement nos problèmes sur nos architectures séquentielles. Autrement dit ces algorithmes otn été conçus pour des architectures séquentielles. Et si certains de ces algorithmes ne sont pas parallélisables, ça ne veut pas dire qu’il n’existe pas d’algorithme paralléèle efficace pour résoudre le problème en question.
  
  
  
  Pour ma part je pense qu’il existe très peu de problèmes non-parallélisables. Mais je n’ai pas vu de travaux formels sur cette question. Si quelqu’un en connaît…
  
  
  
  Cependant je suis d’accord avec ta conclusion selon laquelle il faudra à la fois de la puissance parallèle et de la puissance séquentielle. Simplement je pense que la norme peut et doit être parallèle, même si je conçois que ça puisse sembler inimaginable au plus grand nombre aujourd’hui. Pourtant le chemin à faire au niveau des langages et technos n’est plus très long.
  
  
  
  
  
  
  
  paul161 a écrit :
  
  
  
  Déjà, un journaliste n’a pas à prendre parti comme on le voit trop souvent maintenant (des expressions comme “le cas le plus ahurissant” n’ont rien à faire dans un article de presse)
  
  
  
  
  
  Je ne suis pas d’accord, je ne considère pas qu’il s’agissait d’une prise de partie. Une liberté de ton, oui, mais celle-ci est acceptable vu les circonstances : le discours marketing d’AMD sent bel et bien le très réchauffé.

RRMX a écrit :



Personne ne signera pour ça, sauf forcé. MPI, pthreads etc sont de simples hacks qui réutilisent les vieux languages inappropriés de par leur style. Je suis un grand aficionado de la programmation (mais surtout, comme tu l’as souligné plusieurs fois, de l’algorithmie) parallèle, cependant je ne me fais guère d’illusion sur l’évolution future des pratiques.





A vrai dire je ne pense pas que l’avenir sera aux langages fonctionnels (ni davantage à MPI et compères). Faisons le point de ce qu’ils apportent :



* Des sémantiques vectorielles telles que map/reduce basées sur une composition par fonctions. Mais de nos jours le moindre langage impératif s’en est doté (c# / c++ / java chronologiquement). Et si les langages fonctionnels ont souvent eu des sémantiques additionnelles, c’est aussi le cas de certains langages impératifs (async/await en c#)



* Un monde immuable (à des degrés divers selon les langages). Ce qui garantit l’isolation, qui est le trait vraiment nécessaire au parallélisme. Sauf que le peu d’avantages de l’immuabilité par rapport à l’isolation (pureté et donc composabilité, testabilité et analyse) est loin de compenser les pieds et les mains qu’il faut faire pour manipuler des états mutables qui demeurent indispensables (monades, codata, etc). A mon sens l’approche et son coût ne sont pas satisfaisants et on peut trouver mieux.



* A part ça les programmes impératifs et fonctionnels sont de toute façon équivalents : on passe du premier au second via un graphe de flux de contrôle (CFG) et une passe SSA (single static assignment). Le reste n’est donc qu’une affaire de vue de l’esprit.





Si j’avais à parier je dirais que l’avenir sera plutôt à un langage impératif qui sera doté de :

a) Sémantiques isolationnelles.

b) Sémantiques transactionnelles couvrant les états mutables explicitement marqués comme transactionnels.

c) Diverses sémantiques asynchrones à la Erlang ou à la C# : acteurs explicites ou implicites, appels asynchrones vers une thread pool avec spécification de continuations, etc.

d) Des sémantiques déclaratives et réactives.

e) Des sémantiques pour gérer des unités de calcul hétérogènes.



Je précise au passage qu’on n’a pas besoin à mes yeux d’auto-parallélisation. Laisser le dév spécifier quand paralléliser via des sémantiques simples et de haut-niveau (boucles parallèles, appels asynchrones, etc) est simple et efficace.



Enfin, oui, tout ça demandera du travail. Mais de toute façon le développement logiciel nécessite de réapprendre constamment.