Fermer

  • AgoraVox sur Twitter
  • RSS
  • Agoravox TV
  • Agoravox Mobile

Accueil du site > Actualités > Technologies > Du PC à la Voie Lactée : les performances de nos ordinateurs

Du PC à la Voie Lactée : les performances de nos ordinateurs

L’augmentation vertigineuse des performances de nos ordinateurs est difficile à concevoir, à visualiser.
Pourtant, elle est réelle, et bien au-delà de ce qu’on pourrait imaginer.
En effet, la lenteur et la lourdeur des logiciels d’aujourd’hui, s’aggravant constamment, fait qu’il est souvent difficile de s’en apercevoir…

La Galaxie dans un PC

JPEG - 378.2 ko
La Voie Lactée
Cliquer pour agrandir

Prenons un exemple concret : notre galaxie, la Voie Lactée.
La Voie Lactée fait 80.000 Années-lumière de diamètre, soit environ 800.000.000.000.000.000 km, ou 800 millions de milliards de kilomètres, et elle comporte environ 300 milliards d’étoiles.
Ce sont des valeurs… astronomiques.

Supposons que l’on veuille stocker la position de toutes les étoiles de la Voie Lactée (par rapport au centre), ainsi que le type spectral (la couleur) et la classe de luminosité (la taille, de hypergéante à naine blanche), quel volume cela prendra-t-il ?

En informatique, on utilise habituellement le type "Double" pour les nombres réels (non entiers). Le "Double", occupant 64 bits (8 octets) de mémoire, offre 16 chiffres significatifs.
Avec cette précision (de -9.000.000.000.000.000 à +9.000.000.000.000.000), on peut mémoriser des distances à 100 km près dans toute la galaxie.
Sachant qu'une étoile comme le Soleil fait 1.4 millions de km de diamètre, la précision de 100 km est largement suffisante.
Les types spectral et classe de luminosité tiennent sur un octet chacun (255 valeurs possibles par octet).

Chaque étoile aura donc 3 coordonnées (x, y, z) de type Double de 8 octets, et 2 valeurs (type et luminosité) de 1 octet, soit au total 3 * 8 + 2 * 1 = 26 octets par étoile.
A raison de 300.000.000.000 d'étoiles, le volume de données sera de
26 * 300.000.000.000
= 7.800.000.000.000 octets
= 7.617.187.500 Ko
= 7.438.660 Mo
= 7.265 Go
= 7 To.

Avec 4 disques Western Digital de 2 To à 130€, vous pouvez donc stocker la position, la couleur et la taille de toutes les étoiles de la galaxie.
Et votre PC gérera sans mal ces 4 disques.

Tout votre ADN dans votre PC

Prenons un autre exemple amusant.
En 1990 sortait le livre "Jurassic Park". Il y est question de recréer les dinosaures à partir de leur ADN, en utilisant massivement des ordinateurs pour aider à la reconstitution des brins d'ADN abimés par le temps.

La chaîne d'ADN, présente dans les cellules vivantes, est un programme permettant de recréer à l'identique la créature qui les possède, et est composée d'une suite de 4 bases : A (adénine), T (thymine), C (cytosine) et G (guanine).
C'est comparable, en informatique, à l'encodage sur 2 bases (0 et 1).

