"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.
[^] # 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é"