Quand tu porte naivement du code du PC vers la X360 et la PS3, tu verra des perfs beaucoup plus importantes sur la X360 que sur PS3.
a propos ce que disent ces gars la avec folding@home:
20x ca me parait quand meme beaucoup, mais pas improbable. Le genre de calculs qu'ils font s'y prete peut-etre bien.
Autant la PS3 et la X360 sont des plateformes bien definies et previsibles niveau perfs, autant quand ils parlent de "PC", c'est on ne peut plus flou.
pour vous donner une idee, la j'ai sous la main un soft qui affiche des effets de particules dans la boite ou je bosse.
ca a ete optimise sur PC, X360, et PS3/SPU.
je viens de mesurer le temps pris par chacune des machines pour calculer un truc donne (le billboarding de 110 000 particules, avec generation de 4 positions/couleurs/texcoords par particule, puis l'ecriture de tout ca dans un vertex buffer pour l'affichage).
Ca donne (avec en plus la PsVita, for the lulz
):Machine
| Nb Threads Hardware | Temps (millisecondes) | Gain de perfs de la PS3 | |
| PC-Core2Quad | 4 | 4.0 ms | 6.6x |
| PC-Corei7 | 8 | 1.7 ms | 2.8x |
| X360 | 6 | 4.5 ms | 7.5x |
| PS3 | 1 PPU | 18.0 ms | 30x |
| PS3 | 5 SPU, sans SIMD | 11.0 ms | 18.3x |
| PS3 | 5 SPU | 0.6 ms | 1x |
| PsVita | 3 | 40.0 ms | 66x  |
Si vous voulez plus de details sur le pourquoi du comment:
la PS3 a un seul coeur PowerPC hyperthreade (donc deux threads peuvent tourner en parallele dessus) : le "PPU".
la X360 a exactement le meme, mais en triple (3 coeurs -> 6 threads en parallele).
en plus de ca la X360 a une poignee d'instructions en plus (notamment pour les dot-products, et des instructions de pack/unpack des types D3D (dont des float16 bits)), qui font que ca peut encore un peu accelerer certains types de calculs compare a la PS3.
Mais...
a cote de ca, si on utilise les SPU de la PS3, c'est une toute autre histoire. yen a 6 dispos. (mais en pratique vaut mieux en utiliser que 5, l'OS s'en reserve un, et preempte le thread-group qui tourne sur son SPU reserve toutes les 5 ms, et ca preempte tous les autres, donc au final c'est mieux d'en chopper juste 5 sur les 6. heu bref. on s'en fout, meme avec juste 5, ca poutre la X360).
on peut voir un SPU comme etant un mini-CPU super bourrin dans tout ce qui est calcul brut, et assez nul a chier dans le reste
(genre des algos recursifs, des algos ou ya plein de tests, d'appels de fonction, de calculs scalaires, bref...)tous les CPU recents ont un set d'instructions "SIMD", (Single Instruction, Multiple Data), qui en gros sont des instructions qui operent sur des "vecteurs" de nombres.
par exemple, le SIMD sur PC/x86, c'est le SSE. un registre SSE contient 4 nombres reels 32-bits. la ou il faudrait en temps normal 4 instructions pour les additionner entre eux, en SSE on peut en une instruction, additionner deux vecteurs de 4 nombres chacuns. Bref, c'est tres tres utile et efficace pour optimiser.
Certaines architectures (genre la wii-u), ont des vecteurs SIMD de deux elements seulement, d'autres (AVX), en ont 8, d'autres (NEON, ce qu'il y a sur les iphone,ipad,ps-vita), ont un mix de 2 et 4 elements par vecteur. Sur les PC, avant le SSE, il y avait le MMX, qui en avait aussi 2 par vecteur.
Bref.
sur X360 et PS3 (PPU et SPU), les vecteurs SIMD contiennent 4 elements.
d'habitude, sur un CPU classique, il n'y a que quelques registres SIMD (qui contiennent les vecteurs en question), et plein d'autres registres simples qui contiennent qu'une seule valeur, utilises pour tous les calculs classiques. par exemple, sur PC x86-32 bits, il y a 8 registres SSE, et une 10aine de registres entiers classiques utilisables pour tout et n'importe quoi. pour ceux ici qui connaissent pas trop, c'est pas beaucoup. quand on a besoin de valeurs temporaires pour les calculs, et qu'on a plus assez de registres, il faut stocker temporairement ca en memoire, et ca fait perdre du temps, donc plus on a de registres, mieux c'est.
les SPU n'ont QUE des registres SIMD. et ils en ont 128.
et TOUTES les instructions des SPU sont des instructions SIMD. meme pour charger une valeur en memoire, l'instruction attend l'addresse dans un registre SIMD.
aussi, si vous savez ce que c'est qu'un cache: les SPU n'ont pas de cache. la seule memoire qui leur est accessible (code+data), est leur "local storage" on-chip, de 256K, qui a en gros les perfs d'un cache L1 classique. ils n'ont pas acces a la main-memory, et pour recuperer les donnees a traiter, il faut faire des DMA.
tout ca a pour effet:
- pour du code pas pense pour les SPU, ca va etre horrible, et le gain de performance va etre minime, et ca risque meme d'etre plus lent que sur le PPU.
- pour du code concu et optimise pour, ca blaste sa mere...
apres, evidemment, au debut la PS3 a eu une mauvaise reputation aupres des devs, parceque c'etait super chiant de porter sur PS3 un jeu code sur PC initialement, du a ces grosses differences d'architecture, qui demandent une conception differente du programme pour avoir de bonnes perfs.
mais maintenant c'est plus tellement le cas, les devs s'y sont habitue, et le cell est vraiment une architecture ultra-puissante, pour peu qu'on arrive a voir comment re-organiser un algo pour le rendre SPU-friendly.