[ Debat ]loi de Moore & de Wirth

Pause Café
#1

Pourquoi nos programmes sont de plus en plus lents alors que notre materiel de pc deviens de plus en plus puissant et rapide

Loi de Moore : > de Gordon Moore, cofondateur d’Intel, en 1975 :
« Le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans. »

Loi de Wirth : > loi formalisée par Niklaus Wirth en 1995 :
« Le logiciel ralentit plus vite que le matériel accélère. »

donc nous comprenons qu’a la fin … :

« 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. »

je crois meme que Linus Torvald le disais lui meme dans une interview assez recente où il parlais justement de la gueguerre C versus C++

agoravox.fr/actualites/techn … les-106615

#2

Plus ils essayent de rendre facile une programmation d’un langage (plus il est ralenti il me semble (de mon point de vu je vois sa), sans vraiment connaître les détails du fonctionnement des langages).

Je m’en vais pour lire les commentaires de l’article, il y a des très long commentaire :smiley:
Comme le dit notre chère Dr. House, interesting.

#3

C’est faux. Le langage n’est pas un problème. Dire le contraire c’est juste démontrer que l’on ne comprend rien à la performance. Linus a déjà prouver que s’il est excellents en gestion de projet et en système il ne comprend rien aux langage.

D’une part le design est plus important que le langage d’autre part nous ne demandons pas la même chose aux logiciels actuels qu’avant.

#4

oui et de plus ca se défend pas mal niveau comm, certaines anecdote sont tres interressantes

je comprends bien , c’est meme evident mais justement comme le faisais remarquer le Torvald se s’rais 'ti pas mieux d’eviter les codes a ralonge qui alourdisse le prog pluss qu’il ne fonctionne ?

#5

Sa revient plus ou moins à ce que j’ai dit (à moins que je me trompes encore :smiley:).
Plus il essaye de complexifier ce qui est de base niveau langage (pour x raison), plus sa ralenti.

Bien que cet ralentissement peux s’avérer raisonnable pour x raison.

Un mec qui s’y connaît en X langage ne vas pas de manière exprès apprendre Y autre langage par ce qu’il sera plus rapide (à moins que sa vaut vraiment le coup).

Sans parler du côté matériel auquel j’avais complètement zapé, auquel je me suis souvenu en lisant les commentaires de l’article.

Il y a un bon nombres de facteurs qui rentrent en jeux.
(langage, matériel, le programmeur, portabilité,…)

#6

Il me semble, Kripteks, qu’effectivement tu tu trompes (ou alors c’est moi)…

[divination]
Ce qui compte pour la rapidité d’execution c’est la complexité de ton algorithme. Elle sera la même quel que soit le language utilisé. Donc, à moins que le compilateur soit moisi, tu te retrouves à la fin ac un executable qui devrait tourner aussi vite quel que soit le language utilisé à l’ecriture du code.
Les différences entre les languages viennent du fait qu’ils ne sont pas pensés à la base pour atteindre les mêmes buts. Si tu codes quelquechose dans un language qui n’est pas prévu à la base pour ce que tu veux, tu vas perdre du temps, obtenir un code plus difficile à lire, etc… mais si tu codes bien, il devrait être aussi rapide qu’avec un autre language.

En revanche, je suis d’accord pour dire que lorsque l’on est trop assiste, on perd en optimisation et le résultat peut être trop lourd par rapport à ce qu’on attend.
[/divination]

#7

Voila tout à l’heure je postais à partir de mon téléphone je vais maintenant m’exprimer plus librement.

Il y a 15 ans, les logiciels faisaient bien moins de choses :
[ul]
[li]pas ou peu de réseau[/li]
[li]pas de multimédia[/li]
[li]matériel simple[/li]
[li]modèle d’interaction simplistes[/li][/ul]

Augmenter la puissance de nos machine ne sert à rien si c’est pour faire exactement la même chose, aujourd’hui on veut avoir accès à 16 millions de couleurs, avoir pleins d’interactivité entre les logiciels, avoir du plug’n’play pour tout, avoir de la fiabilité à tout les niveaux,… et ça ça a un cout.

Pour ce qui est des langages, il est faux de croire que hors du C/Fortran/COBOL/Pascal/lisp point de salut (comment ont l’écris dans ces cas ?).