Selon les êtres vivants cette chaîne est de longueur variable, mais, pour les grands vertébrés, elle tourne autour de 3.000.000.000 de bases (pour l'homme, comme, sûrement, pour les dinosaures).


En 1989, époque de Jurassic Park, c'était un volume incroyablement grand à gérer : il faut plusieurs superordinateur Cray X-MP (dans le livre) pour traiter une telle masse de données.

JPEG - 183.3 ko
Cray X-MP
Cliquer pour agrandir

Le Cray X-MP/416, sorti en 1984, est le summum de la série, et le plus rapide et plus puissant ordinateur du monde à l'époque.
Il possède 4 processeurs à 117 Mhz, et une mémoire centrale de 128 Mo. On peut lui adjoindre des SSD, sorte de grandes armoires de mémoire additionnelle de 1 Go chacune, et il offre une puissance de calcul de 800 Mflops (millions d'opérations par seconde).
Ce jouet coûte, à l'époque, 15 millions de dollars.

Brochure technique sur le Cray X-MP.
Jurassic Park possède donc 3 superordinateur Cray X-MP/416 dotés chacun d'un SSD de 1 Go, soit 45 millions de dollars.

En enregistrant de façon un peu simpliste la chaîne d'ADN dans un fichier, en réservant un octet par base (c'est bien plus qu'il ne faut, mais ça facilite la lecture du fichier), la chaîne complète d'ADN pèsera 3 Go.

C'est-à-dire que la totalité de la chaîne d'ADN d'une de nos, de vos cellules, tient directement dans la mémoire vive du PC qui vous sert à lire cet article.
C'est-à-dire qu'on peut mettre deux programmes génétiques complets sur un DVD.
Et sur votre disque dur, vous pourrez stocker entre 10 et 100 fois votre génome. Rien que ça.

En 2011, vous avez entre les mains la puissance de 3 superordinateurs Cray de 1989 à 15 millions de dollars.

La lenteur croissante des applications.

Malgré les performances inimaginables de nos PC, on remarquera sans mal la lenteur extrême de nombreux programmes, particulièrement les suites bureautique.
Il est intéressant à ce sujet de faire le parallèle avec Word 5.1 sur Macintosh Plus.

PNG - 5.5 ko
JPEG - 59.1 ko

Soyons clairs : 90% des fonctionnalités de Word 2003 existaient déjà dans Word 5.1, y compris l'éditeur de graphiques, l'éditeur d'images, l'éditeur de tableaux, les correcteurs grammaticaux et orthographiques, le catalogue des synonymes, les styles, la possibilité de mise en page, etc.

JPEG - 39.5 ko
Macintosh Plus
Cliquer pour agrandir

Le Macintosh Plus est sorti en 1986, avec un processeur Motorola MC68000 à 8Mhz et 1 Mo de mémoire vive, extensible à 4 Mo.
Word 5.1, sorti en 1992, n'est pas très véloce sur Mac Plus, mais il est parfaitement utilisable, et l'on profite de toute la puissance de ses outils sans problèmes.

20 ans plus tard, sur des machines au moins 400 fois plus rapides que le Mac Plus, Word 2010 n'est pas plus rapide ou réactif, en n'offrant que très peu de fonctions supplémentaires (et essentiellement des fonctions inutiles).

Tout le monde connait la "loi de Moore", inventée par Gordon Moore, cofondateur d'Intel, en 1975  :
« Le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans. »
Il ne s'agit pas d'une étude sérieuse, statistique, mais d'une prédiction empirique, qui s'est révélé jusqu'à présent exacte.

La Loi de Wirth

Et bien, la loi de Moore a son corollaire, concernant la lenteur permanente des programmes !
Cette autre loi à été formalisée par Niklaus Wirth en 1995, et nommée donc "Loi de Wirth" :
 « Le logiciel ralentit plus vite que le matériel accélère. »

Le matériel a beau doubler en performance tous les 24 mois, les programmes n'accélèrent pas pour autant : au contraire, ils deviennent plus gros et plus lent, les développeurs justifiant cette lenteur excessive comme compensée par la loi de Moore !

Il faut dire qu'un grand nombre de choix très malheureux a été fait ces 20 dernières années dans le domaine de la programmation, allié à une situation de manque de développeurs.

D'un côté, l'informatique a envahi le quotidien, nécessitant une armée inexistante de développeurs : actuellement, en France, par exemple, en pleine crise, l'informatique est le seul domaine où il y a plus de postes disponibles que de candidats (offrant alors des situations particulièrement favorables pour les développeurs).
La conséquence de cette situation, c'est que pour pallier le manque de développeur, on est envahi de développeurs médiocres ou franchement mauvais, incapable de coder correctement quelques lignes (et l'on est entouré de développeurs capables de noircir 50 lignes de code pour faire une action réalisable en 5 lignes).

D'un autre côté, dans l'idée de vouloir toujours tout révolutionner, de faire différent des "vieux", et à un rythme effréné, on a cédé à de nombreuses technologies spécialement mauvaises, comme les langages interprétés (Java tout particulièrement, .net, Javascript, Python, etc), les langages massivement objets, menant à des pertes de performances souvent sensibles, et à une augmentation de la mémoire utilisée sans rapport avec la mémoire vraiment nécessaire.

Si l'on codait aujourd'hui les applications, en C ou en Pascal, comme on le faisait dans les années 80, nos ordinateurs donneraient une impression de vitesse et de fluidité dont on n'a pas idée.


Moyenne des avis sur cet article :  4.46/5   (67 votes)




Réagissez à l'article

120 réactions à cet article    


  • Asp Explorer Asp Explorer 20 décembre 2011 18:24

    Tout à fait exact. Le fait est aussi que les besoins ont changé. Certes la bureautique est la même qu’en 1990, mais allez donc coder un lecteur vidéo en assembleur...


    • spartacus1 spartacus1 20 décembre 2011 18:28

      Je ne peux qu’abonder dans le sens de votre article.

      En 1965, j’ai écrit, dans le cadre de ma thèse, en FORTRAN, une petite chaîne de programmes qui calculait, à partir d’observations terrestres, la trajectoire des satellites artificiels. Le but étant de mettre en évidence les irrégularités de trajectoire, c’est à dire, in fino, la forme et/ou* la masse spécifique en chaque point de l’écorce terrestre.
      Il y avait une dizaine de programmes tenant dans 20 Koctets (en fait, à l’époque, il s’agissait de mots de 4 bits). Le toute écrit. par une seule personne, en moins d’un mois.
      J’imagine que maintenant, plusieurs mois et des Mo seraient nécessaire à des programmeurs actuels.

      En fait, en plus de 40 ans, je n’ai pas vu de progrès vraiment significatifs, de réels changement de paradigme, en programmation, si, peut-être, des avancées dans le domaine de la programmation parallèle.
      On ne fait que rajouter des gadgets, on pare de mots ronflants (raffinement graduel, objets, réutilisation, fonctionnel, ...) des pratiques que les bons programmeurs ont d’instinct.
      Je suis effaré de voir que chaque jour on redécouvre des choses qui existent de puis longtemps.
      Par exemple, le « cloud computing » s’appelait « time-sharing » il y a une trentaine d’années.
      Simplement, les progrès du matériel, permettent de mettre effectivement en œuvre des techniques existantes, mais il n’y a pas vraiment de progrès conceptuels.

      Lorsque je regarde certains code source, je partage totalement votre avis quant à la médiocrité voire la nullité de certains développeurs. 

      * Le et/ou demanderait trop de développements pour être analysé ici et serait, de toute façon, HS.


      • Marc Bruxman 20 décembre 2011 19:30


        "On ne fait que rajouter des gadgets, on pare de mots ronflants (raffinement graduel, objets, réutilisation, fonctionnel, ...) des pratiques que les bons programmeurs ont d’instinct.« 

        Le progrès est justement d’avoir pris une technique de développement existante qui était fait avec les petites mains du développeur tant bien que mal et de l’avoir inclus dans un langage de sorte que leur mise en oeuvre devient facile.

        Oui on peut faire de l’objet avec un langage impératif. Avec un bon usage des pointeurs sur fonction, tu peux même simuler de l’héritage. Mais quel inconfort d’utilisation ! Personne ou presque n’utiliserait l’objet s’il fallait encore faire comme cela.

        De même tu peux faire des fonctions d’ordre supérieur en C plutôt que d’utiliser un langage fonctionnel, mais si tu as besoin de fonctions d’ordre supérieur, il sera surement plus agréable d’écrire le code en ML.

        Et quid du typage ? Trouves tu que le C et le Pascal ont une sécurité de typage satisfaisante ? (Même en compilant en -Wall sur gcc ?). En théorie bien sur, un bon développeur ne fera jamais d’erreur de typage. Sauf que tout homme est étourdi. Quand tu as des crash sur un projet de 6 millions de ligne de code qui occasionnent des indisponibilités tout ca parce qu’un mec a casté un pointeur en integer (vécu), crois moi tu regrettes que le langage n’ai pas empéché cette action et bloqué la compilation. Après oui le développeur n’avait pas à caster en int sont pointeur mais c’est un autre problème. L’empécher de faire cette connerie est déja un progrès.

        Pour la gestion mémoire aussi, tu aimes les buffers overflows avec le C ? Bien sur, tu es un bon développeur et n’en fait jamais sans doute ? Ou plutôt tu es comme tout le monde et tu as passé parfois un peu de temps avec un debugger mémoire à trouver que tu avais écrasés certaines structures de données utilisées par malloc() en interne. Surement que l’on peut s’e satisfaire, mais l’empécher est un progrès.

         »Par exemple, le « cloud computing » s’appelait « time-sharing » il y a une trentaine d’années.
        Simplement, les progrès du matériel, permettent de mettre effectivement en œuvre des techniques existantes, mais il n’y a pas vraiment de progrès conceptuels.« 

        Si le cloud »fonctionne« et si des plateformes PaaS voient effectivement le jour et sont satisfaisante cela sera déja un progrès. Rien que le fait de fonctionner avec un cluster de commodity servers est un progrès. Et nécéssite un travail important pour que cela marche à la fin.

        Quand aux progrès conceptuels, allez voir dans les labos. Allez voir par exemple ce qu’est le model checking. Mais il faudra encore beaucoup de temps avant que tout cela ne soit intégré à nos outils. De même que des choses comme le garbage collector ont mis du temps à être intégré à nos environnements (de maniére efficace).

         »Lorsque je regarde certains code source, je partage totalement votre avis quant à la médiocrité voire la nullité de certains développeurs. "

        Ah ca oui par contre. Et j’ajouterai que l’utilisation de la syntaxe du C dans d’autres langages est un désastre. Combien de gens formés correctement au C codent de la même façon en Java et ont des perfs de merde ? Dans ce cas le langage n’y est pour rien. Si Java avait une autre syntaxe au moins les gens seraient conscient du fait qu’ils ne savent pas coder dans ce langage et peut être apprendraient il à le faire (ou à utiliser un autre langage).


      • L'enfoiré L’enfoiré 20 décembre 2011 19:02

        Le matériel informatique, c’est comme pour la HiFi, la vitesse est toujours dépendante du maillon le plus faible.
        Je ne vais pas vous faire un cours d’informatique.
        Je me souviens d’une phrase caractéristique et bien vrai :
        « even if you have a 1000 MHz, 2000 MHz, or 10.000 MHz, you are still waiting at the same time ».
        Signed by an old informtician smiley


        • Abou Antoun Abou Antoun 21 décembre 2011 00:54

          Le matériel informatique, c’est comme pour la HiFi, la vitesse est toujours dépendante du maillon le plus faible.
          Cela dépend de la nature de l’application. Une application de calcul scientifique lourde va consommer de la RAM, un SGBD va fortement dépendre de la mémoire de masse.
          Si donc vous écrivez essentiellement des applis de gestion de bases de données mieux vaut les faire tourner sur une machine avec un bon disque quelque soit le processeur. Si vous vous spécialisez dans le calcul scientifique prévoyez beaucoup de mémoire vive un ou plusieurs bons procs et utilisez le parallélisme autant que faire se peut.


        • L'enfoiré L’enfoiré 21 décembre 2011 08:48

          Abou,

          « Cela dépend de la nature de l’application. »

          Exact. Alors, analysons ce qui est utilisé le plus dans l’entreprise. A mon avis, le domaine scientifique est assez marginal. L’applicatif qui tourne autour de la gestion de société est encore le plus utilisé. Comment se pratique-t-il ?
          En réseau, reliés à des grosses machines à distance. Quel est le maillon faible (ou qui peut l’être) ? Les moyens de la communication, le débit, Intranet et Internet.
          Les vieux moyens d’input et output passent plus par là. On imprime moins.
          Des extractions de données se passent ensuite et sont envoyés vers des solutions externes utilisant les outils Offices.
          La décentralisation se produit ainsi.


        • L'enfoiré L’enfoiré 21 décembre 2011 10:27

          Notre journal L’Echo, a un article du jour sur le sujet.
          Titre « L’Europe va tester la réalité du haut débit ».
          C’est pas gagné d’avance du côté des communications. smiley


        • L'enfoiré L’enfoiré 21 décembre 2011 16:07

          au sujet de l’article de l’Echo, il s’agit d’un contrat de 2,6 millions d’euros avec la société SamKnows qui est chargé par l’Europe d’analyser les bandes passantes fournies par les fournisseurs d’accès en Europe.
          En jeu, 50 milliards de développement en infrastructure digitale.
           


        • Marc Bruxman 20 décembre 2011 19:13

          Du bon et du mauvais dans cet article.

          Je suis d’accord avec vous sur un point : Le manque de développeurs qualifiés nuit grandement à l’industrie informatique.

          Mais ceci me donne envie de hurler :
          "Si l’on codait aujourd’hui les applications, en C ou en Pascal, comme on le faisait dans les années 80, nos ordinateurs donneraient une impression de vitesse et de fluidité dont on n’a pas idée.« 

          Et bien non. Pourquoi ne codez vous plus en C ou Pascal ? Parce que les applications se sont complexifiées De l’interface graphique kikoolol (plus en noir et blanc) à des fonctionalités nouvelles comme la correction ortographique qui se fait au fur et à mesure que vous tapez, le ’smart art’ pour faire à la volée des dessins sans se prendre la tête, le lissage des polices, et ne l’oublions pas l’augmentation de la résolution de votre écran etc, etc, ...

          Or, il y a une limite à ce que le cerveau humain peut encaisser en terme de complexité. Il y a donc deux solutions, soit se limiter en termes fonctionnels, soit faire évoluer nos langages et outils pour pouvoir travailler plus efficacement. L’évolution des langages correspond à ce besoin : Modulo une perte en performance (qui est réelle mais peut être maitrisée si le développeur est compétent), vous diminuez la complexité du code et donc vous pouvez écrire un code plus gros sans bugs.

          Lorsque les premiers gestionnaires de mémoire virtuelle sont apparus (il y a fort longtemps), c’était un jouet couteux et certains informaticiens trouvaient que c’était inutile et qu’un vrai développeur pouvait tout à fait s’en passer. Or, aucun système multi-tache ne serait fiable sans cette évolution (qui reste couteuse). La même chose pour le C qui fut un truc pour les »tafioles" car les vrais hommes codaient en assembleur ;) Mais essayez d’écrire Microsoft Word en 100% Assembleur et vous allez voir le résultat.

          Après les jérémiades sur les performances de l’objet et même de langages décriées pour leur perf comme le java sont une histoire de mauvais développeurs qui éssaient de coder en Java comme ils codent en C ce qui donne des performances merdiques. Un bon développeur java (c’est rare et cher) approche les perfos d’un bon développeur C++ à quelques pourcent près. Dans certains cas, il peut même les dépasser à cause des optimisations permises par le JIT (qu’un compilateur statique ne peut pas réaliser). Maintenant comme peu de devs ont appris à faire de l’orienté objet correct, forcément le résultat est merdique. Mais la solution n’est pas de ne pas utiliser l’objet, juste de former les devs aux technos qu’ils utilisent.

          Beaucoup d’informaticiens conspuent ainsi les langages plus évolués que le C, ils ont tort. Non seulement ces langages sont rapides si on prend le temps de bien les utiliser (mais la le fait que beaucoup reprennent la syntaxe du C est délétaire car les gens croient qu’ils vont pouvoir coder pareil en C qu’en Java ou PHP), mais en plus c’est le fait d’avoir accès à un niveau d’abstraction supérieur qui fait la différence car cela vous permet d’écrire vite et bien des applis complexes. Les langages à objets qui supportent l’introspection par exemple permettent d’écrire très rapidements des codes élégants, et simple à maintenir. Et même si on y perd un peu en performance, dans la plupart des projets, le gain dépasse largement le coût : Des dizaines de jours hommes économisés d’un coté contre 300$ de hardware en plus ? Et vous choisissez quoi ?

          Enfin avez vous tant besoin de vitesse lorsque vous utilisez un ordinateur ? Dans la plupart des cas votre CPU ne fout rien. Dans les quelques pouillémes de cas ou vous avez besoin de perfo, rien ne vous empéche d’écrire en C la routine importante (voir de retoucher le code ASM produit si vous savez comment marche le pipeline), mais pour du boulot général, cela n’a aucun intérêt.


          • L'enfoiré L’enfoiré 20 décembre 2011 19:22

            Marc,
             Exact.
             Si je te disais ce que j’ai réalisé avec de petits crincrins de 4K qui devenait une merveille quand on passait à 8K.
             Moi, ce n’était pas en C, c’était en assembler.
             Là, on divisait les bits en deux.
             Tu as lu ma « Grande gaufre » ?
             Ça c’est de l’histoire vue de l’intérieur... smiley


          • L'enfoiré L’enfoiré 20 décembre 2011 19:24

            Ce qui me manque aujourd’hui, ce sont les dumps de mémoire quand cela se plantait.


          • L'enfoiré L’enfoiré 20 décembre 2011 19:29

            Qu’est-ce qui a vraiment changé ?
            Le « user friendlyness » pour que les non-informaticiens s’y intéressent.
            Il fallait toucher plus de monde. Le marketing a suivi le mouvement.
            Alors, il y a eu eu les belles images, le son, les vidéos sur les écrans ...
            Le plug and play....
            Il faut bien que jeunesse se passe... smiley
             


          • Marc Bruxman 20 décembre 2011 19:35

            @L’Enfoiré

            Jamais codé en assembleur pour le boulot, mais un peu à titre perso pour le fun et j’adorais cela ! Lol ca donne envie de se refaire un bon core war ;)


          • Mor Aucon Mor Aucon 20 décembre 2011 20:03

            Excellent votre commentaire. J’aurais dû me douter que vous étiez l’un des derniers maso d’assembleur qui restent.


          • L'enfoiré L’enfoiré 20 décembre 2011 20:07

            Cela commençait par l’assignation de la mémoire en ’tranches" par les registres :
            BALR *,3
            USING 4,5,6

            Toutes les instructions qui suivait en utilisant cet adressage :

            Exemple un MOVE :
            MVC 0(4,5),2(6)

            Traduction transfert du 4 caractères de l’adresse +2 du registre 6 vers l’adresse du registre 5 
            Amusant, non ?
             


          • L'enfoiré L’enfoiré 20 décembre 2011 20:16

            Si intéressé par l’histoire


          • Abou Antoun Abou Antoun 21 décembre 2011 00:46

            Excellente mise au point de quelqu’un qui connait le sujet. J’en rajoute une couche un peu plus loin.


          • L'enfoiré L’enfoiré 21 décembre 2011 12:29

            Yoann,

            « Le manque de développeurs qualifiés nuit grandement à l’industrie informatique. C’est l’industrie informatique qui impose la médiocrité des développeurs. Et pas le contraire. »

            Oui. Absolument. Alors, il faut en rechercher l’origine. Elle vient de cette fuite en avant qui veut que tout le monde est obligé de courir pour implémenter la nouvelle version d’un logiciel. Alors, il faut passer des heures à suivre des cours. La version précédente n’est pas encore testée et implémentée que le marketing impose d’étudier la suivante.

            Exact. donc ? Plus le temps de consolider les connaissances. Obligé d’aller de l’avant. Les anciens softs suivent le même mouvement et restent aussi à la traine pour ajouter la dernière nouveauté inventée chez un concurrent ou au niveau hardware. Les mises à jours des softs en sont une preuve. Elles sont même automatiques/

            "Et bien non !! Les applications sont les mêmes depuis 20 ans. Et on oblige à re-coder les mêmes applications dans de nouveau langage plus lourd. C’est que démontre l’auteur avec le parallèle des logiciel « word ».

            YES. Ok pour le reste.


          • Bovinus Bovinus 22 décembre 2011 00:01

            Je soutiens la position de Yoann. L’informatique, j’ai laissé tomber au début des années 2000, et suis passé à un domaine totalement différent. Cela dit, j’ai pas oublié mes bases, et d’un point de vue strictement économique, les deux points-clefs de la controverse sont ceux-là :

            Marc Bruxman :
            Des dizaines de jours hommes économisés d’un coté contre 300$ de hardware en plus ? Et vous choisissez quoi ?

            À quoi Yoann répond ceci :
            Vous faites l’apologie de la médiocrité...
            Prenez une cuillère en plastique et une cuillère en métal. L’une des deux fera bien mieux sont boulots pendant plus longtemps et avec un meilleur rendement pour l’acheteur.

            La question ici est celle de l’arbitrage entre divers facteurs, tels que la consommation de ressources, l’investissement dans la production de hardware plutôt que dans le développement, la valeur de l’argent par rapport aux ressources et aux « jours-hommes », et l’arbitrage entre capital humain et capital industriel. Ces questions touchent aux choix socio-économiques fondamentaux de la société où tout ceci se déroule. Les adeptes de la solution « hardware » estiment qu’avec un simple upgrade hardware relativement bon marché, l’entreprise économise des capitaux sur les charges personnel, ce qui la rend plus efficace et se traduit par un meilleur rendement du capital investi pour les investisseurs. C’est pas faux, et c’est en effet la meilleure solution dans le cadre de notre système économique actuel.

            Maintenant, examinons les conséquences concrètes d’une telle situation. Plutôt que d’employer un développeur de plus, nous importons du matos américain (les CPUs relèvent du duopole Intel-AMD), ce qui provoque une fuite de capitaux de l’économie locale vers l’économie américaine correspondant grosso-modo à la somme que nous dépensons en hardware. De plus, la production de CPU étant fortement automatisée, l’argent de ces CPU s’en va dans la poche du très riche capitaliste propriétaire de la machine qui fabrique ces CPU, et qui, de toute façon la fait fonctionner dans quelque pays misérable du Tiers-Monde pour un bol de riz les 10 Quadcores. Quant au capitaliste, l’argent sera au choix, réinvesti dans le développement et le marketing du prochain CPU encore plus puissant que le précédent, placé chez un banquier ou bien en bourse, c’est à dire, détourné vers l’économie dite « virtuelle ». Enfin, comme ces CPU nous dispensent d’embaucher un codeur de plus, on fabrique un chômeur supplémentaire, ce qui signifie que celui-ci a été formé en vain. On est dans un schéma de rentabilisation maximale du capital par externalisation de coûts environnementaux (ressources inutilement gâchées pour produire les CPU) et sociaux (délocalisations, chômage, gaspillage de capital humain).

            Dans ce schéma monstrueux, où la machine pourtant censée aider les hommes, le seul à bénéficier des retombées du processus productif est celui qui possède la grande Machine à fabriquer les machines. Ce type de système, poussé à son paroxysme, nous donne fatalement une situation où quelques riches possèdent tous les outils de production et exploitent sans vergogne une armée de misérables qui eux ne possèdent rien, et n’ont pas la moindre sécurité économique. C’est évidemment très simplifié, mais néanmoins vrai. L’arbitrage entre embaucher, c’est à dire, faire faire le travail par les hommes, ou bien, concentrer le capital, c’est à dire, investir dans l’outil de production est un choix de société et débouche, comme on l’a vu, vers des conséquences sérieuses . La question qu’on devrait se poser n’est pas de savoir combien d’heures-homme je « gagne » si je remplace mes ordinateurs par des ordinateurs plus récents et performants, mais de savoir à QUI ces gains d’efficacité profiteront-ils, et sont-ils justifiés eu égard au projet de société en vue. Il existe évidemment des situations où une économie de ce type est justifiée, par exemple, une situation de guerre économique, ou de guerre tout court. Mais ce qu’il faut saisir, c’est que le choix de mettre en œuvre une économie de guerre doit relever de la société et non de quelques individus.

            Si la machine permettait de libérer l’homme afin qu’il puisse se consacrer à autre chose, alors, je dirais : vive la machine ! Malheureusement, chacun sait qu’il n’en est pas ainsi dans nos démocraties capitalistes. La machine sert, depuis au moins l’époque des filatures de Manchester et de Lyon, à écraser les salaires des misérables qui font fonctionner la machine (le chômeur ne coûte rien au capitaliste, et de plus, fait office d’épouvantail pour ceux qui ont encore un emploi, ce qui les pousse à accepter des salaires plus faibles ou des conditions de travail plus dures). Le propriétaire de la dite machine, s’enrichit scandaleusement, tandis que la société en supporte les conséquences (chômage, misère sociale, ressentiment, etc.).

            Maintenant, considérons la réponse que Marx apporte à ce problème qu’il a eu le mérite d’avoir formulé en ces termes que je viens d’exposer plus haut : le capitalisme d’État, où le capitaliste propriétaire de la machine n’est pas un individu mais le Léviathan étatique. Cela n’a pas eu les résultats espérés, mais même en admettant que cela fonctionne comme Marx l’entendait (c’est à dire, alléger dans une certaine mesure le fardeau du travail de production), on peut se retrouver confronté à des problèmes d’un tout autre genre. Par exemple, le désœuvrement, la dépendance excessive du système productif envers la machine, ou encore sur-concentration de pouvoirs dans les mains de l’État avec tout le cortège de risques funestes que cela implique (bureaucratisation, totalitarisme, violence sociale).

            Ce qui me conduit à conclure que la réponse capitaliste à l’arbitrage entre capital et main d’œuvre, qu’elle soit privée ou étatique est rarement la bonne. Gardons-nous d’en conclure trop vite que la machine et les outils sont préjudiciables à la sanité sociale ; ce que je cherchais à montrer, c’est que c’est la machine qui doit servir l’homme et non l’inverse. Quand le capitaliste se sert du capital pour réduire les charges de personnel, en vérité, il asservit ce personnel par le jeu du mécanisme ci-dessus décrit. Il semble que la société, dans son ensemble, a tout à gagner à préférer l’embauche de main d’œuvre supplémentaire à l’acquisition de machines. À moins, bien sûr, que ces machines ne fassent ce qu’on en attend généralement : décharger l’homme de tâches ingrates, et démultiplier son potentiel.


          • BOBW BOBW 25 décembre 2011 12:06

            Merci Bovinus de privilégier les solutions humaines et sociologiques aux orientations technocratiques que choisit le système capitaliste esclavagiste :

            Choisissons et préférons de loin un philosophe humaniste à un économiste pro- fordien et tayloriste. smiley

          • Radix Radix 20 décembre 2011 19:57

            Bonjour

            Vous devriez vous amuser a démonter un graphique Excel dans un logiciel de dessin vectoriel comme Illustrator ou Corel Draw vous allez comprendre pourquoi cela rame sec.

            Vous allez découvrir que derrière le cadre il y en a un deuxième voire un troisième, idem pour tous les autres tracés. Je suis obligé de faire cette opération fastidieuse de « démontage » pour intégrer le graphique dans des applications ou je dois conserver le vectoriel mais avec une contrainte de poids.

            Pour Word c’est plus simple un copié-collé du texte dans le bloc-note et sauvegarde en txt pour enlever toute la « merde » attachée.

            Radix


            • Hubu 20 décembre 2011 21:57

              Dans un PC le composant qui est le véritable goulet d’étranglement depuis l’existence de l’ordinateur et vous oublier de le dire dans votre article en terme de rapidité est le disque dur qui certe croit sans arret en capacité (des 4 TO viennent de sortir au Japon) mais en terme de débits ça ne progresse quasiment plus depuis un bon moment !!!!

              Quand on voit les gains apporté par les SSD ou on passe de 100 Mo/sec en lecture/écriture avec les disque dur dans le meilleur des cas à 300/400/500 mo/sec voir plus de 1 GO en lecture/ écriture avec un SSD en PCI express et encore ca va continer à évoluer et s’améliorer tout en baissant.

              Les logiciels lourds n’ont qu’a bien se tenir !!!

              Les SSD sont capable de lire et d’écrire des petits fichiers à très grande vitesse là où le disque dur classique rame comme pas possible.


              • bzh_nicolas 20 décembre 2011 22:59

                Encore un spécialiste...

                Vous semblez confondre l’espace de stockage d’un ordinateur et sa puissance...
                Votre article aurait eut tellement plus d’impact en expliquant qu’un i7 haut de gamme est 130x plus puissant (en terme de flops) qu’un cray X-MP. Dommage, vous vous contentez de donner des quantités d’infos stockées, c’est sans intérêt et sans grande significations...

                P.S. : « comme les langages interprétés (Java tout particulièrement, .net, Javascript, Python, etc) »
                Java et les langages dotnet ne sont pas interprétés mais compilés (en byte code certe mais compilés quand même). Quand à java script et python ce ne sont certainement pas eux qui ralentissent tes applis, ils ne servent pas à ça...


                • Akwa Akwa 20 décembre 2011 23:42

                  Cet article est un article de vulgarisation, destiné au non spécialiste, afin de montrer de façon pratique et amusante les performances (en mémoire essentiellement) de nos ordinateurs, et les raisons des lenteurs pourtant constatées.

                  Le byte-code est un code machine interprété : il n’est pas natif. Il n’y a que les fanboy java pour oser jouer sur les mots, en prétendant qu’il est compilé, comme le serait du C.


                • cob 20 décembre 2011 23:59

                  Je dois être un gros fanboy Java, alors. smiley


                • Akwa Akwa 21 décembre 2011 00:10

                  @cob

                  Le JIT ne change rien au fait que le byte code n’est pas natif.
                  Par ailleurs, le JIT n’est pas valable sur toutes les plateformes, et la perte de performances avec la compilation JIT existe toujours.

                  Enfin, c’est totalement absurde de générer du byte-code, pour ensuite, en temps réel, le recompiler encore une fois en code machine natif.
                  C’est une solution d’ingénieur, qui amuse les ingénieurs, c’est tout.

                  Il est tellement plus logique de générer nativement du code machine natif pour chaque plateforme, comme le fait par exemple le freepascal.


                • Abou Antoun Abou Antoun 21 décembre 2011 00:34

                  Cet article est un article de vulgarisation, destiné au non spécialiste, afin de montrer de façon pratique et amusante les performances (en mémoire essentiellement) de nos ordinateurs, et les raisons des lenteurs pourtant constatées.
                  Ceci ne vous autorise pas à dire des choses fausses.


                • Abou Antoun Abou Antoun 21 décembre 2011 00:36

                  C’est une solution d’ingénieur, qui amuse les ingénieurs, c’est tout.
                  Les ingénieurs ont mieux à faire que de concevoir des programmes pour la multitude d’architectures existantes et de passer leur temps en maintenance. Le byte-code, les machines virtuelles c’est LA solution aux architectures multiples et aux problèmes d’évolution.
                  Vous parlez (très mal) de ce que vous ne connaissez pas.


                • cob 21 décembre 2011 00:43

                  La JVM n’interprète quasiment plus rien, en tout cas pas les sections de code critiques du type boucle-for. Historiquement, le Bytecode était destiné à être interprété mais ce n’est plus vrai aujourd’hui. Le JIT est plutôt devenu la règle que l’exception.


                  Du reste, un code natif n’est pas d’une conception plus « logique » qu’un code générique, les deux répondent seulement à des besoins différents. Notamment en terme de coût/délai de développement, de maintenabilité, d’évolutivité et j’en passe.

                • L'enfoiré L’enfoiré 21 décembre 2011 08:59

                  Abou,

                   "Les ingénieurs ont mieux à faire que de concevoir des programmes pour la multitude d’architectures existantes et de passer leur temps en maintenance. Le byte-code, les machines virtuelles c’est LA solution aux architectures multiples et aux problèmes d’évolution..« 

                  Je suis bien d’accord, mais ce n’est pas ce qui se passe.
                  Le métier a bien changé. A mes débuts (bien avant les PC), j’ai développé du software de base.
                  Tout était à faire.
                  Puis sont arrivés les PC, les langages se sont multipliés. Les versions (pour raison de marketing) aussi. Le gros et nouveau problème, c’était de garder la compatibilité entre chacun. Là, les surprises ont été nombreuses.
                  Accommoder la version d’un soft 2.8 d’un fournisseur avec la version 6.43 d’un autre.
                  On est passé tout doucement à la maintenance et à moins de développement pur »from scratch".

                   


                • L'enfoiré L’enfoiré 21 décembre 2011 09:01

                  Un petit texte qui a son importance dans ce jeu de quilles smiley


                • sonearlia sonearlia 21 décembre 2011 00:13

                  « D’un autre côté, dans l’idée de vouloir toujours tout révolutionner, de faire différent des »vieux« , et à un rythme effréné, on a cédé à de nombreuses technologies spécialement mauvaises, comme les langages interprétés (Java tout particulièrement, .net, Javascript, Python, etc), les langages massivement objets, menant à des pertes de performances souvent sensibles, et à une augmentation de la mémoire utilisée sans rapport avec la mémoire vraiment nécessaire. »


                  Je suis pas d’accord avec ça, ces langage ont permis la création de nombreuse application qui n’aurait j’amais trouver d’auteur s’il fallait les coder en C ou en pascal.
                  De plus ces langage permettent la vulgarisation de la programmation, on commence tous débutant un jours.

                  • Akwa Akwa 21 décembre 2011 00:24

                    Ces langages n’ont rien permis du tout, on pouvait parfaitement le faire en Pascal, voir même en Fortran, à partir du moment où l’on codait proprement, et en étant prévoyant.

                    Le Pascal a été inventé pour apprendre la programmation et le fonctionnement d’un compilateur, c’était et ça reste le meilleur langage pour débuter.

                    D’ailleurs, quand on a appris à coder en Pascal, on code proprement ensuite dans tous les autres langages.


                  • Abou Antoun Abou Antoun 21 décembre 2011 00:32

                    D’ailleurs, quand on a appris à coder en Pascal, on code proprement ensuite dans tous les autres langages.
                    C’est tout simplement absurde !
                    Vous allez prétendre qu’un Pascalien sait par nature programmer proprement en LISP en ALGOL ou en HASKELL ???


                  • Abou Antoun Abou Antoun 21 décembre 2011 00:40

                    Ces langages n’ont rien permis du tout, on pouvait parfaitement le faire en Pascal, voir même en Fortran, à partir du moment où l’on codait proprement, et en étant prévoyant.
                    Errare humanum est, perseverare diabolicum !
                    Vous êtes un vrai dinosaure (moi je suis simplement vieux).


                  • Akwa Akwa 21 décembre 2011 01:08

                    Je vous retourne la même chose.
                    Vous êtes aveuglé par les dogmes modernes.

                    Je préfère être un dinosaure, et être un bon codeur, soucieux de l’utilisation des ressources, que d’être à la mode et faire du code pourri.

                    Soyons honnêtes : jamais on a eu autant de problèmes à cause des ordinateurs ! Bagnoles ne démarrant pas, ascenseurs ne fonctionnant pas, trains en rade, etc !
                    Vos nouveaux langage n’ont fait qu’apporter des problèmes, et pas vraiment des solutions, sous couvert de rentabilité et de modernité !


                  • Abou Antoun Abou Antoun 21 décembre 2011 01:30

                    Erreur dans mon post précédent :
                    Vous allez prétendre qu’un Pascalien sait par nature programmer proprement en LISP en ALGOL ou en HASKELL ???
                    Je voulais dire LISP, PROLOG ou HASKELL.
                    C’est vrai que dans votre entreprise de démolition vous avez oublié le langage PROLOG.


                  • sonearlia sonearlia 21 décembre 2011 01:39

                    « Ces langages n’ont rien permis du tout, on pouvait parfaitement le faire en Pascal, voir même en Fortran, à partir du moment où l’on codait proprement, et en étant prévoyant.


                    Le Pascal a été inventé pour apprendre la programmation et le fonctionnement d’un compilateur, c’était et ça reste le meilleur langage pour débuter. »

                    Dans ce cas pourquoi ne sont t’il pas plus utiliser, pourquoi ne trouve t-on pas l’équivallent de pygame pour ces langages ? (je parle pas du module SDL, mais du site qui regroupe plusieurs milliers d’application utilisant ce module).




                  • L'enfoiré L’enfoiré 21 décembre 2011 09:06

                    Savez-vous qu’on recherche encore des programmeurs qui savent écrire dans le langage le plus utilisé à une certaine époque : le Cobol ?


                  • Akwa Akwa 21 décembre 2011 00:28

                    Merci d’éviter les messages limite hors-sujet, ne s’arrêtant que des deux dernières lignes de l’article.

                    L’article traite de ce dont son capables les ordinateurs d’aujourd’hui, par des exemples très parlant, puis enchaine sur la loi de Wirth, qui est vérifiée tous les jours.

                    Je sais qu’AV est fréquentée par de nombreux informaticiens, qui sont fréquemment des intégristes de leur langage (spécialement Java, comme le confirment les posts plus haut), mais je leur serait reconnaissant de ne pas polluer les commentaires.

Ajouter une réaction

Pour réagir, identifiez-vous avec votre login / mot de passe, en haut à droite de cette page

Si vous n'avez pas de login / mot de passe, vous devez vous inscrire ici.


FAIRE UN DON






Les thématiques de l'article


Palmarès