Discussion :

[le pythonien]

J'avoue que je n'arrive pas à le croire.
Vous êtes sans douter que l'Assembleur est le langage de programmlation le plus proches de la machine.
Selon moi, si l'Assembleur est plus proche de la machine alors il est forcément le langage de programmation le plus rapide n'est-ce pas ? (c'est quand même logique).

Et bien je vous apprends que cela est peut-être faux.
Car je programme en Python et mon programme en Python met 2 secondes pour m'afficher cent fois le mot "traore" tandis que l'Assembleur me met plus de 5 secondes. Alors cela veut-il dire que l'Assembleur, bien qu'il soit assez proche de la machine, reste néanmoins le langage de programmation le plus lent ? , et du moins le moins adapté pour la programmation de nos jours ? Car tout programme qui se respecte doit être assez rapide pour traiter de nombreuses informations et cela en un temps record

Alors s'il y a quelqu'un qui peut m'expliquer.
Pour les infos je programme en Assembleur 16 bits.

Ou alors est-ce le 16 bits qui est lent ?
A vrai dire je suis un peu découragé et j'espère que j'ai tort

[dapounet]

ou alors est ce le 16 bits qui est lent?

Oui, les programmes 16 bits sont émulés sous Windows donc ton test ne représente rien. En plus dans ce cas-ci les performances sont clairement limitées par le temps mis pour afficher le texte à l'écran.
Quand j'avais résolu des problèmes de Project Euler j'avais été surpris de voir que les performances ne changeaient pas entre une version assembleur, C ou Python. Par contre j'avais lu il y a quelques mois que Python avait vraiment un problème avec le multithreading.

[Mat.M]

et bien j e vous apprend quecela est peut etre faux.
car je programme en python et mon programme en python met 2 seconde pour m affiher cent vopis le mot "traore" tandis que l assemleur me met plus de 5 secondes.:

Hé ! Tout dépend de ton programme assembleur si tu utilises par exemple les interruptions du BIOS ou du DOS si tu copies des données sur les registres de la pile....
Python c'est sans doute développé en C et les compilos C sont particulièrement optimisés au niveau du code

[Obsidian]

Alors s'il y a quelqu'un qui peut m'expliquer.
Pour les infos je programme en Assembleur 16 bits.

Et le Python, à ton avis, en quoi est-il écrit ? :-)

Bon, déjà, l'assembleur, c'est le langage du microprocesseur. Plus précisément, son jeu d'instruction et ses modes d'adressage. Ça veut dire que c'est une forme lisible du langage machine. Ce n'est pas simplement un langage « bien noté », ou plus performant parce que mieux conçu.

Si tu veux faire un bench qui mesure réellement les performances d'un programme, fait un programme qui dure plus de quelques secondes, d'une part, et qui soit réellement autonome :

Essaie par exemple de compter de zéro à 4 milliards :

En assembleur :

Code :

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

1
2
3
            xor ecx,ecx
branch:     dec ecx
            jnz branch

Et en Python

Code :

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

1
2
3
4
 
a = int (0xffffffff)
while a:
    a=a-1

Et mesure les temps d'exécution des deux :-)

[jeremya]

Je programme en Python et mon programme en Python met 2 secondes pour m'afficher cent fois le mot "traore" tandis que l'Assembleur me met plus de 5 secondes.

Lorsque tu programmes en Python, le compilateur réalise des optimisations (par exemple, choix des instructions les plus rapides) pour améliorer les performances du programme.
Lorsque tu programmes en Assembleur, le compilateur va générer un programme proche de ce que tu as écrit.
Il est donc fort probable que le programme Python soit mieux "optimisé" que le programme Assembleur, d'où la différence de performances.
Pour t'en convaincre, tu peux désassembler le programme Python, et comparer le code Assembleur généré par le compilateur Python avec ce que tu as écrit en Assembleur.

[Forthman]

Hello,

J'ai pas tout compris a ton programme en Assembleur,
tu affiches 100 fois un mot c'est bien ca ?
Mais comment ? dans une fenetre Win$ ? directement sur l'ecran
en mode texte ?

car meme si les programmes 16 bits sont emules, pour afficher 100 fois
un mot de 6 caracteres, il ne faut pas 5 Secondes !

Je viens de faire un test sur un Celeron a 2.4GHz sous XP, avec un
petit prog en Forth (donc pas en assembleur hein)

Pour afficher 65536 fois le mot "TRAORE" en mode plein ecran en mode texte
en utilisant les fonctions DOS (int21h) et en laissant faire les sauts de pages
(et ca c'est lent)....
Bon, tout ca tout ca.... il me met 11.31secondes

En mode fenetre DOS sous XP ce temps passe a 3.79 secondes mais la c'est
de la triche car la fenetre n'est pas rafraichie souvent

Donc j'ai pas encore tout compris a ton "test"

a+ Francois

[teurastaja]

Et le Python, à ton avis, en quoi est-il écrit ? :-)

Bon, déjà, l'assembleur, c'est le langage du microprocesseur. Plus précisément, son jeu d'instruction et ses modes d'adressage. Ça veut dire que c'est une forme lisible du langage machine. Ce n'est pas simplement un langage « bien noté », ou plus performant parce que mieux conçu.

Si tu veux faire un bench qui mesure réellement les performances d'un programme, fait un programme qui dure plus de quelques secondes, d'une part, et qui soit réellement autonome :

Essaie par exemple de compter de zéro à 4 milliards :

En assembleur :

Code :

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

1
2
3
            xor ecx,ecx
branch:     dec ecx
            jnz branch

Et en Python

Code :

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

1
2
3
4
 
a = int (0xffffffff)
while a:
    a=a-1

Et mesure les temps d'exécution des deux :-)

en fait, mesurer le VECTEUR temporel pour etudier limpact direct de labstraction linguistique par calcul du coefficient de deceleration (plus long est le test, plus il est fiable). Le vecteur physique n'etant pas souhaite car lalgorithme doit calculer labsolu. par ailleurs, ce genre de test nest nen est qu1 sur bien des methodes...

[Rekin85]

teurastaja a écrit :
en fait, mesurer le VECTEUR temporel pour etudier limpact direct de labstraction linguistique par calcul du coefficient de deceleration (plus long est le test, plus il est fiable). Le vecteur physique n'etant pas souhaite car lalgorithme doit calculer labsolu. par ailleurs, ce genre de test nest nen est qu1 sur bien des methodes...

En bon Français sans erreur d'orthographe, cela semblerait sorti tout droit de "La théorie du bordel ambiant" de Moreno...

[Rémi Coquet]

+ je me demande si l'énergie dépensée sera réellement compensée par une avancée intellectuelle quelconque