On se retrouve aujourd'hui avec des processeurs de super calculateurs, surpuissant et doté de bientôt 200 millions de transistors...
Le problème, c'est qu'une unité d'exécution RISC, disons - pour couper la poire en deux, à jeu d'instruction de taille flottante (oui je sais, c'est plus vraiment du RISC), ça ne prend pas 200 millions de transistors.
Au lieu de ça, on implémente des nouvelles instructions (bonne idée), et on tente des incantations vaudoo sur le code (genre exécution dans le désordres et autres bidouilles) comme si le compilateur n'était pas foutu de le faire lui même (du moment qu'on y travail).
Quand on a 200 millions de transistors, on à quoi comme solution, quand on en a déjà trop pour aligner de plus en plus de pipelines ?
- On fait du multi-coeur (Cell)
- On rajoute des instructions spécifiques et complexes (Intel/AMD).
Le problème des multi coeurs est que ça implique un gros goulot d'étranglement au niveau mémoire (ben oui puisque vous avez un débit mémoire qui ne double pas quand le nombre de coeur double, quadruple)
et des problèmes de parraléllisme http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
Faudra repenser le développement et tout développer en multi-threading. Je souhaite longue vie aux langages intrinsèquement parallèles.
Ou alors, on se retrouvera avec des bloat CPU.
Je ne partage pas la peur de patrick quand aux conséquences pour le libre, car je vois mal d'une part intel/amd ne pas documenter ses instructions, et d'autre part, leur granulité sera trop fine pour qu'elles soient réservables à .net ou java. Je veux dire par là qu'un compilo bien foutu saura les utiliser à bon escient.
M'enfin quand on voit que gcc est pas foutu d'utiliser mmx, sse, etc... On peut avoir peur.
Après mes propos ne sont que d'humbles intuitions...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Ça devait arriver...
Posté par Ontologia (site web personnel) . En réponse au journal Les bloat-CPU. Évalué à 6.
Le problème, c'est qu'une unité d'exécution RISC, disons - pour couper la poire en deux, à jeu d'instruction de taille flottante (oui je sais, c'est plus vraiment du RISC), ça ne prend pas 200 millions de transistors.
Au lieu de ça, on implémente des nouvelles instructions (bonne idée), et on tente des incantations vaudoo sur le code (genre exécution dans le désordres et autres bidouilles) comme si le compilateur n'était pas foutu de le faire lui même (du moment qu'on y travail).
Quand on a 200 millions de transistors, on à quoi comme solution, quand on en a déjà trop pour aligner de plus en plus de pipelines ?
- On fait du multi-coeur (Cell)
- On rajoute des instructions spécifiques et complexes (Intel/AMD).
Le problème des multi coeurs est que ça implique un gros goulot d'étranglement au niveau mémoire (ben oui puisque vous avez un débit mémoire qui ne double pas quand le nombre de coeur double, quadruple)
et des problèmes de parraléllisme
http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=bgteob&a(...)
Faudra repenser le développement et tout développer en multi-threading. Je souhaite longue vie aux langages intrinsèquement parallèles.
Ou alors, on se retrouvera avec des bloat CPU.
Je ne partage pas la peur de patrick quand aux conséquences pour le libre, car je vois mal d'une part intel/amd ne pas documenter ses instructions, et d'autre part, leur granulité sera trop fine pour qu'elles soient réservables à .net ou java. Je veux dire par là qu'un compilo bien foutu saura les utiliser à bon escient.
M'enfin quand on voit que gcc est pas foutu d'utiliser mmx, sse, etc... On peut avoir peur.
Après mes propos ne sont que d'humbles intuitions...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker