spectras a écrit :

ce que je voulait dire dans mon pavé mal foutu, c'est que ce que tu peut faire avec le "haut niveau", tu peut le faire aussi bien en "bas niveau" voir meme peut etre mieux car tu n'est pas bridé par le fonctionnement dudit haut niveau

Bien entendu. C'est toujours le même équilibre, aussi vieux que le premier assembleur : temps de développement / temps d'exécution.

Ça, c'est sûr, d'où l'existence de tous ces langages de programmation plus ou moins adaptés à ce que l'on veut faire.
Ainsi, mes 2 langages de prédilections sont l'Asm X86 et le PHP :[ul][li]quand les entrées se limitent à quelques touches sur le clavier, la sortie à quelques lignes à l'écran, mais avec vraiment beaucoup beaucoup de calculs à faire entre les deux Asm (les interfaces d'entrée/sortie en Asm, c'est la mort )
[li]quand les entrées sont compliquées (tableaux de taille variable) et de même pour la sortie (tableaux ou graphiques avec de la couleur pour mettre en évidence les points cherchés), mais avec un traitement pas trop long entre les deux PHP (les formulaires pour les entrées et les tableaux HTML pour la sortie, c'est le bonheur )[/ul]

GoldenCrystal a écrit :
Dans la façon dont je vois les choses, un algorithme exprimé en C, est l'expression de l'algorithme en lui même (souvent déjà optimisé par le cerveau humain... tiens donc le compilo C sait pas le faire à notre place ? ^^), et le même algorithme en un langage bien plus évolé, sera plus la représentation conceptuelle de l'algorithme que l'algorithme lui-même.

[...]

Et si je défends les hauts niveau sur le fait qu'ils simplifient la vie aux programmeurs, je les défends pas sur le fait de les rendre cons hein... Si tu vois une [vraie] optimisation à faire (simple qui plus est), alors fais là... Le compilateur l'aurait peut-être fait ou peut-être pas, mais là au moins tu sais que c'est fait. Parce que bon, avec des "le compilateur devrait" tu finis par faire des codeurs fainéants qui ne cherchent même pas l'optimisation, et le compilateur derrière ne doît jamais être une excuse pour ça.

J'ajouterai cependant une nuance dont je n'entends jamais parler : la différence entre algorithmie théorique et algorithmie pratique.
Prenons un cas simple déjà abordé, l'itération :[ul][li]en Java et autres langages de haut niveau (HLL), on va utiliser comme le dit si bien GC une représentation conceptuelle de l'algorithme d'itération en utilisant par exemple un Iterator si on travaille sur une Collection c'est de l'algorithmie conceptuelle
[li]en C (ce que j'appelerai un langage de niveau intermédiaire (MLL)) mais aussi en Java quand on travaille sur les types primitifs (int[] par exemple), on utilise une expression directe de l'algorithme avec une boucle for du genre for ( i = 0 ; i < N ; i ++ ) {...} sans effet de bord sur i ça reste selon moi de l'algorithmie théorique, puisque la théorie dit de parcourir les éléments du tableau, donc on parcourt les éléments du tableau
[li]en Asm == langage de bas niveau (LLL), on sait ce que donne la boucle for précédente (genre, en admettant que N est une constante strictement positive connue à l'assemblage (== compilation) : xor eax,eax | Boucle: | ... | inc eax | cmp eax, N | jl Boucle), et on connaît les flags lus et/ou mis à jour par les instructions : donc si, de manière pratique, l'algorithme peut être adapté à une lecture décroissante du tableau (ce qui est assez généralement le cas), alors il est plus efficace d'écrire mov eax, N | Boucle: | ... | dec eax | jge Boucle (quelques milliards de cmp eax, N en moins sur chaque boucle du programme, croyez-moi, on sens la différence) j'appelle ça de l'algorithmie pratique, on ne reste pas à l'algo théorique qui dit qu'il faut itérer sans préciser si le sens de parcours importe (auquel cas, très bêtement, tout le monde va parcourir dans le sens croissant )[/ul]
Et je trouve qu'il est important d'adapter pratiquement au langage cible l'algorithme théorique de base.
Ainsi, concrètement, j'ai pris il y a 2–3 ans l'algorithme de cryptage DES tel qu'il est donné dans le document descriptif officiel, et je l'ai retravaillé dans l'optique 'Asm pur', en réfléchissant à la représentation des données et aux instructions que j'allais utiliser, pour en faire un nouvel algo décrivant ce que j'allais faire en Asm. Voici textuellement le SMS que m'a envoyé squalyl le 27/07/2004 :

Cryptage DES d'un bloc avec 65536 clés, programme en C. version internet: Sans optimisation: 2273 ms, optimisé 631 ms. Version Ethaniel: Non opti: 1172 ms, opti: 611 ms... Je peux vous appeler maître?

Note : ce qu'il appelle 'optimisation' (je lui ai demandé après), c'est l'option -O de GCC.
D'ailleurs, il faudrait vraiment que je me remette à ce programme, surtout que j'ai trouvé à la même époque comment remplacer 2 instructions à 4µops (sur P4) par 4 instructions à 1µop deux fois moins de temps, et comme en plus il y a plus d'instructions, on peut mieux faire du pipe-lining \o/ !
Et il faudrait aussi que je passe en MMX, paske là tous mes registres normaux sont utilisés et ça me bloque parfois un peu...