"Ou comme un contrôleur mémoire supplémentaire par le CPU, pour obtenir une machine NUMA (un peu comme les chip de SGI dans ses grosses machines). Bon après il vaut toujours mieux avoir le réseau haut débit qui va avec derrière."
Non, non et non. Surtout pas !
C'est un enfer à faire correctement ces machines là. La gestion de cohérence de cache et la localité de l'accès mémoire devienne primordial, ce qui demanderait un énorme boulot sur le noyau de Linux lui-même, avec aucune garanti de résultat.
Aujourd'hui, on ne fait plus de mémoire partagé, au contraire, on fait du "share nothing" avec des communications explicites, il faut donc des liens explicites de communication à latence ultra-faible, qui peuvent très bien reposer sur du TCP/IP pour la facilité.
"Ou je me trompe ?"
Oui tu te trompes, il n'est jamais question de faire le boulot en entier par une seul instruction, mais simplement de faire une partie de l’algorithme qui est lent.
"On peut monter le volume jusqu'à 70-80 dB sans grosses distorsions. Après, je pense que c'est le hifiberry qui ne suit plus."
C'est surtout tes haut parleurs qui ne suivent plus. Si les HIFIBerry sont basé sur du Tamp, Ils sont très très bon jusqu'à la moitié de leur puissance, ensuite cela se dégrade mais cela reste bon. Il faut aussi que l'alimentation suivent sans broncher.
Un haut parleur de base, c'est 200€, difficile de parler de hifi à moins chère. Avec 10W, difficile d'avoir autre chose que des bibliothèques, mais rien n’empêche d'avoir un caisson de basse en plus. Il faut donc trouver des HP avec un "bon rendement", en gros cela veut dire qu'ils utilisent moins de courant pour la même tension, et donc nécessite moins de puissance. Le 8 ohms que l'on voit partout n'est qu'une moyenne. J'ai des HP ou cela tombe à 2 ohm en basse fréquence (donc pour le même volume sonore, l'ampli doit fournir 4x plus de courant).
Disons que sans le succès de ses petites machines 32 bits only, il y aurait eu une pression énorme pour tout passer au 64 bits. Là, il avait toujours une excuse pour dire, "on va se couper d'une partie des utilisateurs non négligeable".
Tu n'as rien compris. Si tu es en 32 bits, avec 4 Go de ram, c'est pour les utiliser. Donc ton application va chercher à allouer des gros morceaux de mémoire contiguë en mémoire virtuelle. Or avant de faire son alloc, il y a déjà un paquet de truc présent dans l'espace mémoire virtuelle de l'application (alloc précédente, lib, code), et trouver des "gros morceaux" contiguë est difficile.
Le problème n'est pas la quantité, mais les tailles maximum des morceaux.
J'ai eu le problème avec une jvm embarqué qui alloue un gros morceau aux démarrages.
N’empêches que Intel a grave merdé d'avoir sorti de nouveau processeurs uniquement 32 bits, quand le 64 bits commençait à décoller. Cela a longuement retardé la bascule, et garder en vie windows XP bien trop longtemps.
Je crois que tu as complètement oublier l'intérêt des benchs : savoir ce qui va le plus vite pour l'utilisateur, et pas seulement, pourquoi cela va plus vite.
Cela peut être intéressant de faire des microbenchmark pour mesurer l'effet d'un seul paramètre. Mais l'utilisateur s'en contre-fou : c'est la vitesse de son application qui comptent, dans les versions facilement accessibles. Par exemple, si son application n'utilise pas SSE, alors quelle le pourrait, le gain attendu sera faible. C'était le cas de beaucoup de code au lancement du x64, qui n'avait pas de routines en assembleur.
C'est aujourd'hui, plus le cas. De toute façon, le code x64 est plus rapide en général uniquement grâce au doublement du nombre de registres généraux disponible.
Dans tout votre baratin, vous oubliez un problème très chiant quand vous adressez un problème utilisant toute la RAM et qui s'approche du maximum en 32 bits. C'est la pénurie d'espace d'adressage.
En gros, linux va mapper des lib partagé un peu partout dans l'espace d'adressage virtuel. Ensuite, l'application va vouloir allouer un gros bloc de 2 Go : et bien il ne pourra pas ! Car l'espace virtuelle (virtuelle pas physique) est saturé. Le problème se pose aussi avec les applications 32 bits sous noyau 64 bits. Sous windows, il y a en plus des libs de converssion 32/64 qui fragmentent encore plus. Ce qui veut dire que des applications fonctionnent avec un windows 32 bits, mais plus avec un windows 64. Il y a même un problème temporel car plus le dernier reboot est loin, et plus de library sont chargés.
Le seul et unique cas ou le mot adressé n'est pas un octet, que j'ai vu, sont des anciens DSP de TI qui utilisait des mots de 16 bits à la place. Vu que "sizeof(char) = 1" par définition du langage C, et que un char utilise la plus petite unité de mémoire adressable, tu as des char 16 bits, avec "sizeof(char) = 1". Cela casse tellement de code C, qu'il y avait un mode avec le char en octet !
Si vous cherchez une solution à la "chinoise" avec un gros copro qui sait faire du calcul matriciel, c'est puissant, mais cela nécessite du code réécrit. Et un serveur est loin de faire beaucoup de calcul pure.
En cherchant une autre balance cpu/perf, cela pourrait fonctionner, comme avoir beaucoup de bandes passantes par cpu (remplacer qq Mo de cache par un port DDR 256 bits comme la PS4 au lieu de 128). Et pourquoi pas pouvoir mettre plusieurs ordinateurs sur le même PCB, relié entre eux par un bridge qui pourrait être vu comme une carte réseau par linux. Ce genre de config pourrait être bien quand il y a des dizaines de GO de mémoire (un cache de 16 Mo devenant moins intéressant avec l'augmentation de la taille mémoire).
Je crois aussi beaucoup à des instructions spécifiques pour ce qui prend du temps : compression gzip, crypto, hash,… Je parle bien d'instructions et non de coprocesseurs qui ne sont jamais assez flexible et qui sont "long à lancer" (écriture sur les registres, etc…). Pour supporter ce gens d'instruction, il "suffit" de porter la lib openSSL qui gère la crypto et la libgzip.
Concernant les mémoires rapides spécifiques, les problèmes sont souvent les mêmes : latence identique à la DDR, taille réduite, et prix élevé.
Je confirme que sur les SoC Arm tout est sous forme de core externe, ce qui impose tout un tas de contraintes chiantes :
- L'usage du core n'a aucun intérêt sur les petits paquets en terme de perf (à cause du temps de setup)
- Il n'y a jamais tous les mode (CBC, XTX,…)
- Le support de l'OS est obligatoire
- L'usage par plusieurs applications est compliquée
Bref, la mode des cores à ajouter autour des ARM n'est pas top. Le seul avantage est de pouvoir couper leur alimentation quand on s'en sert pas… (Donc, l'avantage est de ne pas s'en servir…)
"Pour faire simpliste dans le même acabit RISC au niveau CPU pourrait être comparé à KISS au niveau système."
Non, c'est complètement faux. Ce n'était vraiment pour les tout premiers modèles, ou le décodeurs étaient ultra simpliste : bit de contrôle de l'alu ou du controleur mémoire + adresse de registre. Avec les techno superscalaire, c'est devenu beaucoup plus compliqué. Si le décodeurs x86 est toujours aussi complexe, il l'est autant qu'à l'époque des pentiums.
Il faut voir si la comparaison était faite avec "gcc -O2", "gcc -OS" ou "gcc -O3" qui prend forcément plus de place.
Pour le 2), c'est forcément le cas, puisque les registres supplémentaires sont obtenu avec un prefix. Mais d'un autre coté, avoir plus de registres permet souvent de se passer d'accès à la mémoire.
De nos jours ce qui occupe le plus de silicium, c'est tout le système superscalar pour pouvoir lancer en parallèle l’exécution de plusieurs instructions. C'est quadradic avec le nombre d'étage de pipeline, le nombre d'unité de calcul, et la taille de la fenêtre d'instruction utilisée.
"Je ne suis pas tout à fait d'accord: ajouter un décodeur x86 dans le CPU et sous utiliser le CPU car le compilateur ne peut voir qu'un petit nombre de registre, ça a aussi des conséquences au niveau de la consommation."
Ce n'est pas faux, mais beaucoup moins vrai depuis le mode 64 bits qui double les registres. De plus, le système superscalaire offre de fait des centaines de registres invisibles.
"Et pour ce qui est de la densité de code moins importante des RISC, tu retardes"
Je ne retardes pas du tout. Thumb était loin de l'efficacité des x86, très loin même. Il n'offrait même pas toutes les possibilités du jeu 32 bits (ce qui imposait d'utiliser plusieurs instructions 16 bit ou repasser en 32). Thumb2 propose un mode mixte 32/16, j'imagine que tous les nouveau cpu ARM utilise se mode de base. Mais cela reste moins optimal que le code x86, il suffit de comparer la taille des binaires générés.
le fait d'utiliser des instructions complexes consomment toujours plus d'énergie en étant toujours moins optimal.
C'est complètement faux. Les instructions très spécialisé sont bien plus efficace : instruction AES par exemple, ou simplement les instructions SIMD à 4 opérandes…
Est-ce que les compilateurs d'aujourd'hui sont capable de penser en terme énergétique.
Cela ne sert à rien. Un code plus efficace dans le sens classique est aussi un code qui consomme moins.
Le SIMD est une unité de calcul spécialisée au sein du FPU, il est plus typiquement RISC dans sa conception,
Cela ne veut rien dire en terme d'architecture. J'imagine que tu veux dire qu'une unité SIMD classique n'a pas les instructions x87 typique comme sin ou cos, et j'imagine que tu veux dire qu'il y a moins de microcode, mais le microcode est géré avant l'unité de calcul.
"Intel nous "impose" toujours ce vieux CISC alors qu'en interne "tout est RISC""
Je crois revenir 15 ans en arrière. Cette phrase ne veut rien dire. RISC ou cisc qualifie un jeu d'instruction, dire que tout est "RISC derrière" n'a aucun sens.
"du coup ça fait de la perte de puissance à cause de cette conversion permanente,"
Non au contraire, la densité de code est énorme en x86, l'itanium devait avoir des Mega octet de cache pour battre un x86. Et il est mort.
"Mais pourquoi donc on n'a pas de concurrent qui propose une puce compétitive face à un Xeon 10 cœurs par exemple?"
Il te faut qq milliard pour ça. Et il faut avoir le logiciel optimisé qui va avec. Les piles complètes logiciels sous Linux, ne sont pas si vieilles que ça.
depuis qu'il a tué AMD (qui fait que le a figuration depuis des années tellement ses CPU sont décevants de nos jours)…
AMD annonce une nouvelle architecture 30% plus rapide en monocore pour une même fréquence. Faut-il encore qu'il la sorte rapidement.
[^] # Re: Open Hardware
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et si on achetait de l'Open Hardware (v2) ?. Évalué à 3.
Non, non et non. Surtout pas !
C'est un enfer à faire correctement ces machines là. La gestion de cohérence de cache et la localité de l'accès mémoire devienne primordial, ce qui demanderait un énorme boulot sur le noyau de Linux lui-même, avec aucune garanti de résultat.
Aujourd'hui, on ne fait plus de mémoire partagé, au contraire, on fait du "share nothing" avec des communications explicites, il faut donc des liens explicites de communication à latence ultra-faible, qui peuvent très bien reposer sur du TCP/IP pour la facilité.
Oui tu te trompes, il n'est jamais question de faire le boulot en entier par une seul instruction, mais simplement de faire une partie de l’algorithme qui est lent.
"La première sécurité est la liberté"
[^] # Re: HP !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Création d'un multiroom audio à base de raspberry / hifiberry / max2play. Évalué à 3.
D'après ici : http://www.ti.com/lit/ds/symlink/tas5713.pdf la puissance dépend directement de l'alimentation, qui peut monter à 20V.
"La première sécurité est la liberté"
# HP !
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Création d'un multiroom audio à base de raspberry / hifiberry / max2play. Évalué à 4.
C'est surtout tes haut parleurs qui ne suivent plus. Si les HIFIBerry sont basé sur du Tamp, Ils sont très très bon jusqu'à la moitié de leur puissance, ensuite cela se dégrade mais cela reste bon. Il faut aussi que l'alimentation suivent sans broncher.
Un haut parleur de base, c'est 200€, difficile de parler de hifi à moins chère. Avec 10W, difficile d'avoir autre chose que des bibliothèques, mais rien n’empêche d'avoir un caisson de basse en plus. Il faut donc trouver des HP avec un "bon rendement", en gros cela veut dire qu'ils utilisent moins de courant pour la même tension, et donc nécessite moins de puissance. Le 8 ohms que l'on voit partout n'est qu'une moyenne. J'ai des HP ou cela tombe à 2 ohm en basse fréquence (donc pour le même volume sonore, l'ampli doit fournir 4x plus de courant).
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 2.
Disons que sans le succès de ses petites machines 32 bits only, il y aurait eu une pression énorme pour tout passer au 64 bits. Là, il avait toujours une excuse pour dire, "on va se couper d'une partie des utilisateurs non négligeable".
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
Maintenant oui, mais ma proposition était vrai aussi en 2005. Pour un même code C, j'avais en gros +20% de performance.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
Tu n'as rien compris. Si tu es en 32 bits, avec 4 Go de ram, c'est pour les utiliser. Donc ton application va chercher à allouer des gros morceaux de mémoire contiguë en mémoire virtuelle. Or avant de faire son alloc, il y a déjà un paquet de truc présent dans l'espace mémoire virtuelle de l'application (alloc précédente, lib, code), et trouver des "gros morceaux" contiguë est difficile.
Le problème n'est pas la quantité, mais les tailles maximum des morceaux.
J'ai eu le problème avec une jvm embarqué qui alloue un gros morceau aux démarrages.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
N’empêches que Intel a grave merdé d'avoir sorti de nouveau processeurs uniquement 32 bits, quand le 64 bits commençait à décoller. Cela a longuement retardé la bascule, et garder en vie windows XP bien trop longtemps.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 4.
Je crois que tu as complètement oublier l'intérêt des benchs : savoir ce qui va le plus vite pour l'utilisateur, et pas seulement, pourquoi cela va plus vite.
Cela peut être intéressant de faire des microbenchmark pour mesurer l'effet d'un seul paramètre. Mais l'utilisateur s'en contre-fou : c'est la vitesse de son application qui comptent, dans les versions facilement accessibles. Par exemple, si son application n'utilise pas SSE, alors quelle le pourrait, le gain attendu sera faible. C'était le cas de beaucoup de code au lancement du x64, qui n'avait pas de routines en assembleur.
C'est aujourd'hui, plus le cas. De toute façon, le code x64 est plus rapide en général uniquement grâce au doublement du nombre de registres généraux disponible.
"La première sécurité est la liberté"
[^] # Re: Se tenir au courant ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 5.
Dans tout votre baratin, vous oubliez un problème très chiant quand vous adressez un problème utilisant toute la RAM et qui s'approche du maximum en 32 bits. C'est la pénurie d'espace d'adressage.
En gros, linux va mapper des lib partagé un peu partout dans l'espace d'adressage virtuel. Ensuite, l'application va vouloir allouer un gros bloc de 2 Go : et bien il ne pourra pas ! Car l'espace virtuelle (virtuelle pas physique) est saturé. Le problème se pose aussi avec les applications 32 bits sous noyau 64 bits. Sous windows, il y a en plus des libs de converssion 32/64 qui fragmentent encore plus. Ce qui veut dire que des applications fonctionnent avec un windows 32 bits, mais plus avec un windows 64. Il y a même un problème temporel car plus le dernier reboot est loin, et plus de library sont chargés.
"La première sécurité est la liberté"
[^] # Re: Une excellente chose
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Open Beauty Facts : que contiennent vraiment nos produits cosmétiques ?. Évalué à 4.
Pour le savon d'alep, il y a 20% d'une huile essentiel végétale, c'est encore un peu plus agressif.
Si ils ont le droit de le faire, c'est simplement que la marque n'est pas déposée, comme pour Laguiole.
"La première sécurité est la liberté"
[^] # Re: Une excellente chose
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Open Beauty Facts : que contiennent vraiment nos produits cosmétiques ?. Évalué à 1.
Un "savon de marseille" qui n'est pas avec 72% d'huile d'olive….
"La première sécurité est la liberté"
[^] # Re: Correction
Posté par Nicolas Boulay (site web personnel) . En réponse au journal x86 ou x86_64 ?. Évalué à 4.
Le seul et unique cas ou le mot adressé n'est pas un octet, que j'ai vu, sont des anciens DSP de TI qui utilisait des mots de 16 bits à la place. Vu que "sizeof(char) = 1" par définition du langage C, et que un char utilise la plus petite unité de mémoire adressable, tu as des char 16 bits, avec "sizeof(char) = 1". Cela casse tellement de code C, qu'il y avait un mode avec le char en octet !
"La première sécurité est la liberté"
[^] # Re: Open Hardware
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et si on achetait de l'Open Hardware (v2) ?. Évalué à 2.
Si vous cherchez une solution à la "chinoise" avec un gros copro qui sait faire du calcul matriciel, c'est puissant, mais cela nécessite du code réécrit. Et un serveur est loin de faire beaucoup de calcul pure.
En cherchant une autre balance cpu/perf, cela pourrait fonctionner, comme avoir beaucoup de bandes passantes par cpu (remplacer qq Mo de cache par un port DDR 256 bits comme la PS4 au lieu de 128). Et pourquoi pas pouvoir mettre plusieurs ordinateurs sur le même PCB, relié entre eux par un bridge qui pourrait être vu comme une carte réseau par linux. Ce genre de config pourrait être bien quand il y a des dizaines de GO de mémoire (un cache de 16 Mo devenant moins intéressant avec l'augmentation de la taille mémoire).
Je crois aussi beaucoup à des instructions spécifiques pour ce qui prend du temps : compression gzip, crypto, hash,… Je parle bien d'instructions et non de coprocesseurs qui ne sont jamais assez flexible et qui sont "long à lancer" (écriture sur les registres, etc…). Pour supporter ce gens d'instruction, il "suffit" de porter la lib openSSL qui gère la crypto et la libgzip.
Concernant les mémoires rapides spécifiques, les problèmes sont souvent les mêmes : latence identique à la DDR, taille réduite, et prix élevé.
"La première sécurité est la liberté"
[^] # Re: Open Hardware
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et si on achetait de l'Open Hardware (v2) ?. Évalué à 2.
Niveau performance vous serez forcément à la ramasse par rapport à Intel. Quelle niche pensez-vous prendre avec un RISC-V ?
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 4.
Quand tu fais un core tu es obligé de faire les modes avec, sinon les aller-retour sont trop coûteux en temps. Autant tout faire avec le cpu.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 7.
Je confirme que sur les SoC Arm tout est sous forme de core externe, ce qui impose tout un tas de contraintes chiantes :
- L'usage du core n'a aucun intérêt sur les petits paquets en terme de perf (à cause du temps de setup)
- Il n'y a jamais tous les mode (CBC, XTX,…)
- Le support de l'OS est obligatoire
- L'usage par plusieurs applications est compliquée
Bref, la mode des cores à ajouter autour des ARM n'est pas top. Le seul avantage est de pouvoir couper leur alimentation quand on s'en sert pas… (Donc, l'avantage est de ne pas s'en servir…)
"La première sécurité est la liberté"
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 4.
J'imagine que cette puissance ne tient pas compte de la clim, non plus…
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 6.
Non, c'est complètement faux. Ce n'était vraiment pour les tout premiers modèles, ou le décodeurs étaient ultra simpliste : bit de contrôle de l'alu ou du controleur mémoire + adresse de registre. Avec les techno superscalaire, c'est devenu beaucoup plus compliqué. Si le décodeurs x86 est toujours aussi complexe, il l'est autant qu'à l'époque des pentiums.
"La première sécurité est la liberté"
[^] # Re: Bizarre le cadeau d'EDF...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
J'avais aussi en tête le cout des veilles ou le cout d'un frigo de 100W à 100€ dans l'année.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Il faut voir si la comparaison était faite avec "gcc -O2", "gcc -OS" ou "gcc -O3" qui prend forcément plus de place.
Pour le 2), c'est forcément le cas, puisque les registres supplémentaires sont obtenu avec un prefix. Mais d'un autre coté, avoir plus de registres permet souvent de se passer d'accès à la mémoire.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 4.
De nos jours ce qui occupe le plus de silicium, c'est tout le système superscalar pour pouvoir lancer en parallèle l’exécution de plusieurs instructions. C'est quadradic avec le nombre d'étage de pipeline, le nombre d'unité de calcul, et la taille de la fenêtre d'instruction utilisée.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Ce n'est pas faux, mais beaucoup moins vrai depuis le mode 64 bits qui double les registres. De plus, le système superscalaire offre de fait des centaines de registres invisibles.
Je ne retardes pas du tout. Thumb était loin de l'efficacité des x86, très loin même. Il n'offrait même pas toutes les possibilités du jeu 32 bits (ce qui imposait d'utiliser plusieurs instructions 16 bit ou repasser en 32). Thumb2 propose un mode mixte 32/16, j'imagine que tous les nouveau cpu ARM utilise se mode de base. Mais cela reste moins optimal que le code x86, il suffit de comparer la taille des binaires générés.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 8.
C'est complètement faux. Les instructions très spécialisé sont bien plus efficace : instruction AES par exemple, ou simplement les instructions SIMD à 4 opérandes…
Cela ne sert à rien. Un code plus efficace dans le sens classique est aussi un code qui consomme moins.
Cela ne veut rien dire en terme d'architecture. J'imagine que tu veux dire qu'une unité SIMD classique n'a pas les instructions x87 typique comme sin ou cos, et j'imagine que tu veux dire qu'il y a moins de microcode, mais le microcode est géré avant l'unité de calcul.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 3.
Cela n'a rien à voir avec le RISC, et c'est même plutôt faux à cause de la densité du code moins importante.
"La première sécurité est la liberté"
[^] # Re: Rien sur les spécificités du nouveau bébé 1er du top 500 ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le Top 500 des supercalculateurs de juin 2016. Évalué à 5.
Je crois revenir 15 ans en arrière. Cette phrase ne veut rien dire. RISC ou cisc qualifie un jeu d'instruction, dire que tout est "RISC derrière" n'a aucun sens.
Non au contraire, la densité de code est énorme en x86, l'itanium devait avoir des Mega octet de cache pour battre un x86. Et il est mort.
Il te faut qq milliard pour ça. Et il faut avoir le logiciel optimisé qui va avec. Les piles complètes logiciels sous Linux, ne sont pas si vieilles que ça.
AMD annonce une nouvelle architecture 30% plus rapide en monocore pour une même fréquence. Faut-il encore qu'il la sorte rapidement.
"La première sécurité est la liberté"