En puissance brute, c'est très puissant, mais peu d'algorithme peuvent tirer parti d'une telle architecture : les noeuds disparaissent à chaque instant, il faut donc pouvoir relancer le calcul ailleurs et ne pas dépendre du résultat pour lancer d'autres calculs et les noeuds sont faiblements interconnecté, on peut pas utiliser le travail intermédiaire dans un noeud pour le calcul sur un second noeud.
Du coup, c'est une architecture très sympa mais qu'on ne peut pas trop comparé à un supercalculateur classique (d'ailleurs, déjà dans les supercalculateurs, tout n'est pas facilement comparable, déjà le calcul sur carte graphique vs cpu).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Entièrement d'accord. On parle de supercalculateur pour une architecture unique AVEC passage de donnée. Le test est généralement LINPACK, loin d'être optimum mais bon.
Dans le cas présent, on fait de l'embarrassingly parallel. Un joli mot pour dire qu'en fait, on lance N tâches indépendantes en séquentiel. C'est super intéressant comme genre de calcul mais cela ne rentre pas en compte dans un test de supercalculateur puisqu'il y a indépendance des tâches.
À ce genre de calcul bête à celui qui a la plus grosse, internet est le plus puissante calculateur du monde ;-) On se fiche globalement du résultat mais qu'est ce que les processeurs calculent… Enfin, on s'en fiche pas tant que cela car dès que ça merde trop ici ou là, on apporte des correctifs pour que cela continue de marcher correctement.
Après, justement avec LINPACK, le travail est très divisé et il me semble qu'il serait possible de l'adapter pour tourner sur un système très distribué vu n'a pas pas besoin de communication entre les nœuds. On pourrait donc faire tourner une adaptation de LINPACK sur folding@home pour comparer sur la même charge. Après l'intérêt est très limité.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Si je ne me trompes pas, Linpack, c'est de l'algèbre linéaire. C'est parallélisé intelligemment. Mais ça requiert définitivement des communications, et il faut que les matrices soient suffisamment larges par rapport au nombre de processeurs pour atteindre un quelconque niveau d'efficacité.
C'est vrai que ne n'avait pas pensé que le rapport cpu/ram est assez élevé dans le cas de folding@home et qu'en plus, on ne peut sans doute pas se permettre d'utiliser beaucoup de ram.
Par contre, pour les communications, c'est à quel point ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
En fait en lisant wikipedia, Linpack fait un pivot de Gauss et non une extraction de valeur propre comme je le pensais. Dans la version pas intelligente, ça ferait très très peu de communication : on attribuerait des lignes à des processeurs, et à chaque étape on leur fournit le coefficient multiplicateur, et la ligne à retirer. Mais en faisant ça on aurait rapidement des processus qui n'aurait plus de travail (ceux dont les lignes ont atteintes la forme triangulaire souhaitée). Je n'ai pas trouvé l'algo de Linpack, mais il doit y avoir probablement quelques subtilités supplémentaires qui répartissent la charge, et provoquent plus de communications.
Pour folding@home, il s'agit d'intégrer les équations de la dynamiques sur des atomes (parfois sur des molécules ou des bases). Donc essentiellement l'usage mémoire c'est 6 flottants par atome (plus selon les descriptions quelques informations comme la charge, l'état d'hybridation des orbitales…) ; s'y ajoutent des données globales sur le système (forme, environnement) et les méthodes d'intégration (à température constante, à énergie constante…) — qui comptent pour presque rien. Les systèmes sont tout petit au regard des capacités des ordinateurs actuels (quelques dizaines de milliers d'atomes/molécules/bases) dans les pires des cas. Et ensuite, l'intégration se fait à l'échelle de temps des mouvements atomique. Dans le pire des cas la femtoseconde. Et comme le dépliement/rempliement d'une protéine, peut facilement prendre un temps de l'ordre de la seconde ou même de de la semaine, il faut surtout faire beaucoup, beaucoup, beaucoup de pas de temps.
# Oui mais non
Posté par claudex . Évalué à 9.
En puissance brute, c'est très puissant, mais peu d'algorithme peuvent tirer parti d'une telle architecture : les noeuds disparaissent à chaque instant, il faut donc pouvoir relancer le calcul ailleurs et ne pas dépendre du résultat pour lancer d'autres calculs et les noeuds sont faiblements interconnecté, on peut pas utiliser le travail intermédiaire dans un noeud pour le calcul sur un second noeud.
Du coup, c'est une architecture très sympa mais qu'on ne peut pas trop comparé à un supercalculateur classique (d'ailleurs, déjà dans les supercalculateurs, tout n'est pas facilement comparable, déjà le calcul sur carte graphique vs cpu).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui mais non
Posté par Sytoka Modon (site web personnel) . Évalué à 7. Dernière modification le 19 avril 2020 à 11:06.
Entièrement d'accord. On parle de supercalculateur pour une architecture unique AVEC passage de donnée. Le test est généralement LINPACK, loin d'être optimum mais bon.
Dans le cas présent, on fait de l'embarrassingly parallel. Un joli mot pour dire qu'en fait, on lance N tâches indépendantes en séquentiel. C'est super intéressant comme genre de calcul mais cela ne rentre pas en compte dans un test de supercalculateur puisqu'il y a indépendance des tâches.
À ce genre de calcul bête à celui qui a la plus grosse, internet est le plus puissante calculateur du monde ;-) On se fiche globalement du résultat mais qu'est ce que les processeurs calculent… Enfin, on s'en fiche pas tant que cela car dès que ça merde trop ici ou là, on apporte des correctifs pour que cela continue de marcher correctement.
[^] # Re: Oui mais non
Posté par claudex . Évalué à 4.
Après, justement avec LINPACK, le travail est très divisé et il me semble qu'il serait possible de l'adapter pour tourner sur un système très distribué vu n'a pas pas besoin de communication entre les nœuds. On pourrait donc faire tourner une adaptation de LINPACK sur folding@home pour comparer sur la même charge. Après l'intérêt est très limité.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui mais non
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Si je ne me trompes pas, Linpack, c'est de l'algèbre linéaire. C'est parallélisé intelligemment. Mais ça requiert définitivement des communications, et il faut que les matrices soient suffisamment larges par rapport au nombre de processeurs pour atteindre un quelconque niveau d'efficacité.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Oui mais non
Posté par claudex . Évalué à 3.
C'est vrai que ne n'avait pas pensé que le rapport cpu/ram est assez élevé dans le cas de folding@home et qu'en plus, on ne peut sans doute pas se permettre d'utiliser beaucoup de ram.
Par contre, pour les communications, c'est à quel point ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oui mais non
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3.
En fait en lisant wikipedia, Linpack fait un pivot de Gauss et non une extraction de valeur propre comme je le pensais. Dans la version pas intelligente, ça ferait très très peu de communication : on attribuerait des lignes à des processeurs, et à chaque étape on leur fournit le coefficient multiplicateur, et la ligne à retirer. Mais en faisant ça on aurait rapidement des processus qui n'aurait plus de travail (ceux dont les lignes ont atteintes la forme triangulaire souhaitée). Je n'ai pas trouvé l'algo de Linpack, mais il doit y avoir probablement quelques subtilités supplémentaires qui répartissent la charge, et provoquent plus de communications.
Pour folding@home, il s'agit d'intégrer les équations de la dynamiques sur des atomes (parfois sur des molécules ou des bases). Donc essentiellement l'usage mémoire c'est 6 flottants par atome (plus selon les descriptions quelques informations comme la charge, l'état d'hybridation des orbitales…) ; s'y ajoutent des données globales sur le système (forme, environnement) et les méthodes d'intégration (à température constante, à énergie constante…) — qui comptent pour presque rien. Les systèmes sont tout petit au regard des capacités des ordinateurs actuels (quelques dizaines de milliers d'atomes/molécules/bases) dans les pires des cas. Et ensuite, l'intégration se fait à l'échelle de temps des mouvements atomique. Dans le pire des cas la femtoseconde. Et comme le dépliement/rempliement d'une protéine, peut facilement prendre un temps de l'ordre de la seconde ou même de de la semaine, il faut surtout faire beaucoup, beaucoup, beaucoup de pas de temps.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.