Nicolas Boulay a écrit 16043 commentaires

Une liseuse, cela peut être un ARM9 à 200Mhz. Il n'y a pas de fpu, mais c'est toujours plus rapide que les cpu dédiés à 20Mhz.

"La première sécurité est la liberté"

Ou alors tu le code toi-même : un vector pour le stockage et un hashmap pour l'association composant <-> entity.

"La première sécurité est la liberté"

Pour chaque entité tu alloues tous les composants ? Pourquoi pas seulement, les composants utiles ?

"La première sécurité est la liberté"

Les indirections sont bien plus local que dans un système classique.

"La première sécurité est la liberté"

Une personne en 4/5ième (80%), à 5 semaines de congé de 4 jours.

"La première sécurité est la liberté"

Pour moi, le layout mémoire idéal d'un système à entité consiste à regrouper par composant.

L'entité est simplement un nombre, nombre qui sert de clef dans un conteneur à composants, pour retrouver les composants.

L'idée est que chaque système manipule un nombre réduit de composants sur un grand nombre d'entités, ainsi on bénéficie d'une meilleure localité d'accès pour les caches.

Le conteneur peut être une hashmap ou un arbre.

"La première sécurité est la liberté"

Dans ce cas, il pourrait trouver une tablette chinoise, sans wifi ni bluethout de 5 à 7", cela fera bien mieux l'affaire.

"La première sécurité est la liberté"

J'aurais fais les mêmes choix de soft, mais pourquoi ne pas en faire une application libre pour smartphone ?

J'imagine que le hard est fun à faire, mais cela limite pas mal la diffusion du projet.

"La première sécurité est la liberté"

C'est pas Obiwan Kenobi, le dernier espoir ?

"La première sécurité est la liberté"

Après ma position ce n'est pas que les GPU sont inutiles, loin de là. C'est juste que parler d'un rapport 100, c'est n'importe quoi. Ni en théorie, ni en pratique, on atteint le rapport 100. Même en comparant un CPU d'il y a trois ans à GPU de cette année.

Ok. J'étais rester sur des GPU avec >1 TFlops de puissance, et des cpu qui tournait à 60 Gflops. (2 instructions fpu/cycles/cpu).

"La première sécurité est la liberté"

Excuse-moi pour l'agressivité, mais purée t'as pas peur de la contradiction !

Non, c'était mes souvenirs. Le MULSP c'est du simple précision, et c'est 4 multiplications seulement, qui prennent 2 cycles, et non un seul.
Actuellement, tu prends 16 ops en un seul cycle. L'avx date de quand ? 2 ans max.

Je me repète mais à un instant donné, on a des groupes de 32 cœurs qui exécutent la même intruction sur un GPU.

La grosse différence, c'est que tu n'es pas obligé d'avoir les adresses mémoires contigües contrairement au SIMD. Un vecteur load/store pourrait exister, mais ce n'est pas encore fait, sauf erreur. La différence est que cela revient à pouvoir exécuter la même fonction sur 32 éléments totalement différent, contrairement au SIMD classique.

"La première sécurité est la liberté"

un ordre total sans le surcoût d'un protocole de cohérence.

Quel est l'intérêt de ça, si tu fonctionnes avec des threads pas franchement synchronisé ? Je comprends l’intérêt de l'ordre pour un cpu localement, mais pas pour l'ensemble des cpus. Un retard d'écriture venant d'un write buffer ou d'un retard de thread, quelle différence ?

un protocole de constance mémoire beaucoup plus faible que la cohérence de cache classique.

Lequel ?

"La première sécurité est la liberté"

cette dernière ne peut être utilisée que si l'intégralité de la ligne a été transférée. Une ligne de cache sur x86 fait 64 bytes.

Cela m'étonnerait beaucoup. Même dans la DDR, il y a un mode de transfert qui demande la data qui intéresse en premier.

"La première sécurité est la liberté"

J'imagine que depuis que Intel fait de l'AVX en 64 bits, cela n'a plus trop d'intérêt.

"La première sécurité est la liberté"

Regarder le monothread pour du HPC, c'est pas sérieux.

"La première sécurité est la liberté"

Y'a ARM aussi.

"La première sécurité est la liberté"

Il y a tout de même plus de contraintes d'utiliser du SIMD large par rapport à des GPU (un comble). Mais bon le SIMD 512 bits, efficace c'est récent, avant tu avais une seul multiplication même en SSE.

"La première sécurité est la liberté"

