Alors, soyons bien d'accord: je sais à quel point un compilateur ça trompe énormément. Je sais entre autres parce que je bosse au même niveau (juste au-dessus du matériel, ou dans le compilateur).
Cela étant dit: si tu prends n'importe quel guide sur l'optimisation de code (disons le manuel d'Intel sur la question par exemple http://www.intel.com/Assets/PDF/manual/248966.pdf, ou le site de A.Fog, http://www.agner.org), ou surtout des manuels plus haut-niveau (pour les gens qui ne veulent/peuvent pas passer le temps qu'il faut à micro-optimiser leur code), les méthodologies proposées impliquent souvent de compiler à différents niveaux d'optim (-O0,..., -O3), et de prendre un jeu d'essai représentatif -- bref, de faire à la main ce que certains compilateurs (icc, et normalement gcc aussi, par exemple) savent faire depuis un moment: de la compilation guidée par profilage.
De plus, que -O3 puisse ralentir un programme, je le crois volontiers; qu'il donne des résultats faux (ou même que l'optimisation a eu un effet de bord surprenant, disons), à moins d'un bug dans le compilateur, c'est plutôt que l'utilisateur a fait des hypothèses quant au langage/à la machine qu'il utilise (je parle d'expérience).
Concernant la cohérence et l'élégance d'un langage et sa prévisibilité, je ne suis pas certain de comprendre ce que tu veux dire par là. La plupart du temps (mais clairement pas toujours), plus de concision implique plus de clarté, mais cela suppose néanmoins une compréhension du langage, et de comment il fonctionne. J'ai l'impression qu'une bonne partie des reproches faits aux langages « différents » (qu'ils soient fonctionnels, tels que ML, Haskell, LISP, déclaratifs tels PROLOG, ou bien juste « glu » genre Perl) est qu'ils ne fonctionnent pas comme leurs cousins impératifs tirés du C. J'ai exactement le même problème avec Fortran par exemple, et pourtant il n'est pas si éloigné du C que ça (en supposant qu'on passe à Fortran 90 au minimum pour avoir la forme libre de syntaxe).
[^] # Re: typage mou
Posté par lasher . En réponse à la dépêche Quelques nouvelles de Go, le langage de programmation. Évalué à 3.
Cela étant dit: si tu prends n'importe quel guide sur l'optimisation de code (disons le manuel d'Intel sur la question par exemple http://www.intel.com/Assets/PDF/manual/248966.pdf, ou le site de A.Fog, http://www.agner.org), ou surtout des manuels plus haut-niveau (pour les gens qui ne veulent/peuvent pas passer le temps qu'il faut à micro-optimiser leur code), les méthodologies proposées impliquent souvent de compiler à différents niveaux d'optim (-O0,..., -O3), et de prendre un jeu d'essai représentatif -- bref, de faire à la main ce que certains compilateurs (icc, et normalement gcc aussi, par exemple) savent faire depuis un moment: de la compilation guidée par profilage.
De plus, que -O3 puisse ralentir un programme, je le crois volontiers; qu'il donne des résultats faux (ou même que l'optimisation a eu un effet de bord surprenant, disons), à moins d'un bug dans le compilateur, c'est plutôt que l'utilisateur a fait des hypothèses quant au langage/à la machine qu'il utilise (je parle d'expérience).
Concernant la cohérence et l'élégance d'un langage et sa prévisibilité, je ne suis pas certain de comprendre ce que tu veux dire par là. La plupart du temps (mais clairement pas toujours), plus de concision implique plus de clarté, mais cela suppose néanmoins une compréhension du langage, et de comment il fonctionne. J'ai l'impression qu'une bonne partie des reproches faits aux langages « différents » (qu'ils soient fonctionnels, tels que ML, Haskell, LISP, déclaratifs tels PROLOG, ou bien juste « glu » genre Perl) est qu'ils ne fonctionnent pas comme leurs cousins impératifs tirés du C. J'ai exactement le même problème avec Fortran par exemple, et pourtant il n'est pas si éloigné du C que ça (en supposant qu'on passe à Fortran 90 au minimum pour avoir la forme libre de syntaxe).