Discussion :

[megs]

Je suis d'accord, il est totalement hors sujet...d 'ou le 0 pointé... C'est comme si on lui demandai :"déclinez les types de nuages en fonctions de leurs altitude" et qu'il répondait :"les nuages les plus haut sont les plus rapides et les nuages les plus bas sont les plus lents" .
De plus même si il n'a pas tord, il n'a pas forcement raison non plus... Ca dépend du codeur...on peut tres bien faire un code plus merdique en ASM qu'en VB.. c'est dure mais c'est possible. Je ne parle pas du C vu que l'optimisation du compilateur permet parfois de faire des miracles.

[arkhamon]

Allez c'est jeudi, et ça fait longtemps que j'ai pas fait mon sale caractère.
Cet étudiant mérite.... 0, 0 et mille fois 0 !
On lui demande une chose, il ne répond pas à la question, répond à une autre qu'on ne lui a pas posé, et en plus sort des conneries ! Donc mille fois 0 !

Je m'explique :

Au début était... Le binaire. Pour ceux de mon âge ou plus, rappelez vous si vous avez bossé sur un nano-ordinateur : 8 interrupteurs, un bouton reset et un bouton run... Ca c'est du binaire, encore appele langage machine, ou L1G. C'est le seul compris par l'ordinateur. Pour le coup, pas très convivial mais bon... Ici la dépendance est au niveau de l'ordinateur lui même !

Vient ensuite l'assembleur :
LD AH, ...
MOV ...
PUSH AL...
Que du bonheur ! On est déjà en dehors de ce qui est compréhensible par la machine, puisqu'on est obligé de passer par un pseudo compilateur (ASM et EXE2BIN ça vous rappelle de (mauvais) souvenirs ?
Ca c'est L2G. La dépendance est au niveau du micro-processeur, et dans certains cas de la machine et/ou de l'OS (si si rappelez vous l'appel des interruptions DOS (surtout celles non documentées)...)

Bonheur suprême : BASIC, Pascal COBOL, Fortran, ADA, JAVA, Shell Unix (ben oui c'est aussi un L3G)... Le royaume de l'informatique, l'eldorado des programmeurs... Enfin des boucles compréhensibles, de la récursivité (presque) contrôlée, des données évoluées... Tiens vous notez comment j'ai volontairement pas parlé de C ? Bon d'accord, en fervent défenseur de Pascal, je suis de mauvaise foi... Bien sur que C a aussi sa place ici !
Certains sont interprétés (Basic, VB), d'autres compilés (C, Pascal, Ada), certains enfin sont pseudo compilés, on parle de P-code (Cobol, JAVA...) et ça nécessite un compilateur et un interpréteur (cherchez l'erreur).
J'oubliais : on est en L3G. Ca y est, on est enfin indépendant du processeur et de la plateforme. Et même dans certains cas (le seul intérêt du P-Code à mon avis), on est multi plateforme !

Viennent ensuite les langages de manipulation de données type SQL : là on s'éloigne temporairement des notions de programmation standards et on se tourne vers la manipuilation de données hiérarchisées, relationnelles... C'est les L4G. Là on est totalement indépendant de l'OS aussi : c'est l'ère du client-serveur, de Saint Oracle...

Et quand on a fait tout ça on fait quoi ? On essaie d'être intelligents (ou du moins de faire croire que les machines le sont) et on attaque les L5G : les langages de manipulation de prédicats pour l'intelligence Artificielle (LISP, Prolog....). Perso je suis hermétique, mais bon... Bon là je sais plus trop de quoi on dépend en fait... Notez bien que même ici, on passe par un interpréteur ou un compilo, puisque de toutes façons...

AU FINAL, ON REVIENT TOUJOURS AU BINAIRE !!!!!

Voila ce qu'une bonne réponse (si j'ai fait une coquille dites le moi) eut pu être. Mais certainement pas ce qu'il a marqué !

Après pour ce qui concerne la convivialité et tout le reste, faut voir. Certaines personnes adorent le C, d'autres le Pascal, j'avais un pote en ingé qui était tri-lingue : Français, Anglais et assembleur 80386, et qui ne comprenait pas qu'on passe par un compilo avec ces langages de tapette alors qu'on peut tout faire en ASM... Je respecte, et suis même u peu jaloux...

Ensuite les perfs... Là je m'amuse. A plateforme identique (je veux dire même machine et même OS), qu'est ce qui fait la différence de perf sur un même résultat ? Je parle bien de resultat et pas de soft, la nuance est subtile :

