• # Pan!

    Posté par  . Évalué à 10.

    le gouvernement américain a t-il interdit à Intel et NVIDIA de vendre aux Chinois leurs puces, avec comme argument l’usage que les militaires chinois font du supercalculateur pour simuler des armes nucléaires. Une décision sans effet… autre qu’accélérer la marche à l’indépendance du géant asiatique. Les 40.000 puces de 260 cœurs de calcul dont TaihuLigth est constitué sont de fabrication chinoise, comme l’architecture du supercalculateur.

    Ou comment se tirer une balle dans le pied :)

  • # Faut ajouter des liens au lien !

    Posté par  . Évalué à 4.

    La liste de ces 500 calculateurs : https://www.top500.org/lists/2016/06/

    Les précédents journaux ou dépêches sur le sujet : https://duckduckgo.com/?q=top500+site%3Alinuxfr.org&ia=web

  • # Ça tombe bien, il y en a une en rédaction...

    Posté par  . Évalué à 6.

    qui pourrait tout à fait être une dépêche d'ici.

    Il y en a justement une dans la tribune de rédaction. ;-)

    Pour ceux qui auraient des informations à donner sur le sujet.

    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

  • # Soft power et brute force

    Posté par  . Évalué à 7.

    Outre la nouvelle que ce matos 100% Chinois décime complètement la concurrence, l'autre aspect vraiment intéressant est que ce supercalculateur se dote d'un très bon rapport puissance de calcul/consommation: 6.05 Gflops/W.

    En comparaison, le site green500.org, le petit frère de top500.org, on peut voir que les dernières données (novembre 2015) donne le grand gagnant à 7.03 Gflops/W, tandis que le deuxième au classement pompe 5.33 Gflops/W.

    • [^] # Re: Soft power et brute force

      Posté par  . Évalué à 2. Dernière modification le 29 juin 2016 à 14:17.

      Et surtout c'est quoi l'OS du supercalculateur n°1 ?.
      Dans le top500 il est dit : Sunway RaiseOS 2.0.5

      C'est un gnu/linux adapté ?

      Ou bien c'est un système propriétaire chinois ?

  • # Attention tout de même...

    Posté par  . Évalué à 10. Dernière modification le 29 juin 2016 à 18:05.

    aux chiffres théoriques. Pour avoir travaillé dans le domaine et être toujours un peu au fait des derniers développements, il est de plus en plus difficile d'utiliser cette puissance de calcul.

    Même LINPACK, dont l'algo sous-jacent est probablement parmi les plus massivement parallélisables, n'atteint (dans ce cas-ci) que 74% de la puissance théorique de la machine (93 versus 125 Pflops). Avec des applications plus courantes, on sera probablement loin de ce chiffre.

    Et cette disparité s'accroit d'année en année : les unités de calcul sont de plus en plus spécialisées (GPU, Xeon PHI, etc.), les canaux de transfert sont de plus en plus lents par rapport à la vitesse de traitement (bien que de plus en plus rapides de manière absolue), sans compter la latence (il est tout simplement impossible de relier en point à point 40 000 coeurs, donc il faut des hubs et des switchs, donc plus de latence, etc.), le système de fichiers est loin de suivre en particulier dans les applications de big data, etc.

    Bref, c'est une indéniable prouesse technologique, mais il faut garder en tête qu'en pratique, ce genre de supercalculateur énorme n'est généralement pas plus utile qu'une pléthore de plus petits (par plus petits, j'entends ici 150-200 Tflops, donc petit est tout relatif…) : de toute manière, la grande majorité des chercheurs n'utilisent que quelques noeuds de calcul à la fois.

    Ceci étant dit, l'efficacité énergétique est effectivement un élément à considérer—à mon sens bien plus intéressant que la puissance brute—si on garde en tête que tous les flops ne s'équivalent pas…

    • [^] # Re: Attention tout de même...

      Posté par  . Évalué à 4.

      Je comprends ton argumentaire, mais ça n'enlève rien à la validité de l'annonce. Si le premier a X petaflops et que le second a Y petaflops, et que seuls 74% de la puissance de calcul théorique sont utilisés en pratique, la premer aura 0,74X petaflops et le second aura 0,74Y petaflops, mais l'ordre premier/second est conservé.

      Si, par contre, le coefficient multiplicateur varie selon le calculateur au point que le second repasse devant le premier, là oui, le classement est faux. S'il s'avère que le coefficient multiplicateur est tellement faible qu'il est moins cher/moins polluant de construire des milliers de petits calculateurs, le classement reste exact, mais il est non pertinent.

      Mais en l'absence de ces critères, le classement reste fiable et pertinent, même s'il n'a plus autant de poids.

      Ça, ce sont les sources. Le mouton que tu veux est dedans.

      • [^] # Re: Attention tout de même...

        Posté par  . Évalué à 10.

        Il y a deux éléments à considérer ici :
        1. Est-ce que le ratio performance théorique / performance pratique est similaire pour tous les supercalculateurs?
        2. Est-ce que le benchmark utilisé (HPLINPACK) est représentatif de l'utilisation réelle d'un supercalculateur?

        La réponse à ces deux questions est malheureusement non. J'ai calculé le ratio rMax / rPeak du dernier TOP500 (rMax étant la performance sur LINPACK, un benchmark mais une application réelle néanmoins et rPeak est la puissance théorique obtenue en multipliant la puissance de chaque coeur/noeud par leur nombre). Pour les 35 premiers supercalculateurs, ce ratio varie entre 46 et 94%, avec une moyenne de 76% et un écart-type de 12%. Donc oui, il y a de grandes variations inter-calculateurs.

        Ceci étant dit, on peut me rétorquer que c'est justement la raison pour laquelle il y a un benchmark tel que LINPACK : lui au moins devrait donner la performance réelle du supercalculateur n'est-ce pas? Pas vraiment. À peu près tout le monde s'entend pour dire que ce chiffre n'est pas fiable et surreprésenté (voir la page wikipédia pour un résumé des critiques, mais beaucoup d'articles scientifiques ont été publiés sur le sujet).

        En fait, le problème est très bien connu depuis des décennies et tient (en gros) à une simple formule : la loi d'Amdahl. Cette dernière stipule que le gain lié à la parallélisation est asymptotiquement lié à la portion série du programme (la portion qui ne peut s'exécuter en parallèle). Tout programme possède une portion série, même minimale, ne serait-ce que pour lancer les opérations.

        Supposons que j'aie un programme qui requiert 1000 secondes de traitement sur un seul CPU. Si 75% de mon programme est parallélisable (autrement dit le programme passe 750 secondes dans une section qui peut être parallélisée), alors il est facile de constater que peu importe le nombre de processeurs et l'efficacité de leurs interconnexions, il sera impossible d'exécuter ce programme en moins de 1000-750 = 250 secondes.

        Avec un faible nombre de processeurs, ce n'est généralement pas trop problématique, puisque la portion série peut généralement être réduite suffisamment. Mais lorsque l'on passe à des milliers de coeurs, ça devient nettement plus problématique. Supposons par exemple un ratio de parallélisation de 0.999 (99.9% du programme peut être parallélisé). Ce programme requiert 10 jours (864 000 secondes) pour s'exécuter sur un seul processeur.

        Avec 20 processeurs, l'application de la loi d'Amdahl indique une accélération d'un facteur 19.63 (l'accélération théorique étant de 20, logiquement), soit 12 heures de calcul au lieu de 10 jours. Pas mal!
        Ajoutons maintenant des processeurs : passons à 200. Cette fois, l'accélération est de 166.81x (par rapport à 200x théoriquement), soit un temps de calcul d'environ 1h30. Bon, ça passe encore.
        Passons maintenant à 2000 processeurs : accélération de 666.89x (par rapport à 2000x). 20 000? Accélération de 952x. 200 000? Accélération de 995x. On a atteint l'asymptote.

        Et pourtant, cet exemple est extrêmement favorable : 99.9% de parallélisation, ça se voit extrêmement rarement en pratique lorsqu'il faut prendre en compte les accès disque, la synchronisation entre les noeuds de calcul, le checkpointing, etc. 95% me semble être un taux raisonnable pour les applications courantes (i.e. qui n'ont pas été optimisées aux petits oignons pendant des mois par une équipe d'ingénieurs spécialisés). Dans ce cas, même avec 200 000 processeurs, on va seulement… 20 fois plus rapidement.

        Alors oui bien sûr, il est rare qu'un supercalculateur de 200k processeurs soit utilisé pour une seule tâche—en fait à part pour faire rouler LINPACK, je n'ai jamais vu ça. Mais dans ce cas, de plus petits supercalculateurs peuvent tout aussi bien faire l'affaire, en étant plus près des chercheurs, en réduisant le besoin de construire de nouvelles lignes électriques (16 MW, ça ne s'amène pas comme ça), en réduisant la probabilité d'une panne, etc.

        Je ne suis pas formellement contre le TOP500, je dis simplement que pour 99.9% des chercheurs, il n'y a (littéralement) aucune différence entre un supercalculateur de 150 TFlops et ce dernier monstre de presque 100 PFlops.

        • [^] # Re: Attention tout de même...

          Posté par  . Évalué à 5.

          en réduisant la probabilité d'une panne

          Je dirais plutôt que ça augmente la probabilité d'une panne mais que ça diminue l'impact.

          « 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: Attention tout de même...

          Posté par  (site web personnel) . Évalué à 4.

          J'ai rarement lu une aussi bonne explication sur l'intérêt de vérifier la loi d'Amdahl pour tout code un tant soit peu parallélisé (quand on veut le faire tourner sur un cluster). Merci.

          Je vais te recopier et te citer.

          Proverbe Alien : Sauvez la terre ? Mangez des humains !

  • # Et encore vous n’avez rien vu !

    Posté par  . Évalué à 8. Dernière modification le 29 juin 2016 à 21:12.

    Sunway TaihuLight

    Taihu… Light…

    La version « Full » va envoyer du FLOPS comme un feux d’artifice de nouvel an chinois envoie la poudre.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.