Attention au raisonnement tout de même : qu'est-ce qu'un programme assembleur fourni par du C ? c'est du C compilé. Qu'est-ce qu'un programme assembleur ? c'est de l'assembleur, écrit par quelqu'un. Donc on ne compare que des compilateurs et des programmeurs, pas des langages, vu que ce qui est exécuté ce n'est jamais que de l'assembleur.
Et encore on n'a pas parlé de la distribution des données d'entrées, qui joue fortement sur les performances des programmes quand on les compare.
En effet, définissons un programme comme suit : il prend des données dans une certaine zone de mémoire (comprenant éventuellement les données aléatoires qu'il aura à récupérer, sans perdre de généralité). Il fait ensuite un traitement déterministe et sort les résultats dans une certaine zone de la mémoire (bon c'est presque une machine de Turing notre programme, ami lecteur sauras-tu retrouver la différence ? ).
Si on prend le compilateur théorique suivant, on aura parfaite égalité de vitesse dans les programmes entre tous les langages :
1) il prend le code initial (du C, du Lisaac, etc.)
2) il génère tous les codes assembleurs qui réalisent la même opération (données en mémoire -> sortie en mémoire). C'est possible en temps fini (il suffit de tout énumérer) mais c'est long (bon j'ai précisé que c'était un compilateur théorique, hein ;-) )
3) le compilateur lance chaque programme sur toutes les entrées possibles (pareil, c'est encore plus long ;-) )
4) il choisit à chaque fois le programme le plus rapide pour effectuer les tâches.
Alors l'assembleur, écrit par un humain, sera forcément plus lent ou au mieux aussi rapide que le C/Lisaac/tout ce que vous voulez.
ensuite si on veut chipoter sur les données on se met d'accord sur une distribution de probabilité des données d'entrées et sur la façon de calculer la meilleure vitesse (vitesse moyenne sur les entrées ? vitesse dans le pire cas ? ... ? ) et on recommence le compilateur précédent, en choisissant le programme le plus rapide.
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par khivapia . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
Et encore on n'a pas parlé de la distribution des données d'entrées, qui joue fortement sur les performances des programmes quand on les compare.
En effet, définissons un programme comme suit : il prend des données dans une certaine zone de mémoire (comprenant éventuellement les données aléatoires qu'il aura à récupérer, sans perdre de généralité). Il fait ensuite un traitement déterministe et sort les résultats dans une certaine zone de la mémoire (bon c'est presque une machine de Turing notre programme, ami lecteur sauras-tu retrouver la différence ? ).
Si on prend le compilateur théorique suivant, on aura parfaite égalité de vitesse dans les programmes entre tous les langages :
1) il prend le code initial (du C, du Lisaac, etc.)
2) il génère tous les codes assembleurs qui réalisent la même opération (données en mémoire -> sortie en mémoire). C'est possible en temps fini (il suffit de tout énumérer) mais c'est long (bon j'ai précisé que c'était un compilateur théorique, hein ;-) )
3) le compilateur lance chaque programme sur toutes les entrées possibles (pareil, c'est encore plus long ;-) )
4) il choisit à chaque fois le programme le plus rapide pour effectuer les tâches.
Alors l'assembleur, écrit par un humain, sera forcément plus lent ou au mieux aussi rapide que le C/Lisaac/tout ce que vous voulez.
ensuite si on veut chipoter sur les données on se met d'accord sur une distribution de probabilité des données d'entrées et sur la façon de calculer la meilleure vitesse (vitesse moyenne sur les entrées ? vitesse dans le pire cas ? ... ? ) et on recommence le compilateur précédent, en choisissant le programme le plus rapide.