Plutôt que d'avoir une FPU de plus, what about une FPU qui sait faire 8 opérations en même temps ? ;)

Parce que personne ne code naturellement avec des gros tableau alignés pour faire une addition.( En plus ce genre de code se fait étrangler par la mémoire.)

Prends une simple image 2D, avec la gestion des canaux de couleur, il y a peu de cas qui peut se faire accélérer sans changer le code (surtout avec la gestion des bords).

"La première sécurité est la liberté"

Je parlais de puissance disponible (max) pas de performance réelle.

"La première sécurité est la liberté"

Sur un serveur, la charge de travail se distribue quand même assez naturellement sur un certains nombre de cœurs,

Oui, mais c'est spécifique. En plus, J'imagine que l'augmentation de la vitesse décroit avec le nombre de cœur. Est-ce que 8 cœurs est vraiment 2x plus rapide que 4 ? La bande passante mémoire n'augmente pas aussi vite, idem pour les IO.

l'auto-vectorisation dans les compilateurs (gcc, icc) commence à très bien marcher, donc une recompilation permet déjà d'obtenir un gain en performance.

Vu que le code C impose le layout mémoire, sans le changer, j'ai de gros doute sur les accélérations possibles.

monter en fréquence c'est devenu physiquement impossible (la puissance dissipée augmente de manières quadratique par rapport à la fréquence) et c'est sur que ça devient plus difficile de gagner en performance.

L'équation complète inclus la capacité parasite et la tension, qui peuvent toutes les 2 baisser. De plus, il pourrait rajouter des unités de calcul, j'imagine qu'une application bien écrit devrait tirer facilement des performances d'une unité de FPU de plus.

"La première sécurité est la liberté"

Les GPU sont complexes à programmer, mais la puissance de calcul disponible est 100x supérieur. Heureusement, cela devient de plus en plus facile à utiliser.

"La première sécurité est la liberté"

Les machines pro "lag" un peu avec les gammes grand publique.

"La première sécurité est la liberté"

On est déjà à +40% entre 2010 et aujourd'hui en x86. Alors que Intel a mis le frein sur l'augmentation des performances.

"La première sécurité est la liberté"

'est effectivement devenu difficile de monter en fréquence, par contre le nombre de cœurs par chip augmente à chaque génération (18 cœurs/36 threads par chip sur les Haswell-EP). La taille gérée par les intructions vectorielles augmente et de plus en plus d'opérations sont réalisables en vectoriel (SSE 128 bits -> AVX 256 bits, apparition du Fused-Multiply-Add avec AVX2 etc.).

C'est justement le problème. Aucune application devient magiquement plus rapide avec du nouveau SIMD et de tout nouveau coeur, sans tout réécrire ou presque.

Les améliorations des micro-architectures apportent des gains assez faibles mais qui accumulés deviennent non-négligeables.

C'est le "assez" faible qui est gênant. A une époque, on avait le Pentuim 300Mhz qui est sorti après le 200Mhz (+50% de perf). Le nombre de cœur au delà de 4 devient presque inutile (sauf cas particulier), tant qu'il n'existera pas de langage qui distribue le boulot naturellement.

Finalement le gain de performance par rapport à un Nehalem de 2009 atteint 60%. C'est pas énorme, mais pas négligeable non plus.

Sur du monothread entre un core 2 (2008/2010), et un core i7 il y a en moyenne 10 à 50% de performance en plus.

"La première sécurité est la liberté"

Les processeurs x86 sont loin d'égaler ces bêtes de courses.

Loin? 40% de moins, c'est pas loin, c'est juste derrière.

Ensuite, il faut voir le domaine : FPU, CPU ou IO. Et clairement le PC sacrifiait les IO par rapport au CPU.

Le bench plus haut mesurait des machines 8 sockets. Je serais curieux de voir les performances du même genre d'applications sur 8 machines mono-socket.

Et puis depuis que AMD ne fait plus grand chose, intel se concentre sur le low power et semble avoir abandonné la course à la puissance brute (les core iX offrent peu d'augmentation de performances brutes à chaque génération). C'est dommage. Il est logique donc d'avoir des puces qui sortent avec cet objectif unique en tête.

Si Intel sort une puce avec des instructions d’accélération de compression (pour le mod gzip d'http) et des instructions pour les hash les plus utilisé, en plus des instructions AES, si il augmente drastiquement la bande passante avec la RAM (x2 ?). Il peuvent retrouver une bonne place dans les benchmarks "base de donné".

"La première sécurité est la liberté"