Journal Le multicoeur va vraiment devenir problématique

Posté par  (site web personnel) .
Étiquettes : aucune
13
6
fév.
2009
J'en parlai il y a déjà 1 an et demi, mais il semble que le problème - insoluble - de l'invasion du multicoeur inquiète sérieusement l'industrie.

Dans cet article de LMI, un analyste de Gartner tire la sonette d'alarme sur l'avenir du logiciel sur les serveurs.

Le problème n'est même plus de réussir à faire des logiciel capable de faire leur boulot de manière performante avec 32,64,... 512 processus/thread, le problème est que les OS eux-même, en particulier sur x86 gèrent avec difficulté des architecture multicoeur.

Comment vas t-on solutionner cet épineux problème, jusqu'où va aller la multiplication des coeurs dans les processeurs ? 16, car après cela posera trop de problèmes de communication ?

Va t-on assister à l'émergence des langages http://shootout.alioth.debian.org/gp4/benchmark.php?test=thr(...)">qui gèrent correctement le parallélisme (Erlang, Smalltalk, Haskell, etc...) ?

Les hyperviseurs vont ils suivre ?

Plein de question qui supposent beaucoup de changements de perspectives dans l'industrie...
  • # Le multicoeur va vraiment devenir problématique

    Posté par  . Évalué à 10.

    Ben il suffira de revenir au monocoeur.
    • [^] # Re: Le multicoeur va vraiment devenir problématique

      Posté par  . Évalué à 10.

      ... et de multiplier le nombre de CPU .....
      • [^] # Re: Le multicoeur va vraiment devenir problématique

        Posté par  . Évalué à 1.

        pourquoi pas, mais après tout la gestion de la cohérence de la mémoire centrale partagée restera d'actualité.

        Paralléliser au maximum est une bonne chose mais induit des risques d'incohérence puisque une page peut être accédée par plusieurs cpu en même temps, donc plus on ajoute de cpu/coeur, plus il faut gérer les accès concurrents, et plus on peut perdre en performances.

        D'après ce que j'ai pu lire sur le sujet, il existe bon nombre d'algorithme et bon nombre de chercheurs ce sont déjà penché sur le sujet, donc finalement j'ai un peu de mal à voir en quoi augmenter le nb de coeur pose un pb :

        est-ce que les algo de gestion de concurrence sont devenus inefficaces ?

        Pour illustrer mes propos, le document ci-après illustre quelques algorithme de gestion de concurrence :

        http://arcad.essi.fr/cours/systeme2/96-cnam-coherence.pdf

        Le document date un peu mais finalement l'informatique est un phénomène cyclique ou l'on revient souvent en arrière sur d'anciennes théories :)
        • [^] # Re: Le multicoeur va vraiment devenir problématique

          Posté par  . Évalué à 6.

          C'est simple, entre un algo et son implémentation, à peu près 120932409 choses changent. Par exemple, beaucoup d'algos parallèles sont inefficaces en pratique (en tout cas sur un grand nombre de processeurs ou de coeurs) parce qu'ils supposent une synchro entre tous les processeurs à chaque étape. C'est très vite très lourd et ça ralentit beaucoup le tout.

          Une implémentation efficace d'un algo -- qui plus est parallèle -- va devoir finir par tenir compte de certains aspects matériels. Par exemple, les préchargeurs matériels sur les processeurs sont une mâne providentielle pour beaucoup d'usages, mais peuvent provoquer une perte de performance, car ils peuvent introduire en grande quantité du trafic de cohérence de cache inutile.

          De toute façon le multicore est là pour rester, car l'équation concernant la dissipation thermique n'est pas prête d'être révisée. Donc pas la peine de rêver : pour les cinq à dix prochaines années au moins, on va manger du multicore. Autant se faire à la loi d'Amdahl (et à son pendant, celle de Gustafson). Grosso modo, elle dit ceci :

          Pour une implémentation parallèle de la résolution d'un problème et une taille des entrées donnés, on a

          Accélération = 1 / (Par/Nproc + 1-Par),
          où Par = le temps pris par la totalité du code parallèle, 1-Par est la part purement séquentielle, Nproc est le nombre de tâches parallèles exécutées concurremment.

          Pour faire simple, si j'ai parallélisé mon code à 80% (0.8), et que j'ai 16 processeurs/coeurs, on a :

          Accélération = 1 / (0.8/16 + 1-0.8) = 4

          Gustafson est un peu plus optimiste et rappelle que nous allons bosser sur des problèmes de plus en plus gros avec la même machine, et que donc si on fait grossir la part du problème, ce qui faisait avant 80% de parallélisation fera sans doute 85, 90% ou même plus.

          Dans tous les cas, un algo parallèle a tous les problèmes d'un algo séquentiel, avec en plus la part de communications et la contention sur les ressources "rares" (bus mémoire[s], entrées/sorties, etc).
    • [^] # Re: Le multicoeur va vraiment devenir problématique

      Posté par  . Évalué à 10.

      La question est plutôt: "Après avoir tué ses concurrents sur le plan tarifaire, est-ce que l'architecture x86 est finalement destinée à l'entreprise de demain ?"
      • [^] # Re: Le multicoeur va vraiment devenir problématique

        Posté par  . Évalué à 3.

        > l'architecture x86

        Arrêtez avec les critiques débiles sur x86.

        Du journal :
        - "le problème est que les OS eux-même, en particulier sur x86 gèrent avec difficulté des architecture multicoeur."

        Sur quoi est fondé ce truc ?

        Même Cray fournit du x86.
        • [^] # Re: Le multicoeur va vraiment devenir problématique

          Posté par  . Évalué à 5.

          T'as déjà regardé le jeu d'instructions du x86 avant de dire ça ? Voire programmé avec ?
          • [^] # Re: Le multicoeur va vraiment devenir problématique

            Posté par  . Évalué à 3.

            Moi, oui. Et je ne vois pas où tu veux en venir.

            Je ne vois pas non plus le rapport entre le jeu d'instruction (qui concerne chaque processeur de manière indépendante) et le multiprocessing (géré par un composant "externe", les APIC sur x86 si ma mémoire est bonne).
            • [^] # Re: Le multicoeur va vraiment devenir problématique

              Posté par  . Évalué à 6.

              L'architecture x86 a évolué par ajout de couches successives pour aboutir à qqch d'immonde (ISA au départ 16 bits, ensuite étendu à 32, et encore à 64).
              Le nombre de registres disponibles (8 en 16/32, et encore avec 6 concrètement utilisables) est à mourrir de rire. C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe...

              Alors c'est sûr, ce n'est pas spécifique au SMP, ça prouve que c'est juste une architecture de merde.

              Ensuite pour ton information, l'APIC ça ne "gère" pas le SMP dans l'ensemble, ça permet l'aiguillage des interruptions vers les différents CPU dans un système SMP.
              • [^] # Commentaire supprimé

                Posté par  . Évalué à 8.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                  Ca pourrait tenir si l'on oubliait le copprocesseur arithmétique qui fait ce que tu proposes....

                  a = b + c :
                  ld [b] ; pile : b
                  fadd [c] ; pile : b+c(a)
                  fst [a] ; pile : b+c(a)

                  z = b + a
                  ld [b] ; pile : a|b
                  fadd ; pile a+b
                  fstp[z] ; pile vide

                  Il est quand même présent depuis longtemps, donc à moins que tu ne codes en 286 tu cherches quand même à te compliquer la vie... ( En plus ça accélère le process puisque le CPU est déchargé pendant ce temps... )

                  Le vrai problème du x86 c'est de ne pas avoir pu imposer que tous les opérandes ne travaillent qu'avec les accumulateurs, et devoir conserver ce vieil héritage du chargement des données en mémoire. ( et de devoir emuler les instructions pour les rendre compatibles... )
              • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                Alors c'est sûr, ce n'est pas spécifique au SMP, ça prouve que c'est juste une architecture de merde.

                Et c'est sans doute parce que c'est une architecture "de merde" que les x86 ont écrasé leurs concurrents pendant tant d'années.

                Moi, personellement, j'en ai rien à cirer du nombre de registres ou de la facilité à les gérer. Ce qui m'intéresse (et 98% des développeurs), c'est la performance des applications écrites en C. Et si les performances sont à la hauteur, c'est bien la preuve que l'architecture est tout à fait utilisable.
                • [^] # Re: Le multicoeur va vraiment devenir problématique

                  Posté par  . Évalué à 0.

                  Moi ce qui m'intéresse c'est la performance des applications écrites en Python.

                  \_o< ~~

                  Ah ! On me souffle dans l'oreillette hors série que Python ne gère pas le multicoeur. Veuillez poursuivre.
                  • [^] # Re: Le multicoeur va vraiment devenir problématique

                    Posté par  . Évalué à 2.

                    Ah ! On me souffle dans l'oreillette hors série que Python ne gère pas le multicoeur. Veuillez poursuivre.

                    ???
                    • [^] # Re: Le multicoeur va vraiment devenir problématique

                      Posté par  . Évalué à 2.

                      http://jessenoller.com/2009/02/01/python-threads-and-the-glo(...)

                      En gros tu peux faire des threads en python mais ça ne te permettra pas d'exploiter plusieurs cœurs en même temps. Ça peut toujours améliorer le débit de ton appli en ne restant pas bloqué bêtement sur des IO.

                      D'autres implémentation que CPython pourrait proposer un vrai threading.
                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 2.

                        Oui, ca je sais deja, cest malheureusement le cas de nombreux langanges (ruby, squeak...), par contre ca n'empeche pas d'utiliser le multicoeur
                        Python semble proposé des modules spécifiques pour cela, de plus la bonne vieille méthode du fork est tout aussi valable.
                        • [^] # Re: Le multicoeur va vraiment devenir problématique

                          Posté par  . Évalué à 3.

                          la bonne vieille méthode du fork est tout aussi valable.

                          Largement, pour moi. Autant les threads sont rapidement incontournables quand on vise la réactivité (l'approche BeOS d'avoir un fil d'exécution par fenêtre, ça serait ingérable avec des fork()s). Par contre, pour des traitements "lourds", fork()er reste bon marché. Et beaucoup plus "simple" à implémenter/débugguer (bon, c'est pas tant le fork lui-même que les algos utilisés dans ce genre de cas).

                          Pour de la bureautique de base, l'utilisateur va tout naturellement utiliser plusieurs programmes distincts (de très nombreux, même, vu la tendance actuelle) qui sauront tout à fait se répartir entre les coeurs.

                          En fait, j'ai du mal à voir où est le problème, je crois.
                • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                  On sais tous que le x86 a gagné grace à l'argent d'intel et non pour ses propriétés intrinsèques. Si tu avais le même pognon dans le 6502, on serait tous équipés de 6502 aujourd'hui ;-)

                  Ensuite, on bosse pour la plupart sur x86 et on est bien content qu'il marche bien. C'est pas pour cela qu'il faut le bénir.

                  J'ai fait très peu d'assembleur mais le x86 était déjà une horreur. J'espère que le x86_64 est mieux.
                  • [^] # Re: Le multicoeur va vraiment devenir problématique

                    Posté par  . Évalué à 5.

                    On sais tous que le x86 a gagné grace à l'argent d'intel et non pour ses propriétés intrinsèques.
                    Mais aussi parce qu'il etait retro-compatible :
                    les personnes ayant acheté des logiciels proprios, ayant développé du code optimisé en assembleur, ... pouvait toujours le faire tourné sur les nouveaux cpu sans rien acheté de nouveau ni revalider leur code.

                    PS : du coté de arm [1] ca commence aussi à devenir le bordel :
                    il y a le mode 32 bits classiques, le mode thumb (instruction réduite tenant sur 16 bits), le mode thumb2 (ou les instructions sont de taille variable 16 ou 32 bits), et toutes les instructions dsp, SIMD qui ont été ajouté au fil des nouvelles versions...


                    [1] http://en.wikipedia.org/wiki/ARM_architecture
                  • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                    Bon, d'accord, les 8 registres, les 300 instructions qui servent à rien, effectivement c'est horrible; Surtout quand on connait l'histoire de l'x86 qui est le fruit de hasard, de mariages entre une carpe et un lapin, etc...

                    Par contre il y a un truc absolument génial sur l'x86, c'est la gestion de la mémoire. C'est une tuerie : les 4 ring, la segmentation, la gestion de la mémoire paginée, bref le 386, c'est génialement pensé.

                    Pour le reste...

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                    • [^] # Re: Le multicoeur va vraiment devenir problématique

                      Posté par  . Évalué à 4.

                      Par contre il y a un truc absolument génial sur l'x86, c'est la gestion de la mémoire. C'est une tuerie : les 4 ring, la segmentation, la gestion de la mémoire paginée, bref le 386, c'est génialement pensé.

                      Oui, mais bon est-ce réellement utilisé ?
                      Déja la segmentation on dirait pas.
                      Qui utilise les 4 rings ? Linux en utilise 2, Windows 3 ?

                      Je préfère largement une bête table mmu avec un mode user/superviseur.

                      PS : ce qui est une tuerie (un vrai merdier), c'est les differents mode du x86 : real mode, unreal mode, protected mode, virtual mode, ...
                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 5.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                    Si l'alpha est mort, c'est bien parce que le coeur x86 était plus rapide ou à peine moins rapide mais beaucoup moins chère.

                    "La première sécurité est la liberté"

                    • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                      Si l'alpha est mort, c'est que la puissance commercial n'a pas suivis. Ils n'ont pas été capable de produire des PC en grande quantité au même prix.

                      Je me souviens qu'en 98-99, l'Alpha était un grand espoir. J'en ai eu un entre les mains et c'était du bonheur. Mais on ne les trouvais plus ensuite ou alors a des prix défiant toute concurrence...

                      Si mes souvenirs sont bons, Windows tournait aussi sur Alpha (mais pas chez nous, on tournait déjà sous debian).

                      Des arguments de compatibilité sont donnés pour expliquer la force de l'x86, mais il y a encore peu, il y avait plus de processeur de la gamme ARM de fabriqué que de dérivée x86 ! Je n'ai pas les chiffres actuels.

                      Apple n'a pas arrêter de changer de processeur et est toujours là avec son OS qui monte, qui monte...

                      Le x86 arrive sur sa fin, le amd64 le remplace progressivement. Même s'il y a un mode compatible, pour moi, ce sont quand même deux processeurs différents, on le voit bien, c'est pas la même version de Linux, de Windows...

                      Donc, l'OS dominant Windows va être obligé de passer en grande série sur Windows64 et les éditeurs seront obligé de suivre. La compatibilité sera cassé comme elle l'a été entre Windows 3.11 et Windows 95. Et Windows 64 sera encore l'OS dominant car Linux n'a pas encore assez de part de marché pour renverser la tendance, l'échéance me semble trop proche.

                      Sinon, il y a comme dis plus bas l'Itanium d'Intel mais, pour en avoir une machine Itanium, il ne doit pas y avoir le dixième (centième) des moyens de l'amd64 sur l'Itanium. Si cela continue ainsi, l'Itanium va mourrir gentilement. A mon sens, Intel est en train de fusionner les deux gammes Itanium et amd64, le chipset sera commun, les cartes mères... On va pouvoir faire des vrais machines SMP avec de l'amd64. Je ne sais pas ce qu'il va rester à l'Itanium, le rôle d'un coprocesseur ?

                      Bref, le x86 a encore de l'avenir devant lui mais comme pour le 8086 avant lui, il sera la mais va doucement disparaitre pour laisser la place a l'amd64.

                      PS : comme debian, je préfère l'appellation amd64 a x86_64 car c'est une creation AMD et non Intel. L'appellation amd64 redonne donc a AMD ce qui est a AMD.
                    • [^] # Re: Le multicoeur va vraiment devenir problématique

                      Posté par  . Évalué à 6.

                      Si l'alpha est mort, c'est bien parce que le coeur x86 était plus rapide ou à peine moins rapide mais beaucoup moins chère.

                      Moins cher, je veux bien, mais en terme de rapidité, il n'y avait pas photo. Je me souviens avoir utilisé Windows NT4 en 96-97 sur des machines DEC Alpha, c'était incroyablement rapide (et encore plus avec Digital UNIX, je faisais du Fortran). Même les applis Windows compilées pour x86 pouvaient tourner avec un émulateur (FX!32), et elles étaient à peine moins rapides que sur des archis natives.

                      Non, à mon avis, ce qui a vraiment tué l'Alpha, c'est le rachat de DEC par Compaq, puis de Compaq par HP. Le produit a subi une concurrence interne et a été mis sur une voie de garage.
                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 2.

                        le processeur Alpha était certes rapide (200 MHz dès sa sortie) mais il nécessitait du matériel qui allait bien pour en tirer profit

                        dont de la mémoire très rapide... et hors de prix
                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 4.

                        non, à mon avis, ce qui a vraiment tué l'Alpha,

                        D'après un ami, ancien cadre de digital:
                        Le PDG et le consei d'administration ont volontairement fait couler DEC. On s'est longtemps demandé pourquoi. On a compris après la vente à Compaq et Intel: les stock-options, le montant des (nouvelles) dividendes, ... l'argent du rachat quoi.

                        c'est le rachat de DEC par Compaq

                        Si mes souvenirs sont bons, la division processeur (l'alpha donc) a été rachetée par Intel.

                        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                    • [^] # Re: Le multicoeur va vraiment devenir problématique

                      Posté par  . Évalué à 3.

                      Je pense que tu oublie un detail. A l'epoque, le logiciel libre n'etait pas aussi developper, et sans windows et ses applications x86 32 bits, tu avais juste pas grand chose. Alpha, ARM, MIPS, Power, Sparc en ont clairement souffert. Et on ne commence a voir leur retour que depuis recement, mais on ne passe pas du jour au lendemain de moins de 1% de part de marcher sur le desktop a une part visible du parc.
                  • [^] # Re: Le multicoeur va vraiment devenir problématique

                    Posté par  . Évalué à 5.

                    Tu n'en sais absolument rien si les performances sont bonnes : Il n'y a plus aucuns points de comparaison.

                    Bien sûr que si, il y a encore des points de comparaison.
                    Sun continue à développer des processeurs Sparc, et IBM des processeurs POWER. Par ailleurs Intel lui-même développe une architecture concurrente depuis 15 ans, l'Itanium.
                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 4.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 1.

                        J'aimerais savoir comment tu peux dire que le PowerPC et le POWER ont des moyens de développement inférieurs à ceux du x86, quand on sait qui est derrière (IBM).
                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 7.

                          Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 1.

                        Pourtant, les sparc, les powerpc, cell ne tirent pas trop mal leur épingle du jeu question performance malgré les moyens bien inférieur d'investi. Moyens inférieurs, néanmoins bonnes performances, cela veut dire une seule chose : meilleur architecture !

                        Les Sparc sont à la ramasse, quant aux processeurs POWER il faudrait voir le budget de la division processeurs d'IBM, je ne pense pas que ce soit minuscule. De plus les processeurs POWER ont une dissipation thermique énorme.
                  • [^] # Re: Le multicoeur va vraiment devenir problématique

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


                    Le compilateur lui n'en a pas rien à foutre. Le jeux d'instruction et le nombre de registres sont des facteurs vraiment important dans les phases d'optimisation. Avec une telle architecture :
                    - les capacités de parallélisation au niveau des instructions (superscalar) sont gravement impactées
                    - la réutilisation des valeurs dans les registres est compromise [2]
                    - l'utilisation de la cache du processeur n'est pas optimale


                    Je suis bien au courant, mais toute ma réponse tient dans la réponse de Nicolas Boulay:

                    Si l'alpha est mort, c'est bien parce que le coeur x86 était plus rapide ou à peine moins rapide mais beaucoup moins chère.

                    Les registres en plus, c'est peut être pratique, mais c'est sans doute aussi plus cher. Si avec un bon compilo, on arrive presque aux mêmes performances avec moins de registres et pour moins cher, quel intérêt d'en avoir plus?
                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 4.

                      Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 4.

                        L'alpha avait quand même un léger problème de dissipation thermique ...
                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 2.

                          Ce commentaire a été supprimé par l’équipe de modération.

                      • [^] # Re: Le multicoeur va vraiment devenir problématique

                        Posté par  . Évalué à 3.

                        Il suffirait de 16 régistres pouvant être utilisés de façon orhogonale pour rendre les performances, amha, 1,5 à 2 fois meilleures.

                        Tu viens de décrire le x86-64. Sauf que l'amélioration de performances est plutôt de l'ordre de 10 à 30%, il me semble.
                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 3.

                          Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Commentaire supprimé

                          Posté par  . Évalué à 2.

                          Ce commentaire a été supprimé par l’équipe de modération.

                          • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                            Sauf que le renommage de registres doit beaucoup limiter le problème.

                            Sur un athlon avec 3 décodeurs, 5 unité d'executions, l'ilp moyen est de 1.9...

                            Donc, ce genre de problème est minime. (Je rappelle qu'un cache miss, c'est 100 cycles de perdu)

                            "La première sécurité est la liberté"

                            • [^] # Commentaire supprimé

                              Posté par  . Évalué à 2.

                              Ce commentaire a été supprimé par l’équipe de modération.

                              • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                                Sauf que tes loads peuvent prendre de 3 à 100 cycles, que ton "3) mov rbx, rax" revient à une allocation d'un nouveau registre caché, qu'il y a dans un code plus de lecture que d'écriture, donc que le problème se pose moins souvent dans les cas réel.

                                Dans ton exemple, je pense que les 6 instructions sont exécutables en parallèle car les mov sont simplifiables et revienne à ton deuxième cas (les seuls vrais dépendances sont les read after write).

                                Sinon cela coute cher, c'est bien pour ça que Intel va introduire la notation à 3 registres dans une prochaine révision du SSE.

                                (ne pas oublier aussi que la notation à 2 registres sauve 3 à 4 bits par instructions ! cela participe à la grande compacité du code x86, et donc à l'efficacité de son cache instruction à comparer avec les caches itanium !)

                                "La première sécurité est la liberté"

                                • [^] # Commentaire supprimé

                                  Posté par  . Évalué à 3.

                                  Ce commentaire a été supprimé par l’équipe de modération.

                                  • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                                    Disons que intel va les introduire pour le code SSE dont il n'a pas envie de faire des calculs de dépendances et autre execution dans le désordre. Il doit juger que les instructions SSE ne sont utilisé qu'en coeur de boucle et donc que la taille du mot d'instruction à peu d'impact sur le cache instruction.

                                    "La première sécurité est la liberté"

                    • [^] # Re: Le multicoeur va vraiment devenir problématique

                      Posté par  . Évalué à 6.

                      En pratique, les processeurs x86 ont une micro-architecture RISC derrière le gros bidule CISC que tout le monde voit. Il y a énormément de registres qui sont gérés directement par le matériel, et qui sont non-adressables par le programmeur ou le compilateur. Il n'y a donc pas « moins » de registres que sur les autres processeurs.
                      • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                        risc/cisc s'applique comme leur nom l'indique au jeu d'instruction et surtout pas à la micro-architecture qu'il y a derrière !

                        Les systèmes de renomages de registre permet de voir plus de registres mais nécessite beaucoup de silicium.

                        Donc, pour avoir la même performance, il faut plus de Si, mais cela prends moins de place dans le mots d'instruction, donc cela diminue la taille des programmes. Ce n'est pas simple !

                        "La première sécurité est la liberté"

                        • [^] # Re: Le multicoeur va vraiment devenir problématique

                          Posté par  . Évalué à 2.

                          on veut du VLIW \o/
                          • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                            Comme l'itanium ? :/

                            "La première sécurité est la liberté"

                            • [^] # Re: Le multicoeur va vraiment devenir problématique

                              Posté par  . Évalué à 4.

                              Bon ok, l'Itanium est mort. En plus, si en calcul flottant l'Itanium 2 est une machine de guerre, en entier il faut bien avouer que c'est tout pourri. Maintenant je me permets de faire une petite prédiction : avec l'arrivée du Larrabee et des processeurs "many core" en règle générale, je prédis que les systèmes d'exécution dans le désordre vont plus ou moins disparaître (ça prend plein de place, ça consomme plein d'énergie, etc...). Et là, Intel va ressortir des cartons tout ce qu'il a fait sur l'Itanium et son exécution dans l'ordre pour les compilateurs. Ce ne serait d'ailleurs pas forcément un mal, vu que pour le moment, même en cherchant à faire du mieux qu'on peut, sur un core 2 @ 2GHz, avec potentiellement 8 GFLOPS / coeur, si on arrive à faire 6 GFLOPS, on est déjà très content (j'ai jamais vu mieux). 75% des perfs crête c'est quand même pas génial, comparé aux 95% d'un processeur VLIW couplé à un bon compilateur.
                              • [^] # Re: Le multicoeur va vraiment devenir problématique

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

                                75 ou 95 il faut voir de quel calcul on parle. Un VLIW a tout de même beaucoup de calcul exécuté pour rien, par rapport à un code généraliste (par opposition à un code bourrin à base de matrice) à cause de la gestion par prédicats.

                                "La première sécurité est la liberté"

                                • [^] # Re: Le multicoeur va vraiment devenir problématique

                                  Posté par  . Évalué à 3.

                                  On est bien d'accord, je parlais de calculs très réguliers, qui se passent bien, et pour lesquels le fait de dérouler comme un malade apporte une super performance (incidemment, sur Core 2, dérouler beaucoup n'est pas spécialement une bonne idée).

                                  D'accord aussi pour la question des instructions prédicatées. Maintenant avec les VLIW on a quand même eu droit à tout un tas d'algos « spécifiques » pour la transformation de code (supertraces/superblocs/hyperblocs entre autres). La plupart du temps, elles nécessitent assez de mémoire pour en profiter (car on doit générer beaucoup de versions différentes des mêmes blocs d'instructions initiaux), mais sur une machine telle que l'Itanium 2 (surtout le Montecito, avec ses 1 Mo de L2I) ce n'était pas trop un problème.

                                  Ça n'empêche pas que sur une machine out-of-order, les codes « pourris » -- ie dont le code machine/assembleur a été mal ordonnancé, l'allocation des registres pas forcément bien fichue [1] se débrouillent pas trop mal, mais les codes bien fichus en pâtissent...


                                  [1] Bon ok, sur x86, avec ses 16 registres généraux et ses 16 registres SSE donc très spécialisés, c'est pas forcément le plus simple pour l'alloc des registres.
                • [^] # Re: Le multicoeur va vraiment devenir problématique

                  Posté par  . Évalué à 4.

                  Et c'est sans doute parce que c'est une architecture "de merde" que les x86 ont écrasé leurs concurrents pendant tant d'années.

                  Non c'est à cause de Windows.

                  Ça reste de la merde (même si c'est vrai que c'est rapide, enfin tout dépend de ta mesure, si tu calcul des rapports puissance / prix ou puissance / conso tu trouveras que c'est pas si rapide que ça, sauf qu'en France on s'en fiche grâce à toutes nos centrales nucléaires -- de toute manière pour la plupart des gens qui veulent Windows, ils ont au final pas le choix, donc fin du débat).
              • [^] # Re: Le multicoeur va vraiment devenir problématique

                Posté par  . Évalué à 3.

                C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe...

                Et, au final, on s'en contrefout, puisque c'est le compilateur qui fait le boulot.

                Par ailleurs le journal est juste un troll de première classe, l'architecture x86 n'est pas pire que les autres pour faire du multicoeur (Linus Torvalds semble même penser que son modèle de cohérence mémoire -- memory ordering model -- est plus sain que celui d'autres architectures).
          • [^] # Re: Le multicoeur va vraiment devenir problématique

            Posté par  . Évalué à 3.

            Non.
            Mais x86 des années 80 n'est pas celui d'aujourd'hui.
            Entre autre, les efforts sont maintenant sur x86_64. Certe ce dernier est compatible x86, mais un x86 est tout petit à côté d'un x86_64 (qui doit avoir MMX2, SSE3, etc).
  • # Où est le problème ?

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

    Je pense que tu devrais arrêter de te poser des questions aussi précises sur l'informatique que l'on aura dans 3-4 ans.
    Il n'y a que Gartner qui peut faire des prévisions de ce genre...

    Pour le reste, quand il y a eu un "problème", il y a toujours eu des solutions.
    Que l'on ait pas la solution "parfaite" aujourd'hui pour les ordinateurs de demain, cela n'est pas un problème ... à mon avis.

    Et comme tu le dis, dans ton journal, on a déjà le début d'éléments théoriques.
    Ce qui est plutôt bon signe à ce stade.
    • [^] # Re: Où est le problème ?

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

      Je pense que tu devrais arrêter de te poser des questions aussi précises sur l'informatique que l'on aura dans 3-4 ans.
      J'aime ça, je trouve ça marrant, et j'aime pas vivre au jour le jour ('fin si, de plus en plus et c'est pas plus mal). Si c'est ton truc de pas te poser de questions, parce que c'est "imprévisible", bahh, c'est cool pour toi :-)

      Et comme tu le dis, dans ton journal, on a déjà le début d'éléments théoriques.
      Ce qui est plutôt bon signe à ce stade.

      Pas faux, mais il restent des problèmes... La théorie, c'est bien, mais dans une SSII j'en connais peu qui s'y connaissent un minimum..

      - Comment apprend t-on au dev moyen à coder avec des threads... en java ? (oui je sais, ya leur nouveau fork/join)
      - Comment on debug sur des logiciels multithreadé et donc très peu déterministe ?
      - On fait comment pour gérer les perfs ? Gérer le partage de mémoire ? etc...
      - Combien de temps ça va mettre d'avoir de la gestion automatique de parallélisme dans les langages/framework mainstream ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 3.

        - Combien de temps ça va mettre d'avoir de la gestion automatique de parallélisme dans les langages/framework mainstream ?

        Il suffit d'utiliser des outils modernes tel que le Fortran! :D
      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 7.

        Comment apprend t-on au dev moyen à coder avec des threads... en java
        On lui apprend pas, soit on le passe sur un autre paradigme (programmation fonctionelle), soit on lui met un framework qui gère çà à sa place.

        Comment on debug sur des logiciels multithreadé et donc très peu déterministe ?
        Dans une VM en évaluation multi-état. On va se retrouver avec de plus en plus de routeur d'info à la centralisateur COM/shm ou autre RMI. Après c'est assez lourd, mais comme ca n'interressera que les devs de framework et pas les devs moyens, ca devrait passer.

        On fait comment pour gérer les perfs ? Gérer le partage de mémoire ? etc...
        On fait pas, on laisse de CPU et le noyeau se débrouiller tous seuls, et surtout, surtout on ne s'en mêle pas. Il y a plus grand monde capable de battre la gestion mémoire ou l'allocation de perf d'un système sur une application quelconque. (N.B : et arréter de coder des systèmes de gestion du cache mémoire aussi...)

        Combien de temps ça va mettre d'avoir de la gestion automatique de parallélisme dans les langages/framework mainstream ?
        Si par Framework mainstream on parle de .Net ou de J2EE 1.3+, c'est déjà fait.
        • [^] # Re: Où est le problème ?

          Posté par  . Évalué à 2.

          On fait comment pour gérer les perfs ? Gérer le partage de mémoire ? etc...
          On fait pas, on laisse de CPU et le noyeau se débrouiller tous seuls, et surtout, surtout on ne s'en mêle pas. Il y a plus grand monde capable de battre la gestion mémoire ou l'allocation de perf d'un système sur une application quelconque. (N.B : et arréter de coder des systèmes de gestion du cache mémoire aussi...)


          Complètement d'accord :)

          Et à ce sujet, voir cette page http://varnish.projects.linpro.no/wiki/ArchitectNotes que je trouve très instructive.
        • [^] # Re: Où est le problème ?

          Posté par  . Évalué à 1.

          ahahah les mythes de :

          1) arrêtons de faire manuellement X, Y ou Z car c'est toujours mieux fait automatiquement.

          2) tous les logiciels de la galaxie sont de haut niveau et doivent être écrit en C# / Java / Whatever.

          Les années passent est c'est une vision toujours autant approximative et partielle (bon allez je suis gentil donc j'ajoute : presque ;)
      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 2.

        Hé ho, laisse-nous un peu le temps de faire les outils ! :-)
        Grâce à tout ce merdier multicore, je pense que j'aurai du boulot pour encore quelques années.

        Les outils qui gèrent le multicore existent pourtant en partie, mais malheureusement ne sont pas libres : DDT et Total View par exemple (qui ont aussi plein de défauts) sont des debuggers fait exprès pour les programmes parallèles (ils comprennent même MPI et OpenMP).

        gdb gère les threads POSIX, et DDD (qui a récemment repris son dév) est capable d'en tirer parti.

        C'est pas encore la joie, mais ça avance. Il existe tout un tas d'outils pour analyser la mémoire (ValGrind et Acumem [non-libre] sur x86 par ex).

        C'est loin d'être suffisant, mais je pense qu'il faudra encore 5 ans mini pour avoir des outils utilisables par des non-experts pour trouver les bugs ET améliorer les perfs. Mais ça va venir, nécessairement.
    • [^] # Re: Où est le problème ?

      Posté par  (Mastodon) . Évalué à 7.

      Le problème c'est que ce n'est pas un problème futur, c'est un problème maintenant.

      Quand tu achètes un serveur, tu n'as plus que du multicoeur. Et des fois, quand tu changes de serveur, c'est pour des questions de performances. Quand tu te retrouves avec une vieille application monothread dont tu sais pertinemment que l'éditeur ne pourra pas tout recoder en multithread dans les mois qui viennent, et que tes performances sont en baisses (nombre d'utilisateurs plus grands, base énorme, etc...) et que tu te rends compte que tu ne peux améliorer les perfs que marginalement (plus de mémoire, disques plus rapide, mais cpu pas plus rapide, voire plus lents), t'as l'impression de t'être fait rouler.

      L'avantage c'est que parfois, quand ta boite a un département developpement efficace, c'est un peu le coup de pied au cul qui peut te permettre de redevelopper ce dont tu as besoin et t'affranchir d'un éditeur tiers de solution propriétaire. Mais ça ne se fait pas en un jour et c'est toujours au détriment d'autre chose.

      En tout cas c'est une réalité que l'on vit déjà dans ma boite (les applications de plus de 10 ans, c'est fréquent).
      • [^] # Re: Où est le problème ?

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

        Bonjour,

        L'avantage du multi-coeur est tout de même significatif. Même avec des programmes de 10 ans, c'est un pur bonheur de pouvoir en lancer plusieurs sans aucun ralentissement, ou presque (et sur ce point, les 3 OS principaux se débrouillent encore pas trop mal).

        J'ai eu l'occasion d'utiliser deux ordinateurs, dont les processeurs allaient à la même vitesse, en étant de la même architecture, et avec presque la même configuration matérielle. Sur le premier, quand j'ai démarré GIMP pendant que je compilais un programme, la compilation a été fortement ralentie, et GIMP aussi.

        Sur le deuxième, tout s'est magnifiquement bien passé, et les deux tâches étaient aussi rapide que si l'ordinateur était occupé à ne rien faire.

        De même, sur les serveurs, quand on utilise des applications modernes (donc moins de 15 ans), on n'a pas ce problème. Ca fait très longtemps que les serveurs sont équipés de plusieurs processeurs. La preuve : Linux gère parfaitement le multi-coeur, et Microsoft a annoncé en grande pompe que Windows NT 4 gérait le multi-processeur.

        Par exemple, Apache lance plusieurs processus en même temps, et même il y a pas mal de temps, avoir deux processeurs signifiait qu'il y en avait 1 pour MySQL/PgSQL/etc et un autre pour Apache et le reste.

        Bref, je n'ai jamais connu de problèmes avec le multi-coeur et le multi-processeurs, et mon père monte des ordinateurs avec 2 Quand Core dedans (donc 8 coeurs), et ça marche magnifiquement bien (c'est pour du montage vidéo temps réel).

        A plus.
        • [^] # Re: Où est le problème ?

          Posté par  (Mastodon) . Évalué à 0.

          il y'a des exemples dans les 2 sens.

          Pour moi l'exemple de gimp sur un desktop pendant une compilation n'est pas significatif de ce genre de problématiques. Sur un desktop, on a tendance à faire beaucoup de chose en même temps : musique, navigateur web + autres applis. Sur un serveur on multiplie en général moins les usage, à la fois pour des questions de performances mais aussi de sécurité. Et toute les applications ne prennent pas autant avantage d'un multicoeur comme ton exemple d'Apache.

          Une base Oracle par exemple peut tirer avantage de plusieurs coeurs, mais jusqu'à une certaines limite. Mais quand on parle de serveurs actuellement sur le marché avec 128 coeurs, on est déjà très loin de cette limite. Ces machines ne trouvent leur avantage que dans la virtualisation, mais ça n'en fait pas des bêtes de course.
          • [^] # Re: Où est le problème ?

            Posté par  . Évalué à 1.

            " ...Une base Oracle par exemple peut tirer avantage de plusieurs coeurs, mais jusqu'à une certaines limite...."


            Foutaise !!!

            Au contraire: chaque connexion à une instance Oracle correspond à un nouveau processus/thread démarré sur le système (en mode serveur dédié, donc par défaut), donc bénéficie parfaitement du nombre de CPU.... plus il y en a, mieux c'est !!! (indépendamment du reste: IO, bus, mémoire, etc...)

            Et même en paramétrant un peu, pour des requêtes DSS, on peut utiliser le Parallel Query Option: une même requête SQL est divisée pour être exécutée en paralléle par plusieurs slaves....
            • [^] # Re: Où est le problème ?

              Posté par  . Évalué à 1.

              Au contraire: chaque connexion à une instance Oracle correspond à un nouveau processus/thread démarré sur le système (en mode serveur dédié, donc par défaut), donc bénéficie parfaitement du nombre de CPU.... plus il y en a, mieux c'est !!! (indépendamment du reste: IO, bus, mémoire, etc...)

              Et bien sur Oracle à une architecture shared nothing entre tout ces threads qui devine le résultat de ta requête grâce à un oracle.... Rappelle moi de ne jamais t'embaucher pour bosser sur une appli parallèle.

              http://forge.mysql.com/w/images/7/73/Mysqlscale.pdf pour te faire un peu de culture. C'est une introduction, c'est un peu plus compliqué dans la réalité.

              Même si c'était le cas, les OS actuels galèrent pas mal si tu augmentes significativement le nombre de coeurs. Genre simplement pour se partager une carte réseau et réussir à saturer du 10Gb. On peut aussi aller jouer dans le VFS ou dans le VMM si tu veux aussi.
              • [^] # Re: Où est le problème ?

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

                Enfin, Linux gère 4096 coeurs... Je sais que SGI a fait une machine SMP a plus de 1024 coeur qui marche.

                Au dela de 1024 ceurs, il faut aussi que les codes tournent... mais bon, j'ai vu un 'vrai' code tourner sur plus de 10000 coeurs en restant efficace. Cela fait plaisir de voir que cela marche. La limite n'est pas encore la.
                • [^] # Re: Où est le problème ?

                  Posté par  . Évalué à 3.

                  Il y a une différence entre gérer, et être performant/scaler pour une application quelconque.

                  De mémoire il me semble que tu bosses dans le HPC. Dans ce contexte oui, pour du code dédié à un hardware et qui fait des choses assez "limité" ca fonctionne. Le multicore expose les problèmes que l'on a dans le HPC depuis quelques dizaines d'années...

                  Dire qu'actuellement les OS sont capables de scaler linéairement sur 1024 cores pour une charge de travail généraliste n'est pas vrai.

                  Le premier papier intéressant qui me vient à l'esprit est corey, qui à des propositions intéressantes pour des archis fortement multicore: http://www.mit.edu/~y_z/papers/corey-osdi08.pdf
                  • [^] # Re: Où est le problème ?

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

                    Je suis d'accord avec toi mais il était bon de dire que Linux sais faire tourner des codes sur plus de 128 coeurs dès aujourd'hui.

                    Ensuite, il est clair que le mode de fonctionnement n'est pas exactement le même sur un bureau que sur une machine de calcul.
          • [^] # Re: Où est le problème ?

            Posté par  . Évalué à 5.

            Sur un desktop, on a tendance à faire beaucoup de chose en même temps : musique, navigateur web + autres applis. Sur un serveur on multiplie en général moins les usage

            C'est vraiment n'importe quoi là (bis).
            Au contraire, un serveur par construction va souvent devoir servir plusieurs utilisateurs à la fois et de façon indépendante, ce qui est tout de même un vecteur idéal de parallélisation.
            Après, si l'appli utilisée ne le permet pas, c'est qu'elle a été écrite par des guignols (bis repetita, cf. plus haut).
            • [^] # Re: Où est le problème ?

              Posté par  (Mastodon) . Évalué à 3.

              Après, si l'appli utilisée ne le permet pas, c'est qu'elle a été écrite par des guignols (bis repetita, cf. plus haut).

              oui c'est bien ce que je dis. Et dans la vrai vie, et en entreprise, on est aussi confronté à des . Et lâ-bas on n'a pas vraiment le droit de leur donner des claques, donc il faut faire avec et trouver les solutions la où elles sont.
      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 2.

        On sait depuis des lustes qu'il vaut mieux un cpu (ou coeur) de puissance X que n cpu (ou coeur) de puissance X/n.
        Il n'y a rien de nouveau ici. Après qu'il y ait des gogos qui croit l'inverse...
        • [^] # Re: Où est le problème ?

          Posté par  . Évalué à 0.

          On sait depuis des lustes qu'il vaut mieux un cpu (ou coeur) de puissance X que n cpu (ou coeur) de puissance X/n.

          C'est clair, il vaut beaucoup mieux avoir une opération synchrone qui bloque le processeur d'un coté en attendant (par exemple) un retour I/O ou une synchro du cache que de pouvoir faire autre chose sur un autre processeur en attendant.

          Par exemple il vaut nettement mieux faire tourner à la queue leu leu 200 processus dont une dizaine font de petites opérations mais qui requièrent un appel système avec changement de contexte à la clef, que de faire tourner les mêmes processus chacun dans leur coin sur des processeurs séparés.

          Il n'y a rien de nouveau ici. Après qu'il y ait des gogos qui croit l'inverse...

          Elle est longue la liste des gogos... A moins que tu ne sois encore sur un OS monotache mono utilisateur.
          • [^] # Re: Où est le problème ?

            Posté par  . Évalué à 2.

            C'est ni aussi tranché dans un sens, ni dans l'autre...
            • [^] # Re: Où est le problème ?

              Posté par  . Évalué à 2.

              C'est ni aussi tranché dans un sens, ni dans l'autre...

              Je n'ai jamais dit que c'était tranché, c'est juste que d'entendre se faire traiter de "gogos" les gens qui pensent que 4 processeurs de puissance X c'est mieux qu'un processeur de puissance 4X m'a un peu hérissé.

              En applications réseaux, qui représentent quand même aujourd'hui une grosse part des applications existantes, sur les applications multi-threads on a quand même des gains par coeur/processeur qui sont très proche des 100% voir au delà (dès qu'il y a assez de processeurs pour limiter les besoins en context switch, ca a tendance à dépoter pas mal)
              • [^] # Re: Où est le problème ?

                Posté par  . Évalué à 2.

                Les contextes switch sur un Linux sont assez légers et sur un serveur configuré correctement (généralement avec un HZ pas trop grand et sans PREEMPT) tu ne gagnera pas grand chose en remplaçant un CPU d'une puissance X par 4 CPU d'une puissance X/4 chacun, sauf éventuellement à cause d'effet des caches, mais bon c'est de la triche, ça voudrait dire qu'ils ont une puissance qui est en fait > à X/4 chacun.

                Après selon l'application précise la balance peut pencher d'un coté ou de l'autre, selon des critères qu'on peut trouver parfois surprenant (par exemple pour mitiger des problèmes de fiabilités je préfère qu'un programme massivement multithreadé et codé avec les pieds tourne sur un mono-cpu mono-coeur et Linux non preempt).
                • [^] # Re: Où est le problème ?

                  Posté par  . Évalué à 2.

                  Les contextes switch sur un Linux sont assez légers et sur un serveur configuré correctement

                  Vu la longueur des pipelines des CPU modernes ce sont quand même au minimum trente cycles qui partent à la poubelle à chaque changement de contexte.

                  Même si ca n'est pas si grave, c'est quand même un beau gaspillage.

                  Après pour les programmes codés avec les pieds et qui nécessitent une synchro fréquente des threads je suis d'accord avec toi. Pour le reste je suis plus mitigé, surtout quand il y a une VM (.Net, python ou Java) au millieu.
                • [^] # Re: Où est le problème ?

                  Posté par  . Évalué à 3.

                  c'est pas tant les context switch qui permettent d'améliorer les perfs (même si ca joue) mais les effets de caches.

                  Si toutes les données tiennent dans le cache L1 avec un X/4 , alors qu'elles ne tennaient pas avec un X, tu "risque" de passer en super scalaire (que l'augmentation perfs de ton soft par rapport à si il tournait sur un seul core soit supérieur au nombre de cores).
          • [^] # Re: Où est le problème ?

            Posté par  . Évalué à 9.

            C'est clair, il vaut beaucoup mieux avoir une opération synchrone qui bloque le processeur d'un coté en attendant (par exemple) un retour I/O

            Heu... c'est quoi ton OS ?
            Parce que n'importe quel OS digne de ce nom va ordonnancer un autre processus si le processus actuel se trouve bloqué à attendre un retour I/O.
            • [^] # Re: Où est le problème ?

              Posté par  . Évalué à 4.

              Heu... c'est quoi ton OS ?
              Parce que n'importe quel OS digne de ce nom va ordonnancer un autre processus si le processus actuel se trouve bloqué à attendre un retour I/O.


              Pour être exact n'importe quel OS digne de ce nom va relancer un ordononancement des taches avec context switch à la clef, ce qui
              1) est horriblement couteux en terme de perfs
              2) est mathématiquement impossible à optimiser (ca revient à répondre à la question "quand un programme va-t-il finir")
              3) n'est de toutes les façons pas toujours possible (Il est assez mauvais de passer la main à un autre périph quand on en pleine initialisation d'un périphérique, par exemple)
      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 7.

        Sans compter les prestataires/développeurs qui n'ont jamais entendu parler d'optimisation, et qui te font des specs à la noix ...

        Exemple vécu pour une appli web/flash à la google maps, pour 200 utilisateurs réguliers : 1 serveur frontal+2 serveurs d'applis en load balancing, chaque machine devant être au minimum des bipro avec 8Go de RAM. Soit.

        Puis tu découvres que :
        - l'appli (censée être du J2EE) fait son load balancing elle-même, et très mal,
        - le prestataire a fait l'install sur des serveurs windows 32 bits (mal barré pour mettre 8Go de RAM). Personne dans la boite ne s'est posé la question de la compatibilité 64 bits de leur produit,
        - l'appli n'est pas multi-threadée, et le soit-disant serveur J2EE non plus !

        Ah merde, pour développer vaut mieux savoir développer... Ca fait un choc !

        En programmation j'ai fait mes armes sur un Amstrad CPC, et quand je suis arrivé sur PC je n'arrivais pas à comprendre cette manie du "si c'est lent, on boostera la machine". Maintenant je sais expliquer pourquoi ce raisonnement est débile.
        • [^] # Re: Où est le problème ?

          Posté par  . Évalué à 10.

          En programmation j'ai fait mes armes sur un Amstrad CPC, et quand je suis arrivé sur PC je n'arrivais pas à comprendre cette manie du "si c'est lent, on boostera la machine". Maintenant je sais expliquer pourquoi ce raisonnement est débile.

          Pas si débile que ça si on considère les couts d'optimisation d'une appli ...

          Compte combien ça peut couter de réduire la consommation mémoire/CPU d'une appli et combien ça coute d'ajouter une barrette de RAM dans un serveur (je ne parle pas la des applis embarquées que l'on déploie massivement ou le cout n'est pas le même).

          Parfois c'est le coup de poker, parce qu'on ne sait pas forcément ce que ça va donner mais dans beaucoup de cas ça coute moins cher d'acheter des CPU ou de la RAM plutot que de payer quelqu'un à optimiser une appli.
      • [^] # Re: Où est le problème ?

        Posté par  . Évalué à 3.

        Quand tu te retrouves avec une vieille application monothread

        Heu... c'est un peu n'importe quoi là.
        Les serveurs multiprocesseurs, ça existe depuis des décennies, donc si ton appli est une appli serveur et que l'éditeur n'est pas totalement minable, elle devrait déjà être capable de tirer parti de plusieurs processeurs ou coeurs.
  • # perf

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

    Ce qui est bien je trouve avec le multi-coeur, c'est que la limite de performance se retrouve côté algorithmique, bref, du côté du programmeur : la limite physique devient de plus en plus loin, et les perfs "pures" des langages également.
    Pour s'en convaincre on peut regarder le shootout à cette adresse :
    http://shootout.alioth.debian.org/u64q/benchmark.php?test=al(...)

    Les benchs à base de langages réputés "lents" (parcque à base de VM, les langages interprétés sont encore vraiment à la ramasse) se rapprochent des perfs des langages "rapides" (C/++ & co).
    Ce ne sont plus les perfs du langage en soit qui font la différence, mais les algos mis en oeuvre. Les possibilités du langages restent bien entendus une part non négligeable du bench globale, mais il est intéressant de voir qu'il y a encore du chemin à faire au niveau algorithmique pour obtenir des programmes plus performant avec des multi-cores.
    Et la bonne nouvelle, c'est qu'on ne va pas être obligé de codé en C/C++ pour systématiquement recherché les perfs (troll : et visiblement, pas en Lisaac non plus :-p http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...) )
    • [^] # Re: perf

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

      Merci d'avoir explicité un raisonnement trop implicite dans mon journal :-)
      C'est exactement ça.

      Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads et font souvent de bien meilleur choix que lorsqu'on code à la main.

      Quand on code à la main, on va souvent faire n thread pour n espace d'exécution distinct. Un système automatique va faire n thread pour m espace d'exécution, n < m , sachant que bien évidemment, les espaces d'exécution ne n'exécutent pas tous en même temps.
      La commutation entre thread prend du temps, donc ces langages, qui sont à VM, vont plus vite sur ce genre de code.

      Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.

      (PS : Pour Lisaac, COP, en cours d'implémentation (modulo les cours, les TER à gérer), utilise le même genre de mécanisme que SmallTalk/Haskel/Mozart/Erlang, mais en compilé...)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: perf

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

        Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads et font souvent de bien meilleur choix que lorsqu'on code à la main.
        On est pas tout à fait en phase. Moi ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.

        Java/C# vont devoir se mettre au diapason vite fait, mais je fais confiance à Sun/Microsoft pour prendre les dispositions nécessaires.
        Au contraire, quand tu vois le bench, on s'apercoit que les langages C# ou Java n'ont pas à rougir des perfs des langages bas niveaux, parcque la différence se fait au niveau de la qualité des algos mis en oeuvre par les programmeurs. Mais en soit la base technique des langages C# ou Java est adapté au contexte multi-core.

        Le seul véritable critère important dans le langage, c'est le fait qu'il mette à disposition du programmeur l'accès aux fonctionnalités multi-core natives de l'OS/machine sous-jacent. Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.

        Sinon effectivement, si les langages veulent se différencier dans la course au multi-thread, c'est en proposant des nouvelles constructions pour automatiser la répartition sur plusieurs threads. Bien souvent ca se fait à l'aide de bibliothèques, et non directement dans le langage. (pour parler de mon église, on peut citer TPL http://en.wikipedia.org/wiki/Task_Parallel_Library )
        Dans tous les cas, ces éventuelles "aides" au programmeur ne pourront que s'appuyer sur les compétences du programmeur : si l'algo est pas adapté, il sera pas parallélisable, quelque soit le langage. Bref, le programmeur va de nouveau devoir réfléchir, et ca c'est bien, ca laisse beaucoup de chemin d'évolution possible.
        • [^] # Re: perf

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

          > Ce que je disais au contraire, c'est que l'impact du langage est beaucoup moins important dans un contexte multi-thread : c'est l'algo mis en oeuvre par le programmeur qui fait le gros de la différence.

          Dans le shootout, tous les langages utilisent le même algorithme.
          • [^] # Re: perf

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

            Pas vraiment.
            Y'a des contraintes que l'algo doit respecter, mais il y a pas mal de liberté dans la mise en oeuvre.
            Il suffit de voir que la plupart des programmes ont changés d'implémentation dans leur version "multi-core" pour justement tirer parti des nouvelles machines quad-core utilisées dans le shootout.
        • [^] # Re: perf

          Posté par  . Évalué à 3.

          Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.

          C'est vrai que le GIL - qui dans un contexte mono-coeur était une foutue bonne idée - prend des airs de boulet rouillé dans ces conditions. Ceci dit, le module multiprocessing de Python2.6 (installable dans Python2.5 pour ceux qui veulent) limite sensiblement la casse.
          • [^] # Re: perf

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

            C'est un module de multi-processing, pas de multi-threading, franchement c'est totalement différent.
            Gérer la communication inter-process, c'est non seulement beaucoup moins efficace, mais également beaucoup plus lourd pour le programmeur (faut penser sérialization des données et comm inter-process)
            • [^] # Re: perf

              Posté par  . Évalué à 2.

              Dans tous les cas, il faut prévoir ta communication. Dans les exemples Python que j'ai vu, c'est essentiellement utilisé pour travailler sur des beaux gros vecteurs (allez hop, on coupe la liste en 4 et on file ça aux quatres coeurs, roulez jeunesse). Pas besoin d'avoir un doctorat pour faire ça, il me semble. Et c'est aussi "lourd" en threads qu'en process, pour des données suffisamment grosses.
        • [^] # Re: perf

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

          Dommage, pour une fois que je pensais que tu ne disais pas des conneries, je tenais à le souligner ;-)

          Reprenons, je te parle des benchs sur thread-ring, pas les benchs généraux.

          Analysons http://shootout.alioth.debian.org/u32q/benchmark.php?test=th(...)


          1.0 Haskell GHC #2 8.88
          1.1 Haskell GHC 10.84
          1.8 Mozart/Oz 15.91
          3.3 Erlang HiPE 29.14
          4.0 Smalltalk VisualWorks #2 35.87
          7.8 Scheme PLT 69.19
          14 Scala 122
          16 Pascal Free Pascal 124.66
          17 Lisaac 130.07
          18 C++ GNU g++ #2 148.56

          Nous sommes donc sur un quadricore en 32 bits.

          Le meilleur, Haskell, torche en 9s
          Mozart, SmallTalk, Erlang suivent de pas trop loin.
          J'avoue que je sais pas comment fonction le compilo de sheme.

          Ce qui est intéressant, c'est de voir à combien sont les langages qui utilisent du threading "classique" : Scala, Pascal, Lisaac et C++
          On voit qu'ils sont largement distancés : les temps de commutation entre thread prennent un temps fou.
          122s, c'est plus de 13 fois le score d'Haskell
          Ca fait beaucoup.

          Ce serait très intéressant de savoir combien de thread réel on a dans chaque cas

          Bref, c'est parce ces langages gèrent automatiquement les threads, en n'affectant pas un thread par tâche, mais un thread pour plusieurs tâches (les espaces d'exécutions) qu'ils obtiennent de meilleur perfs.

          Effectivement, ce n'est pas tellement le langage en tant que grammaire/whatever qui compte ici, mais l'implémentation : l'interpréteur, la VM, le compilateur.
          D'avoir la petite primitive dans la grammaire du langage peut aider.

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

          • [^] # Re: perf

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

            Oué bah moi je parlais de tous les autres tests : en gros l'impact du multi-thread sur les algos "classiques" et non sur un test dédié.
          • [^] # Re: perf

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

            C'est marrant de voir qu'Ada95 qui est un des rares langages a avoir la notion de tache normalisé est aussi mauvais... C'est terrible de voir son score.
            • [^] # Re: perf

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              En regardant de plus près le code, tu verras que contrairement à Java par exemple, le programmeur prend le soin d'arrêter tous ses threads proprement, ce qui prend un peu plus de temps qu'un brutal System.exit(0).
              C'est un peu le problème de ce genre de bench, le code n'est pas et ne peut pas toujours être homogène.
          • [^] # Re: perf

            Posté par  . Évalué à 7.

            Tu sais que tu peux faire un modèle actor en Java en zero copy et sans avoir à commuter de thread à chaque fois ?

            Genre http://www.malhar.net/sriram/kilim/ ca tient Erlang en microbench et ca le fracasse en perf sur le code metier. L'optimisation de la VM d'Erlang étant à des années lumières de celle de Java. Le fork/join de la JSR 166y n'obtient pas ses perfs avec une implémentation naïve d'un stagiaire.

            On confond un peu tout et n'importe quoi ici. Un modèle de parallélisme donné peut très souvent être implémenté sur n'importe quelle techno. Donc se servir dudit modèle pour venter les performances d'un langage ou d'une VM est absurde.

            De même beaucoup ici confondent scalabilité et performance. À scalabilité identique un code plus performant terminera sa tâche plus rapidement quelque soit le nombre de ressources à sa disposition.


            Pour le moment tout le monde cherche le bon modèle. Les threads demandent des legendary engineers pour simplement faire du code qui marche [1]. Alors tout le monde propose des nouveaux trucs et un jour peut être on trouvera le truc qui scale, qui a de bonnes perfs, qui est facile à développer et qui est facile à débugger. En cadeau bonus si ca marche en local et en distribué c'est merveilleux. Pour le moment on est dans la phase ou on lance n'importe quoi en l'air et on verra bien ce qui retombe.

            Parallèlement il faut réussir à découper son code métier en morceaux parallèles. C'est difficile, et on oublie pas la loi d'Amdah au passage...


            [1] On peut, entre autre, lancer un grand jeu sur les memory models de Java, C++, .Net ou sur ceux des processeurs si certains veulent dire le contraire.
          • [^] # Re: perf

            Posté par  . Évalué à 8.


            Analysons http://shootout.alioth.debian.org/u32q/benchmark.php?test=th(...)


            1.0 Haskell GHC #2 8.88
            1.1 Haskell GHC 10.84
            1.8 Mozart/Oz 15.91
            3.3 Erlang HiPE 29.14
            4.0 Smalltalk VisualWorks #2 35.87
            7.8 Scheme PLT 69.19
            14 Scala 122
            16 Pascal Free Pascal 124.66
            17 Lisaac 130.07
            18 C++ GNU g++ #2 148.56

            [...]
            Le meilleur, Haskell, torche en 9s

            Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et Scheme.

            Mon petit doit me dit que ce test crée plein de thread qui ne font quasiment rien. Du coup ce test test la rapidité de création de thread, et les implémentations purement userspace gagne haut la main car il n'y a pas tout l'overhead kernel...

            Encore une fois les micro bench sont a prendre avec des pincettes...

            [1]

            x Program & Logs CPU secs Memory KB Size B Elapsed secs ~ CPU Load
            1.0 Haskell GHC #2 8.88 2,872 260 8.89 0% 0% 5% 92%
            1.1 Haskell GHC 10.84 4,944 304 9.93 52% 49% 0% 0%
            1.8 Mozart/Oz 15.91 4,356 340 15.91 0% 0% 0% 100%
            3.3 Erlang HiPE 29.14 6,456 273 29.14 61% 0% 37% 11%
            4.0 Smalltalk VisualWorks #2 35.87 13,088 566 35.86 0% 0% 100% 0%
            7.8 Scheme PLT 69.19 24,412 262 69.19 0% 0% 0% 100%
            • [^] # Re: perf

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

              > Mais il n'utilise qu'un seul core [1], tout comme Mozart, Smalltalk et
              > Scheme.

              A priori, la machine Erlang est capable du multi-coeur depuis quelques années déjà (ele était mono coeur avant).

              > Mon petit doit me dit que ce test crée plein de thread qui ne font
              > quasiment rien. Du coup ce test test la rapidité de création de thread, et
              > les implémentations purement userspace gagne haut la main car il n'y a
              > pas tout l'overhead kernel...

              On sais bien en utilisant la bibliothèque OpenMP qu'on a intérêt à lancer la boucle parallèle la plus large possible sur le code source, c'est à dire le plus tôt possible et de la fermer le plus tard possible. En effet, le lancement des threads est terrible en terme de performance.

              On utilise donc des prama OpenMP de type singleton pour dire que certains passages ne sont pas à faire en parallèle. Cela permet de garder les threads ouvert mais qui ne font rien (sauf un) pour la suite du programme.

              Un petit tour du coté d'OpenMP est aussi très intéressant pour comprendre une partie de la problématique.

              Il est clair que si la conception du langage fait que le compilateur est capable de faire cela a notre place, c'est génial.
              • [^] # Re: perf

                Posté par  . Évalué à 2.

                D'apres le manuel de la vm d'erlang :

                +S Number:

                Sets the number of scheduler threads to use when SMP support has been enabled. Valid range is 1-1024. If the Erlang runtime sys-
                tem is able to determine the number of processor cores available, the default value will equal the this value; otherwise, the
                default value will be one.

                This flag will be ignored if the emulator doesn’t have SMP support enabled (see the -smp flag).


                Et pour avoir un apercu de l'etat de l'implementation smp par la vm, voir le fil de discussion : http://www.erlang.org/pipermail/erlang-questions/2008-Septem(...)
          • [^] # Re: perf

            Posté par  . Évalué à 4.

            Bref, c'est parce ces langages gèrent automatiquement les threads, en n'affectant pas un thread par tâche, mais un thread pour plusieurs tâches (les espaces d'exécutions) qu'ils obtiennent de meilleur perfs.

            Oui, parce que le benchmark est idéal pour favoriser ce genre d'implémentation (créer des tas de petits threads dont chacun ne fait pas grand'chose). C'est loin d'être le cas de toutes les utilisations du multi-threading.
      • [^] # Re: perf

        Posté par  . Évalué à 4.

        Les langages qui s'en sortent bien dans le shootout sont les langages qui automatisent la gestion des threads

        C'est une affirmation totalement infondée et probablement foireuse. Aucun des langages présentés n'est capable de paralléliser automatiquement un algo.
        On voit aussi qu'Erlang n'a pas des performances extraordinaires comparé à, par exemple, OCaml. Pourtant l'implémentation testée (HiPE) est censée produire du code natif, non du bytecode.
    • [^] # Re: perf

      Posté par  . Évalué à 1.

      Ce qui est bien je trouve avec le multi-coeur, c'est que la limite de performance se retrouve côté algorithmique, bref, du côté du programmeur : la limite physique devient de plus en plus loin, et les perfs "pures" des langages également.
      Et pourtant les codec vidéo qui consomme beaucoup (genre h264 sur un flux HD) sont toujours développé en c/c++ avec une parallélisation à la main...
  • # Erlang

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

    Je me suis mis il y a peu sur ce langage et il m'impressionne !

    Les notions de base sont simples, tout est basé sur une notion d'objet immutable et sur de la récursivité. Tout passe par message ou presque. La gestion des erreurs est plutôt par processus indépendant (un calculateur / un superviseur).

    En plus Erlang évite la syntaxe du LISP ou de CAMEL. Cela reste a mon sens bien plus clair pour quelqu'un qui vient du monde C / Fortran.

    Bref, c'est étonnant qu'un langage ou on écrit

    a = 2

    a = 3 -> erreur

    puisse être aussi performant.

    Je vous conseille d'aller voir ce langage, rien que pour la culture générale, c'est passionant.
    • [^] # Re: Erlang

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

      > En plus Erlang évite la syntaxe du LISP
      Pourquoi tu veux éviter la syntaxe du LISP ? C'est un de ses points forts il me semble.
      • [^] # Re: Erlang

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

        Mais aussi un de ses points faibles...

        Le LISP est plus vieux que le Fortran mais sa syntaxe n'a pas réussi à percer pendant tout ce temps malgré son élégance.

        Donc, c'est bien d'avoir un langage fonctionnel comme Erlang avec une autre syntaxe, cela explore d'autre voie de la sociologie humaine.
        • [^] # Re: Erlang

          Posté par  . Évalué à 1.

          Ah je m'insurge. Le LISP c'est un gamin il a carrément 4 ans de moins que le Fortran. Le Fortran date de 1954 et le premier compilateur de 1956, quand a LISP il date de 1958 mais l'article wikipedia ne donne pas la date du premier interpréteur, il semblerait que cela aux alentours de 1960.
      • [^] # Re: Erlang

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

        Il faut aimer les parenthèses, quoi…
        • [^] # Re: Erlang

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

          (oui)
          • [^] # Re: Erlang

            Posté par  . Évalué à 3.

            (répondre
                baud123
                (falloir 
                   indéterminé
                      (aimer 
                        parenthèses
                      )
                   )
                oui
            )
            • [^] # Re: Erlang

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

              On s'écarte du sujet mais bon... Ton code en Lisp s'écrirait plutôt comme ça :
              (répondre baud123 (falloir indéterminé (aimer parenthèses)) oui)
              L'équivalent en C serait :
              répondre(baud123, falloir(indéterminé, aimer (parenthèses)), oui);
              Même nombre de parenthèses, des virgules et points virgules en plus.

              L'équivalent en C, si on l'avait indenté comme ce que tu as fais pour le Lisp, donnerait un truc du genre :
              int *
                aimer_v =
                  aimer (&parenthèses);

              double float falloir_v
                = falloir(indéterminé,
                      aimer_v);

              return
                répondre(baud123,
                    falloir_v, &oui)
                 ;


              Et au passage, le code avec les accents ne compile pas en C mais est tout à fait valide en Lisp vu que le compilo supporte l'UTF-8 : http://www.gnu.org/software/clisp/propaganda.html
              • [^] # Re: Erlang

                Posté par  . Évalué à 2.

                Ou alors, uniquement
                return oui
                appelé au bon moment.

                Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # jusqu'où va aller la multiplication des coeurs

    Posté par  . Évalué à 3.

    Et bien, si je regarde du coté du labo de ma fac (encore une fois), actuellement le projet tsar [1] consiste à créer une architecture massivement multicoeur avec 4096 coeurs en objectif.

    Chaque petit groupe de coeurs est réparti dans un petit cluster disposant en interne d'un mécanisme d'interconnection simple, de ram, etc... mais surtout, pour avoir une scalabilité maximum d'un composant d'interfaçage avec un NoC (Network On Chip)[2] permettant les communications entre les clusters.

    Les avantage d'une telle architecture sont nombreux, ça va de la gestion fine de l'énergie à la tolérance aux fautes en passant par la possibilité de placer chaque objet logiciel avec précision sur les ressources offertes par une telle architecture.

    Bien entendu, une telle architecture demande un peu plus de considérations lors du déploiement d'applications, mais comme le dit un proverbe ... qui peut le plus, peut le moins.

    De plus, le projet à aussi une partie concernant le portage de Linux sur la plateforme et enfin, les modèles virtuels du tout sont libre[3]

    [1] petite présentation : http://www-asim.lip6.fr/team/seminaires/past_seminar/tsar_ip(...)
    [2] network on chip : http://www-asim.lip6.fr/recherche/spin/
    [3] soclib : https://www.soclib.fr
  • # Tu devrais savoir ça

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

    T'es académique, tu devrais savoir qu'il y des gens qui planchent sur ces travaux depuis avant la naissance des créateurs de PHP et RoR.

    Le problème et la solution ne sont pas dans les langages (Erlang, mais avant encore, Multilisp), mais bien dans l'industrie qui n'a rien du tout à foutre des progrès de la recherche. Et c'est pas seulement la faute du département marketing qui serait bien incapable de lire ne serait-ce qu'un abstract d'une publication potable, mais aussi de l'inertie délétère de ces sociétés (entreprises) qui refusent de faire des choix éthiques et moraux, au regard de l'avenir de la société (humaine, cette fois).

    Et c'est aussi, selon moi, la faute de la banalisation de l'informatique. On laisse n'importe qui en faire et obtenir un diplôme, et 5 ans plus tard, le gars est chef de projet. C'est foupoudav là… Des formation courtes de techniciens (qui sont techniques) au longues d'ingénieurs (qui peuvent ensuite apprendre une fois employés), aucune ne donne de vision des problèmes de l'informatique. Et pire, ni les uns ni les autres ne vont en fait approfondir et aller fouiller dans les publications scientifiques, parfois vieilles de 10 ou 20 ans, pour trouver la solution qui existe. A la place, les uns vont demander aux autres de coder de la merde car de toute façon, faudra tout récrire dans 5 ans, alors la bonne solution, hein…


    Bref. Je milite pour la reconnaissance de l'informatique comme d'une science à l'instar des maths, et pour qu'on scinde clairement les domaines et compétences de ce fourre-tout afin qu'on ait enfin des bons choix faits par les bonnes personnes (et que ma grand-mère arrête de me téléphoner quand son ordi tombe en panne)

    --
    pas de troll dans le message ci-dessus. Juste de l'exaspération, et un peu d'extrème (car tout le monde sait que PHP n'a pas été créé. C'est une abomination apparue spontanément. Quel humain voudrait un tel langage ?)
    • [^] # Re: Tu devrais savoir ça

      Posté par  . Évalué à 4.

      Et pire, ni les uns ni les autres ne vont en fait approfondir et aller fouiller dans les publications scientifiques, parfois vieilles de 10 ou 20 ans, pour trouver la solution qui existe.

      Et c'est quoi, alors, la fameuse solution qui existe ?
      (mis à part l'élitisme et la rancoeur, bien sûr :-))
      • [^] # Re: Tu devrais savoir ça

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

        42
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Tu devrais savoir ça

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

          Si la théorie de la concurrence à base de pi-calcul et compagnie fonctionnait, ça se saurait. Moi je milite pour qu'on les brûle et qu'on essaye de faire des langages de programmation utilisables.

          Le succès d'une théorie se mesure à ses applications, c'est-à-dire au fait qu'elle puisse fournir des résultats (théoriques ou pratiques) dans un domaine autre que celui qu'elle définit par elle-même. La théorie de la relativité est un succès, car elle permet de prédir le phénomène astronomique des étoiles cachées qui apparaissent pendant une éclipse : résultat externe, qui n'a pas besoin de la théorie d'Einstein pour être compris, utilisé, observé (même si on ne sait pas l'expliquer autrement). Le pi-calcul, de ce point de vue, c'est un échec.

          <troll />
          • [^] # Re: Tu devrais savoir ça

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

            Juste pour préciser que c'est vraiment un troll : le pi-calcul a effectivement des applications, notamment dans le domaine des protocoles cryptographiques. Mais aucune (à ma connaissance et pour l'instant) dans le domaine de la programmation concurrente pour laquelle il a été créé.
          • [^] # Re: Tu devrais savoir ça

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

            Le pi-calcul, c'est un modèle, pas un langage de prog. Comme le lambda-calcul. Certes, c'est Turing-complet, mais l'intéret est pas de faire des programmes mais de comprendre la sémantiques de langages, pratiques eux, qui reposent sur ces concepts.

            Ensuite de quoi, il y a deux niveaux de théorie: celle qui s'applique à la pratique et qui te semble justifiée, et celle dont les résultats s'appliquent à leur tour à la théorie, que tu appelles (à tort) un échec.

            Je dis à tort, car l'étude du pi-calcul (et des nombreux autres modèles de la concurrence) ont apporté de nombreux résultats intéressants et utilisables dans la vie de tous les jours. Mais, encore une fois, force est de constater qu'ils ne sont pas à la portée de tout le monde. C'est un fait, et c'est comme ça.

            Trod de gens considèrent les résultats en informatique (et en maths) comme "dûs". 1+1=2 "bah oui". Et bien non, pas "bah oui". (et pour la petite note, des algèbres simples comme ça (groupes, idéaux, etc), ca s'utilise en info aussi, sauf qu'on a des programmes entiers à la place des nombres…)
            • [^] # Re: Tu devrais savoir ça

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

              Ensuite de quoi, il y a deux niveaux de théorie: celle qui s'applique à la pratique et qui te semble justifiée, et celle dont les résultats s'appliquent à leur tour à la théorie, que tu appelles (à tort) un échec.

              Non. Je ne considère pas comme un échec la théorie qui s'applique à la théorie. Je considère comme un échec la théorie qui s'applique à elle-même. En effet (et je l'ai dit juste au-dessus, en précisant pourquoi je trollais), le pi-calcul n'est pas un échec, car il s'applique dans d'autres domaines (théoriques) : bio-informatique, cryptographie. Mais en terme de modèle pour les langages de programmations, je ne vois vraiment pas quel crédit donner aux résultats obtenus par le pi-calcul : c'est une bulle inflationniste, qui crée ses concepts pour développer des théorèmes qui vont servir à de nouveaux concepts, sans qu'à aucun moment on ne retouche terre. Le lambda-calcul n'est pas comme ça (il a des interprétations en terme de calculabilité, par exemple, et il a produit des résultats nouveaux et intéressants dans ce domaine).

              Mais si tu as un résultat issu du pi-calcul qui parle d'autre chose que du pi-calcul lui-même [1], je serais très intéressé et reverrais sûrement ma position.

              [1] (et des protocoles crypto, on est d'accord dessus que c'est un succès du pi-calcul)
              • [^] # Re: Tu devrais savoir ça

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

                J'avais pas remarqué que tu t'étais répondu.
                Bon, la théorie qui s'applique à elle même, c'est une démarche co-inductive, mais pas forcément inutile.
                Si on omet le spi-calcul dont tu parles (pour les protocoles cryptographiques), sache que les techniques de preuves d'equivalence dans le pi-calcul (et CCS avant), les bisimulations (quis sont construites par co-induction justement), sont utilisées aussi pour prouver l'intégrité de programmes au sens cryptographique, mais aussi l'equivalence de deux programmes (l'un optimisé l'autre non), ou encore te garantir qu'un programme marchera sur ton linux comme sur mon BSD (par des preuves de congruence). Et ces techniques de preuves découvertes grace aux "calculs de processus" s'appliquent aussi au lambda-calcul et à des languages de plus haut-niveau (genre haskell).

                Je crois vraiment qu'on retouche terre. Pas tout le temps, certes. Puis tous les chercheurs ne sont pas d'excellents génies, donc t'as des publis moins bien que d'autres (et des gars qui *veulent* prouver leur conjecture dont on sait qu'elle ne mène à rien).

                Pour moi, le PI calcul (avec ses variantes) est un modèle, et il y a encore pas mal à y étudier. Il y a beaucoup de demande ces temps-ci, car justement, ca modélise vachement bien des trucs en biologie et pas mal de bio-informaticiens ou simple biologistes s'y mettent. J'ai pas plus de détails car c'est pas mon trip…
                Enfin, une invitation récente que j'ai reçue par une ML à laquelle je suis abonné:


                ** CMSB 2009
                ** The 7th Conference on Computational Methods in Systems Biology
                ** http://cmsb09.cs.unibo.it/

                The CMSB (Computational Methods in Systems Biology) conference series was established in 2003 to help catalyze the convergence of modellers, physicists, mathematicians, and theoretical computer scientists (from fields such as language design, concurrency theory, program verification) with molecular biologists, physicians and neuroscientists interested in a systems-level understanding of cellular physiology and pathology.

                J'étais loin de penser à ça quand j'étudiais le PI-calcul en classe…
          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Tu devrais savoir ça

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

              En réalité, Erlang fait à la fois moins et plus que le pi-calcul. Moins, parce qu'il ne propose pas de notion de canal arbitraire (il y a un seul canal par processus). Plus, parce qu'il est évidemment de bien plus haut niveau.

              Erlang peut être formalisé en termes de pi-calcul [1] mais il n'a pas été inventé à partir du pi-calcul. Les liens entre les deux ont été discutés sur la liste de diffusion [2] où il est apparu qu'il est particulièrement bon pour... implémenter des interpréteurs du pi-calcul [3] !

              Quoiqu'il en soit, Erlang doit beaucoup plus à la théorie des files d'attente qu'au pi-calcul. A commencer par son nom [4]. Il est difficile de dire exactement quelles sont les influences ayant présidé à son élaboration, naturellement, mais le contexte dans lequel il a été créé (firme Ericson) autant que l'origine de ses concepteurs et leurs motivations (obtenir un langage qui capture bien les notions usuelles en télécommunications et qui soit distribué pour résister aux pannes) génèrent, à mon sens, une suspicion importante de lecture rétrospective quand on affirme qu' « Erlang est basé sur le pi-calcul, et très fortement ».

              Par contre, pour les applications réelles du pi-calcul, je trouve la page wikipedia [5] est assez complète. Mais il ne faut pas se voiler la face : d'occam-π à jocaml, les langages de programmation qui ont essayé d'utiliser le pi-calcul (ou une de ses variantes) sont des échecs. C'est dommage, mais c'est comme ça : ça ne marche pas (ou alors on n'a pas trouvé la bonne syntaxe/approche pour que ça soit utilisable sur des projets sérieux).

              Je crois beaucoup plus à la programmation réactive fonctionnelle. L'avenir nous dira bien ce qu'il en est.

              [1] http://portal.acm.org/citation.cfm?id=1088375
              [2] http://www.erlang.org/ml-archive/erlang-questions/200310/msg(...)
              [3] http://erlang.org/pipermail/erlang-questions/2003-November/0(...)
              [4] http://en.wikipedia.org/wiki/Agner_Krarup_Erlang
              [5] http://en.wikipedia.org/wiki/Pi-calculus#Applications
    • [^] # Re: Tu devrais savoir ça

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

      Alors, justement, je suis pas académique, je bosse dans une grosse SSII.
      Et effectivement, on en revient à la vieille opposition entre chercheurs et ingénieurs en France.
      Les ingénieurs pensent que la théorie ça sert à rien, et que les gens formés à la fac sont une bande de théorien (= doux rêveur) incapable d'implémenter une lib ftp en java, et les théorciens pensent que les ingénieurs sont des bidouilleurs de code à pein capable d'implémenter un intranet en java.

      Le problème, c'est que c'est pas tout à fait faux...

      Autour de moi, j'ai des techniciens hyper forts... mais incapable de faire la différence entre un compilateur et interpréteur.

      J'ai réalisé un outil d'automatisation de code ces derniers temps sur lequel j'ai été pas mal force de proposition, et j'ai été assez effaré de constater que pas mal de gens avaient du mal à concevoir que parser un source, analyser son arbre abstrait et générer quelque chose avec, c'était possible...
      Des gens très bien, très compétent, parfaitement taillés pour les besoins d'une SSII, mais non, euhhh, c'est quoi un compilateur ?

      Effectivement, ça serait pas mal que les écoles d'ingés reviennent un peu plus dans le giron de l'université, et que les universités travaillent un peu plus à ajouter ce qui manque dans la formation pour adapter les étudiants à la gestion de projet, calculs de couts, etc...

      De savoir lire les abstract de paper, je ne suis pas sûr que ça soit directement utile, et c'est peut être trop leur demander, mais déjà, s'ils pouvaient avoir les connaissances théoriques de base qu'un Master 1 possède, je pense que ça serait déjà énorme, on perdrait beaucoup moins de temps.

      Mais il y a un tel mépris de la théorie, par des gens qui pensent que java est formidable, les framework le sont encore plus, et qui s'extasient des heures durant à faire des usines d'usines d'usines d'objets... que c'est mal baré.

      Tant pis, c'est la productivité qui en pâtit...

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Tu devrais savoir ça

        Posté par  . Évalué à 2.

        Des gens très bien, très compétent, parfaitement taillés pour les besoins d'une SSII, mais non, euhhh, c'est quoi un compilateur ?

        En SSII tu trouves un peu tu trouves un peu les déchets de l'informatique. Des gens qui n'ont pour la plupart pas de cursus d'informaticien, qui sont là pour bouffer sans aucune passion du métier, et qui enchainent les missions pourries chez des grands comptes qui ne s'y connaissent pas mieux...


        Tant pis, c'est la productivité qui en pâtit...

        Non c'est le client qui paye :)
        • [^] # Re: Tu devrais savoir ça

          Posté par  . Évalué à 6.


          En SSII tu trouves un peu tu trouves un peu les déchets de l'informatique. Des gens qui n'ont pour la plupart pas de cursus d'informaticien, qui sont là pour bouffer sans aucune passion du métier, et qui enchainent les missions pourries chez des grands comptes qui ne s'y connaissent pas mieux...

          Notre premier de promo universitaire est partit en SSI au lieu de faire une thèse...
          Néanmoins, je connais beaucoup de gens qui n'avaient aucune formation informatique spécifique et qui ont atterri chez A...S.
          De même, quand je vois que certains recruteurs n'hésitent pas à m'envoyer des offres, ou même me contacter par téléphone, parce qu'ils ont vu mon profil qqpart sur internet et qu'ils ne comprennent pas la moitié des techs citées ou vont jusque proposer des postes admin windows à des ingé unix ! (c'est "admin" qui les intéresse, pas l'expertise dans la tech!)
          Du grand n'importe quoi, oui, je confirme.
      • [^] # Re: Tu devrais savoir ça

        Posté par  . Évalué à 2.

        Les ingénieurs pensent que la théorie ça sert à rien, et que les gens formés à la fac sont une bande de théorien (= doux rêveur) incapable d'implémenter une lib ftp en java, et les théorciens pensent que les ingénieurs sont des bidouilleurs de code à pein capable d'implémenter un intranet en java.

        Tu connais beaucoup de théoricien qui font des intranets en Java? Alors que des ingénieurs qui savent faire une lib FTP en Java, ça doit encore pouvoir se trouver assez facilement.

        Bon après, si tu tiens absolument à mettre du Java dans la négociation...
    • [^] # Re: Tu devrais savoir ça

      Posté par  . Évalué à 8.

      car tout le monde sait que PHP n'a pas été créé. C'est une abomination apparue spontanément. Quel humain voudrait un tel langage ?

      Avec un peu de "chance", il a même été créé par Java (lequel a eu une relation incestueuse avec Windev quand il était jeune). Car aucun de ceux-là n'a pu être créé par un humain non plus.

Suivre le flux des commentaires

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