Plus une éolienne est grande, moins elle est près du sol. Le vent est meilleur en hauteur… La dynamo est aussi un élément important. Les aimants coûtent cher (terre rare). L'effet d'échelle a tendance à faire de plus en plus grand. Aujourd'hui, on est limité par la réglementation et non par la technique.
Je mettais amusé à virtualiser un noeud de calcul sous Xen il y a quelques années… En terme de perf, c'est mauvais !
Chez nous, on a un cluster de calcul sous Debian piloté par un gestionnaire de batch. Il est super facile de soumettre un job interactif et la config des noeuds est quasiment la même que celles des PC de bureau (sous GNU/Linux). Pour moi, la virtualisation du calcul, c'est tout bêtement un cluster de calcul ;-)
Après, je ne fais pas de support calcul pour les autres OS ! De toute manière, les autres OS ne passe pas l'échelle, tous les centres régionaux et nationaux sont sous GNU/Linux.
Ceci dis, je virtualise plein de truc sous Xen mais pas le calcul.
On évoque des éoliennes ayant 175m de haut avec des pales de 150… La machine peut être plus haute que celles d'aujourd'hui. Il suffit 'juste' qu'elle tourne moins vite. En effet, on est limité par la vitesse en bout de pale. Il y a aussi une limitation en puissance à terre mais c'est une règle qui à mon avis n'est pas écrite dans le marbre.
A noter qu'il y a plein de progrès à faire sur le sujet. Par exemple, les éoliennes laissent passer tout les pics de vents. Bref, pour ceux qui ont des idées, il y a matière à mouler ;-)
Contrairement à une idée reçu, l'argent ne se stocke pas ! C'est une des raisons de l'arnaque des retraites par capitalisation ! Ce sont toujours les travailleurs à l'instant t qui payent les retraites du jour. La seule chose qu'apporte la capitalisation par rapport à la répartition, c'est que cela joue en bourse, donc plus de risque donc patrons des sociétés très très bien payés… De plus, on ne joue pas au niveau d'un pays mais au niveau mondial. On ponctionne donc les pays voisins, en gros, les africains et les asiatiques payent nos retraites. Dégueulasse !
Comment voulez-vous stocker de l'argent sur 50 à 70 ans au niveau des centrales nucléaires ? Au niveau national, on est loin d'une somme négligeable. Avec 50 centrales, on fabrique quasiment toute l'électricité française. On voit bien que ce n'est pas un système à mettre en bourse mais bien à laisser à la répartition -> nationalisation…
Attention, le génie civil coûte une fortune ! Tranchée pour les câbles, foreuse, étude du sous sol. Je n'ai pas les tarifs mais je ne serais pas étonné que 50% du prix soit invisible ;-)
Les éoliennes sont de plus en plus puissantes et hautes -> fondations plus importantes.
Avec le temps, les fondations peuvent s'être fissurée, avoir vieillis… Pas facile de savoir si l'acier est toujours bon dedans. C'est ainsi qu'il est très rare dans les remontées mécanique de ré-utiliser les anciens socles d'il y a 30 ans. Cependant, je pense que les blocs de béton actuels sont bien plus robuste et conçus pour une durée de vie bien plus longue.
L'éolien en mer a un rendement quasi double, il est évident qu'il faille mettre les hélices au large dès que cela est possible techniquement. En plus, avec des éoliennes flottantes, il n'y a au fond que les câbles d'ancrage et un gros bloc de béton. Facile à déplacer si jamais il le faut ! Quand aux éoliennes sur les crêtes, ce sont rarement des terres cultivables…
Au sujet des fondations, je n'ai pas de chiffre sous la main mais cela me semble négligeable pas rapport aux barrages, voire à toutes les routes que l'on construit (et les ponts) !
Les surgénérateurs comme superphénix sont basés sur une mauvaise idée : le refroidissement au sodium liquide. Le CEA essaye de nous faire croire que la technologie est maîtrisé. C'est une folie de faire un circuit de transfert de chaleur avec du sodium, beaucoup trop dangereux. On a l'impression que le CEA n'a rien retenu des accidents graves…
Il y a une technologie très prometteuse qui résoudrait notre problème électrique pour au moins un millénaire, le temps de mettre au point la fusion, c'est le réacteur au sel fondus. C'est pas un gouffre financier hypothétique comme ITER ou SuperPhénix, les risques sont /a priori/ bien plus limités et les problèmes techniques qui restent à résoudre (passage à un vrai réacteur fonctionnel) bien plus à notre portée qu'ITER par exemple (dont on ne sais toujours pas comment on va récupérer les calories !). Mais le projet est porté par des chercheur du CNRS et ce n'est pas du tout un projet assumée par les pontes du CEA qui ont tous été formé à l'école Phénix ! A noter que le sel fondus n'a pas /a priori/ d'intérêt militaire…
On voit que le béton se dégrade au final assez rapidement sans rien faire ;-) C'est un peu la différence avec le nucléaire, les durée et la dangerosité n'est pas du tout la même. Un bloc de béton sous terre est il réellement dangereux ?
Dans le même ordre d'idée, sur un fichier HDF5 (ou NetCDF4), est-il capable de lire un morceau d'un tableau sans tout charger en mêmoire ? C'est un peu le défaut des modules classique qui ne fonctionne pas avec de gros volumes de données.
F90 rajoute les modules donc c'est à partir de là que tu as du mangling. Si tu ne fais pas de module, tu fait du F77 caché dans l'appellation F90 mais c'est pas du Fortran moderne… C'est avec cette notion de Module que sont généré automatiquement les .mod, équivalents des .h du C qui permettent une vérification forte du typage dès la compilation.
Avec F2003, il y a l'héritage simple mais on sais tous que c'est facile a émuler puisque qu'en gros, un cast suffit (c'est ce que fait GTK). C'est pour cela que je considère (come d'autre) que la bascule importante a eu lieu avec F90.
En calcul numérique, cela peut être bien plus simple de faire du Fortran. En C, tu te fais chier avec les valeurs, les pointeurs et les références… En Fortran, tout passe par adresse. Il y a tout plein de code matlab que tu fais facilement en Fortran par exemple. De très nombreux thésards n'ont aucun notion de programmation en démarrant…
Évidement, il n'y a aucun intérêt à faire du Fortran pour un clickodrome ou un serveur web. A chacun son domaine. Moi j'aime bien aussi la philosophie Erlang ou tout est immutable et passe par copie ;-)
Le support du Fortran par GCC est très loin d'être nul, c'est pas parce que c'est pas dans LVVM que GCC ne fait rien ! Le support des Co-Array est en cours (Fortran 2008 de tête), les Co-Array sont des tableaux qui fonctionne de manière transparent sur un cluster. C'est faisable avec MPI et/ou OpenMP (sur un noeud) mais ici, l'API est simplifié. La bascule vers des codes parallèle est importante et ne doit pas être que l'affaire des spécialiste. Fortran cherche sa voie très calcul numérique. A chacun ses choix.
C et Fortran ont une ABI compatible (il suffit de mettre les underscores au bon moment, au bon endroit
C'est complètement faux !
Tu parles du Fortran 77, une très ancienne version qui a plus de 35 ans… Depuis le Fortran 90, le Fortran moderne, il y a la notion de Module donc d'espace de nom et chaque compilateur gère le mangling comme il veut. Cela va même plus loin car l'ordre des champs dans un type est laissé au choix du compilateur par défaut (ce qui n'est pas le cas en C) pour des questions de performances et d'alignement…
Fortran est aujourd'hui un langage objet (héritage simple). C'est un langage qui a énormément évoluer (c'est pour cela qu'il n'est pas encore mort), bien plus que le C.
En C++, le "name mangling" n'est pas standardisé. Ils donnent des bonnes raisons même si en pratique, c'est très chiant. Dès qu'on a deux compilateurs, il faut tout se retaper, toutes les lib !
C'est un truc qu'on est régulièrement confronté en Fortran avec gfortran et ifort. Il faut tout se taper en double (et on recommence tout à chaque fois que gfortran change son format, c'est à dire trop souvent). Je pense que c'est moins le cas entre g++ et icc (de mon coté, on n'utilise quasiment jamais icc). Mais cela risque de le devenir si LLVM se généralise de plus en plus et que le C++ de celui-ci soit incompatible avec celui de g++.
Bref, c'est vrai qu'avec le C, une bibliothèque est une bibliothèque qui marche pour tout (même si elle n'est pas forcément optimum).
Peut être une partie du problème viens que GNOME cherche à suivre MacOSX ou Android. Or ces OS ne suivent pas la tradition UNIX (X-Window) du copier coller par bouton du milieu, follow mouse, menu local…
Apple se fout de la compatibilité ascendante et coupe régulièrement les vieux trucs. Ce ne doit pas être évident de faire (en C) un toolkit généraliste qui fonctionne bien dans tous les paradigmes de UI ?
Ensuite, GTK viens de Gimp et non de GNOME… Ensuite, au dela du problème de licence de Qt, il y avait aussi le problème du langage. Qt utilise une surcouche de C++ et il n'était pas envisageable de tout basé sur ce C++. Il faut voir que le binding de bibliothèque C++ depuis d'autre langage n'est pas aussi évident que de partir du C.
Ceci dis, Fortran évite au maximum les pointeurs et a ajouté pas mal de possibilités via les ALLOCATABLE. Dans de très nombreux cas, cela suffit et pour la performance, c'est 100 fois mieux car les pointeurs sont en général une horreur lorsqu'on veut optimiser un code.
Les pointers du Fortran ne sont pas des pointers au sens du C. Tu n'as jamais accès à l'adresse mémoire. On ne les déférence jamais. Ca évite pas mal de chose… mais du coup, pour changer la réfèrence vers laquelle il pointe, on n'utilise pas l'affection = mais l'opération =>
Sur les Xeon haut de gamme par exemple, il y a plus de bus d'accès à la mémoire. C'est ce qui permet à SGI par exemple de faire des machines avec 4096 coeurs qui restent performant.
Si on veut concurrencer le x86_64 sur les calculateurs, il faut avoir une bonne unité de calcul flottant en double précision ainsi qu'une interconnexion efficace (par infiniBand ou équivalent). J'ai rien lu concernant la double précision dans la dépêche or c'est souvent le composant qui coûte cher et qui fait une partie de la différence entre les CPU intel haut et bas de gamme (en plus de capacité IO plus importante aussi).
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 3.
Plus une éolienne est grande, moins elle est près du sol. Le vent est meilleur en hauteur… La dynamo est aussi un élément important. Les aimants coûtent cher (terre rare). L'effet d'échelle a tendance à faire de plus en plus grand. Aujourd'hui, on est limité par la réglementation et non par la technique.
[^] # Re: Plus d'infos
Posté par Sytoka Modon (site web personnel) . En réponse au message Virtualisation sur un parc de serveurs de calcul. Évalué à 4.
Je mettais amusé à virtualiser un noeud de calcul sous Xen il y a quelques années… En terme de perf, c'est mauvais !
Chez nous, on a un cluster de calcul sous Debian piloté par un gestionnaire de batch. Il est super facile de soumettre un job interactif et la config des noeuds est quasiment la même que celles des PC de bureau (sous GNU/Linux). Pour moi, la virtualisation du calcul, c'est tout bêtement un cluster de calcul ;-)
Après, je ne fais pas de support calcul pour les autres OS ! De toute manière, les autres OS ne passe pas l'échelle, tous les centres régionaux et nationaux sont sous GNU/Linux.
Ceci dis, je virtualise plein de truc sous Xen mais pas le calcul.
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 3.
On évoque des éoliennes ayant 175m de haut avec des pales de 150… La machine peut être plus haute que celles d'aujourd'hui. Il suffit 'juste' qu'elle tourne moins vite. En effet, on est limité par la vitesse en bout de pale. Il y a aussi une limitation en puissance à terre mais c'est une règle qui à mon avis n'est pas écrite dans le marbre.
A noter qu'il y a plein de progrès à faire sur le sujet. Par exemple, les éoliennes laissent passer tout les pics de vents. Bref, pour ceux qui ont des idées, il y a matière à mouler ;-)
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 7.
Contrairement à une idée reçu, l'argent ne se stocke pas ! C'est une des raisons de l'arnaque des retraites par capitalisation ! Ce sont toujours les travailleurs à l'instant t qui payent les retraites du jour. La seule chose qu'apporte la capitalisation par rapport à la répartition, c'est que cela joue en bourse, donc plus de risque donc patrons des sociétés très très bien payés… De plus, on ne joue pas au niveau d'un pays mais au niveau mondial. On ponctionne donc les pays voisins, en gros, les africains et les asiatiques payent nos retraites. Dégueulasse !
Comment voulez-vous stocker de l'argent sur 50 à 70 ans au niveau des centrales nucléaires ? Au niveau national, on est loin d'une somme négligeable. Avec 50 centrales, on fabrique quasiment toute l'électricité française. On voit bien que ce n'est pas un système à mettre en bourse mais bien à laisser à la répartition -> nationalisation…
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 3.
Attention, le génie civil coûte une fortune ! Tranchée pour les câbles, foreuse, étude du sous sol. Je n'ai pas les tarifs mais je ne serais pas étonné que 50% du prix soit invisible ;-)
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 7.
Les éoliennes sont de plus en plus puissantes et hautes -> fondations plus importantes.
Avec le temps, les fondations peuvent s'être fissurée, avoir vieillis… Pas facile de savoir si l'acier est toujours bon dedans. C'est ainsi qu'il est très rare dans les remontées mécanique de ré-utiliser les anciens socles d'il y a 30 ans. Cependant, je pense que les blocs de béton actuels sont bien plus robuste et conçus pour une durée de vie bien plus longue.
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 4.
L'éolien en mer a un rendement quasi double, il est évident qu'il faille mettre les hélices au large dès que cela est possible techniquement. En plus, avec des éoliennes flottantes, il n'y a au fond que les câbles d'ancrage et un gros bloc de béton. Facile à déplacer si jamais il le faut ! Quand aux éoliennes sur les crêtes, ce sont rarement des terres cultivables…
Au sujet des fondations, je n'ai pas de chiffre sous la main mais cela me semble négligeable pas rapport aux barrages, voire à toutes les routes que l'on construit (et les ponts) !
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 8.
Les surgénérateurs comme superphénix sont basés sur une mauvaise idée : le refroidissement au sodium liquide. Le CEA essaye de nous faire croire que la technologie est maîtrisé. C'est une folie de faire un circuit de transfert de chaleur avec du sodium, beaucoup trop dangereux. On a l'impression que le CEA n'a rien retenu des accidents graves…
Il y a une technologie très prometteuse qui résoudrait notre problème électrique pour au moins un millénaire, le temps de mettre au point la fusion, c'est le réacteur au sel fondus. C'est pas un gouffre financier hypothétique comme ITER ou SuperPhénix, les risques sont /a priori/ bien plus limités et les problèmes techniques qui restent à résoudre (passage à un vrai réacteur fonctionnel) bien plus à notre portée qu'ITER par exemple (dont on ne sais toujours pas comment on va récupérer les calories !). Mais le projet est porté par des chercheur du CNRS et ce n'est pas du tout un projet assumée par les pontes du CEA qui ont tous été formé à l'école Phénix ! A noter que le sel fondus n'a pas /a priori/ d'intérêt militaire…
http://fr.wikipedia.org/wiki/R%C3%A9acteur_nucl%C3%A9aire_%C3%A0_sels_fondus
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 3.
On voit que le béton se dégrade au final assez rapidement sans rien faire ;-) C'est un peu la différence avec le nucléaire, les durée et la dangerosité n'est pas du tout la même. Un bloc de béton sous terre est il réellement dangereux ?
[^] # Re: bof ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Sortie de Linux 3.13. Évalué à 2.
Et il faut voir la quantité de bentonite injecté dans les montagnes pour chaque barrage…
[^] # Re: bazar/cathedral ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Projets Open Source, des vaches à lait ?. Évalué à 2.
Il me semble que le build de Debian tourne déjà (en partie) sur un cluster Amazon…
[^] # Re: Gros volumes de données ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Pandas, une bibliothèque pour manipuler facilement des données. Évalué à 2.
Dans le même ordre d'idée, sur un fichier HDF5 (ou NetCDF4), est-il capable de lire un morceau d'un tableau sans tout charger en mêmoire ? C'est un peu le défaut des modules classique qui ne fonctionne pas avec de gros volumes de données.
Autre question, Pandas gère t'il le format VTK ?
[^] # Re: Rebuild Debian
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 2.
s/c'est les gros packages/ce sont les gros paquets/
[^] # Re: mélange de langage ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 4.
F90 rajoute les modules donc c'est à partir de là que tu as du mangling. Si tu ne fais pas de module, tu fait du F77 caché dans l'appellation F90 mais c'est pas du Fortran moderne… C'est avec cette notion de Module que sont généré automatiquement les .mod, équivalents des .h du C qui permettent une vérification forte du typage dès la compilation.
Avec F2003, il y a l'héritage simple mais on sais tous que c'est facile a émuler puisque qu'en gros, un cast suffit (c'est ce que fait GTK). C'est pour cela que je considère (come d'autre) que la bascule importante a eu lieu avec F90.
[^] # Re: mélange de langage ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 9.
En calcul numérique, cela peut être bien plus simple de faire du Fortran. En C, tu te fais chier avec les valeurs, les pointeurs et les références… En Fortran, tout passe par adresse. Il y a tout plein de code matlab que tu fais facilement en Fortran par exemple. De très nombreux thésards n'ont aucun notion de programmation en démarrant…
Évidement, il n'y a aucun intérêt à faire du Fortran pour un clickodrome ou un serveur web. A chacun son domaine. Moi j'aime bien aussi la philosophie Erlang ou tout est immutable et passe par copie ;-)
Le support du Fortran par GCC est très loin d'être nul, c'est pas parce que c'est pas dans LVVM que GCC ne fait rien ! Le support des Co-Array est en cours (Fortran 2008 de tête), les Co-Array sont des tableaux qui fonctionne de manière transparent sur un cluster. C'est faisable avec MPI et/ou OpenMP (sur un noeud) mais ici, l'API est simplifié. La bascule vers des codes parallèle est importante et ne doit pas être que l'affaire des spécialiste. Fortran cherche sa voie très calcul numérique. A chacun ses choix.
[^] # Re: mélange de langage ?
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche LLVM 3.4 et Clang 3.4. Évalué à 10.
C'est complètement faux !
Tu parles du Fortran 77, une très ancienne version qui a plus de 35 ans… Depuis le Fortran 90, le Fortran moderne, il y a la notion de Module donc d'espace de nom et chaque compilateur gère le mangling comme il veut. Cela va même plus loin car l'ordre des champs dans un type est laissé au choix du compilateur par défaut (ce qui n'est pas le cas en C) pour des questions de performances et d'alignement…
Fortran est aujourd'hui un langage objet (héritage simple). C'est un langage qui a énormément évoluer (c'est pour cela qu'il n'est pas encore mort), bien plus que le C.
[^] # Re: Local knowledge
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 0.
Merci de ne pas reprendre bêtement la phrasologie "nazis de l'interface". Le nazisme, c'est cela :
http://fr.wikipedia.org/wiki/Nazisme
[^] # Re: Local knowledge
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 2.
On dis souvent les plus grosses vacheries à ses collègues de bureau mais bon, c'est souvent du second degré ;-)
[^] # Re: Uchronie
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
D'après Wikipédia http://en.wikipedia.org/wiki/Name_mangling
En C++, le "name mangling" n'est pas standardisé. Ils donnent des bonnes raisons même si en pratique, c'est très chiant. Dès qu'on a deux compilateurs, il faut tout se retaper, toutes les lib !
C'est un truc qu'on est régulièrement confronté en Fortran avec gfortran et ifort. Il faut tout se taper en double (et on recommence tout à chaque fois que gfortran change son format, c'est à dire trop souvent). Je pense que c'est moins le cas entre g++ et icc (de mon coté, on n'utilise quasiment jamais icc). Mais cela risque de le devenir si LLVM se généralise de plus en plus et que le C++ de celui-ci soit incompatible avec celui de g++.
Bref, c'est vrai qu'avec le C, une bibliothèque est une bibliothèque qui marche pour tout (même si elle n'est pas forcément optimum).
[^] # Re: Local knowledge
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 1.
Peut être une partie du problème viens que GNOME cherche à suivre MacOSX ou Android. Or ces OS ne suivent pas la tradition UNIX (X-Window) du copier coller par bouton du milieu, follow mouse, menu local…
Apple se fout de la compatibilité ascendante et coupe régulièrement les vieux trucs. Ce ne doit pas être évident de faire (en C) un toolkit généraliste qui fonctionne bien dans tous les paradigmes de UI ?
[^] # Re: Uchronie
Posté par Sytoka Modon (site web personnel) . En réponse au journal Gtk to Qt - A strange journey. Évalué à 10.
Ensuite, GTK viens de Gimp et non de GNOME… Ensuite, au dela du problème de licence de Qt, il y avait aussi le problème du langage. Qt utilise une surcouche de C++ et il n'était pas envisageable de tout basé sur ce C++. Il faut voir que le binding de bibliothèque C++ depuis d'autre langage n'est pas aussi évident que de partir du C.
[^] # Re: Résolu
Posté par Sytoka Modon (site web personnel) . En réponse au message Permutation "sure" de pointeurs en Fortran. Évalué à 2.
Ceci dis, Fortran évite au maximum les pointeurs et a ajouté pas mal de possibilités via les ALLOCATABLE. Dans de très nombreux cas, cela suffit et pour la performance, c'est 100 fois mieux car les pointeurs sont en général une horreur lorsqu'on veut optimiser un code.
[^] # Re: Permutation sans variable intermédiaire
Posté par Sytoka Modon (site web personnel) . En réponse au message Permutation "sure" de pointeurs en Fortran. Évalué à 2.
Les pointers du Fortran ne sont pas des pointers au sens du C. Tu n'as jamais accès à l'adresse mémoire. On ne les déférence jamais. Ca évite pas mal de chose… mais du coup, pour changer la réfèrence vers laquelle il pointe, on n'utilise pas l'affection = mais l'opération =>
Bref, ce sont plutôt des alias que des pointers…
[^] # Re: Double précision
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 1.
Sur les Xeon haut de gamme par exemple, il y a plus de bus d'accès à la mémoire. C'est ce qui permet à SGI par exemple de faire des machines avec 4096 coeurs qui restent performant.
# Double précision
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 2.
Si on veut concurrencer le x86_64 sur les calculateurs, il faut avoir une bonne unité de calcul flottant en double précision ainsi qu'une interconnexion efficace (par infiniBand ou équivalent). J'ai rien lu concernant la double précision dans la dépêche or c'est souvent le composant qui coûte cher et qui fait une partie de la différence entre les CPU intel haut et bas de gamme (en plus de capacité IO plus importante aussi).