Les langages de (très) haut niveau permettent d’avoir de se focaliser sur le design ce qui est le point le plus crucial pour 80 % des performances (si on considère la règles des 80-20). Changer de langage ça peut représenter 10 ou 20 % de gain de performance une amélioration du design ça peut faire passer le programme d’une complexité linéaire à logarithmique (à chaque fois que l’on double la taille de l’entrée au lieu de doubler le temps d’exécution il prendra log(2) plus de temps.

Hors les excellents programmeurs sont très rare, très bas niveaux et qui ne sauront pas forcément faire les optimisation de plus haut niveau la machine optimiseras bien souvent mieux que toi. Au sujet de la qualité (ou non) des programmeurs, je souhaiterais rappeler aux éventuels élitistes que si l’informatique est là où elle est c’est surtout grâce à sa démocratisation, je suis d’accord pour dire que chacun doit toujours chercher à s’améliorer, mais je m’oppose aux donneurs de leçons qui méprisent les « mauvais programmeurs ».

La performance ce n’est pas tout, la portabilité, la maintenabilité, la robustesse, la fiabilité, la sécurité, etc sont des critères tout aussi importants que la performance et chacun de ses points peu faire perdre de la performance.

#8

Moi je le vois différemment. Plus tu programme de haut niveau plus tu donne d’informations sur ton code au compilateur et plus il peut avoir d’optimisations.

Un exemple simple serait la boucle foreach. Elle est de plus haut niveau que le for classique, mais le compilateur interpréteur sait que tu va parcourir l’ensemble du conteneur, il va donc pouvoir placer ça dans les registre adéquate s’il peut et en fonction de l’architecture cible. Si le langage définit que l’itérateur du foreach est constant (comme en Java), il peut éviter des recopies inutiles.

#9

Je viens de lire l’article, il me fais vomir.

Les deux premiers exemples prennent la moitié de l’article mais ils ne représentent rien : oui on a de l’espace de stockage a ne plus savoir qu’en faire, mais quel est le liens avec la puissance ou la performance ?

Ensuite son exemple avec les Suites Bureautiques se base sur :

et

Des arguments dit d’autorité, l’auteur a dis que donc c’est vrai.

La conclusion particulièrement affligeante :

Comme c’est bon de taper sur ces médiocres. Parce que nous (moi, l’auteur de cet article) on sait ce qu’est un bon ou un mauvais programmeur, hein, et on sait où on se trouve dans cette catégorisation.

non seulement ces médiocres sont partout mais en plus on viens de découvrir une nouvelle méthode pour vérifier la qualité d’un programmeur : le nombre de ligne de code !

Pas de peau, lisp est un langage interprété et fonctionnel qui date de 1958 (John McCarthy si tu nous regarde on pense à toi).
Le paradigme objet nait en 1969 avec Smalltalk et est utilisé dans les jeux vidéos où le besoin en performance est énorme. Par exemple le moteur de doom 3 écris par un célèbre développeur, John Carmack, qui est très renommé et qui à commencé à faire parler de lui avec des jeux comme Wolfenstein 3D ou Doom. Mais bon, il doit faire partie de ces médiocres développeurs qui font de mauvais choix là où Akwa sait ce qui est bon.

Je tiens encore une fois à souligner que la performance n’est qu’un critère parmi d’autres de qualité logiciel.

#10

[quote=“silver.sax”]Il me semble, Kripteks, qu’effectivement tu tu trompes (ou alors c’est moi)…

[divination]
Ce qui compte pour la rapidité d’execution c’est la complexité de ton algorithme. Elle sera la même quel que soit le language utilisé. Donc, à moins que le compilateur soit moisi, tu te retrouves à la fin ac un executable qui devrait tourner aussi vite quel que soit le language utilisé à l’ecriture du code.
Les différences entre les languages viennent du fait qu’ils ne sont pas pensés à la base pour atteindre les mêmes buts. Si tu codes quelquechose dans un language qui n’est pas prévu à la base pour ce que tu veux, tu vas perdre du temps, obtenir un code plus difficile à lire, etc… mais si tu codes bien, il devrait être aussi rapide qu’avec un autre language.

En revanche, je suis d’accord pour dire que lorsque l’on est trop assiste, on perd en optimisation et le résultat peut être trop lourd par rapport à ce qu’on attend.
[/divination][/quote]

Les algorithmes sont très bien faits et en général très bien codés, souvent en C ou C++ d’ailleurs. Le gain a écrire en assembleur par exemple serait réel mais stupide notamment en terme de gestion de programme. Contrairement à ce que dit l’article les programmes vont de plus en plus vite:

  • Vers les années 1980 à la naissance de la CNIL, il suffisait d’interdire une clef commune pour empêcher le croisement de fichier. L’annuaire inversé est né vers 1990 et a nécessité 3 mois pour établir la base. Un PC fait ça maintenant en très peu de temps.
  • L’encodage d’une video prenait pas loin de 12h au tout début avec des codecs mauvais, ils se font maintenant en moins de 3h avec une qualité impressionnante.
  • Les algorithmes de force brute, d’utopique sont devenus une réelle menace
  • La gestion de base de données de plus en plus gigantesques montrent cette augmentation de puissance.

Par contre effectivement alors que lors du premier programme que j’ai vendu, le design représentait 10% du code mais tout de même sans la doc et le débugage seulement 25% du temps, désormais l’apparence et l’ergonomie constituent les plus gros morceaux. Ceux ci se font souvent avec des bibliothèques généralistes et sophistiquées qui elles peuvent ralentir le code. Il suffit par exemple de voir ce que coute la gestion de la transparence, des fenêtres, etc. C’est pour ça que le petit lecteur de news prend plus de temps, mais un gros programme de calcul prend infiniment moins de temps maintenant qu’avant.

#11

:text-bravo:

:clap: Bravo pour ces excellents principes ! et pour la clarté de la leçon qui l’accompagne :wink:

et une excellent idée pour les résolutions à prendre bientôt pour 2012.