• la qualité du progragrammeur, qui sait (ou pas) générer un code optimisé (genre on balaye une liste jusqu'à ce qu'on ait trouvé l'élément et pas tout balayer)
• la qualité du code produit par le compilateur

Vous remarquerez que je laisse de côté les langages interprétés, ils sont effectivement plus lents. Que dire alors du P-Code...

Donc, pour un même algorithme (mot utilisé volontairement), la seule différence de performance se situe dans le code généré par le compilateur. Si celui ci est optimisé, alors le code est plus rapide ou moins gourmant...
Certains compilateurs (dont Turbo PAscal et delphi après) optimisent déjà certaines choses. Ainsi dans le code suivant (et avec la bonne option de compilation qui va bien) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
if false and MaFonction(argument) then
  begin
  end;

l'appel à la fonction MaFonction ne sera jamais exécuté car il est inutile, le résultat du test étant de toutes façons "False". Notez bien que si je tenais le programmeur qui a pondu ce code, je le....

En conclusion, à mon avis, entre mêmes générations de langages, et même mode d'exécution, AUCUN langage n'est plus rapide ni performant qu'un autre, tout dépend du compilateur.

[Gecko]

arkhamon>

Grace à toi j'aurais appris des chose super intéressantes ^^

[Paul TOTH]

Allez c'est jeudi, et ça fait longtemps que j'ai pas fait mon sale caractère.
Cet étudiant mérite.... 0, 0 et mille fois 0 !

alors j'ai fait un peu de math dans mon jeune temps et j'en ai gardé (entre autre) que mille fois 0 ça fait toujours 0

ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit
Alors évidemment il était question de projets qui nécessitaient des temps de réponse particuliers, comme mon émulateur CBM64 qui tournerai parfaitement et sans optimisation sur un PC moderne, mais pas sur un 286

[Tommy31]

ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit

D'où l'existence de la confortable directive assembleur, dont je me suis beaucoup servi étant plus jeune pour l'optimisation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Begin
  ...
  asm
    ...
  end;
  ...
End;

[arkhamon]

alors j'ai fait un peu de math dans mon jeune temps et j'en ai gardé (entre autre) que mille fois 0 ça fait toujours 0

J'adore le pragmatisme des mathématiciens Tout à fait d'accord. Un peu d'humour ne nuit jamais dans ce monde de brutes !

ensuite je ne suis pas tout à fait d'accord avec toi, j'ai par exemple beaucoup développé en Turbo Pascal justement à l'époque des 286, 386 et 486 avec des cartes VGA de base...et bien sans assembleur tu ne pouvais pas obtenir des performances suffisantes - quelque soit l'algorithme - en n'utilisant que le langage Pascal, tout optimisé qu'il soit
Alors évidemment il était question de projets qui nécessitaient des temps de réponse particuliers, comme mon émulateur CBM64 qui tournerai parfaitement et sans optimisation sur un PC moderne, mais pas sur un 286

Effectivement j'ai le souvenir d'avoir fait ça pour m'amuser car je n'ai jamais développé de trucs ayant de tels besoins de perfs. Un peu avec mon ZX81 quand il avait 1 KO de RAM ouais ouais vous avez bien lu, mais bon c'était au siècle dernier... Effectivement Paul, tu as raison, Turbo pascal, comme la presque totalité des L3G, est moins rapide que du code ASM inséré dedans, car en général le compilateur doit être assez général, donc il génère un code assez gros et aps forcément optimisé. On retrouve ici le vieux débat entre processeurs RISC (Reduced Instruction Set) et CISC (Common Instruction Set) : plus le proc est capable de faire de choses différentes, plus il met de temps à décoder ce qu'il doit faire. Pareil pour un compilo...
Mais tu as parfaitement raison...

[ALT]

Euh non !
CISC = Complex instruction set code.

[arkhamon]

Euh non !
CISC = Complex instruction set code.

Oopps si je me mets à raconter des conneries moi... Oui effectivement, erreur de ma part...

[romuald59220]

Alors ? Tous d'accord pour son 0 pointé ?

Rappel de sa réponse :
"Plus le langage est convivial pour le développeur, plus lent sera le programme. Et plus le langage est « convivial pour l'ordinateur », plus rapide sera le programme."

[CodeurPlusPlus]

(...)

En conclusion, à mon avis, entre mêmes générations de langages, et même mode d'exécution, AUCUN langage n'est plus rapide ni performant qu'un autre, tout dépend du compilateur.

Il n'y a donc plus qu'à écrire un compilateur Python qui fera mieux que n'importe quel compilateur C... ainsi les gentils rêveurs qui nous expliquent que les langages de haut niveau sont plus rapides que les langages de bas niveau pourront enfin avoir raison.

Sinon je ferais remarquer qu'il ne faut pas prétendre, comme certains l'ont fait, que la question posée était stupide. Parce qu'il faudrait savoir ce qu'il y avait dans le cours pour juger de la pertinence de la question.

[Invité]

A en juger par le volume de discussions, ça ressemble plus à un sujet de philo que d'informatique pure

Steph

[rinhary]

ceci est un échantillonnage d'après moi.
réponse: vous deviez assurer vos connaissances entre manipulation, compilation et exécution des données