« Tous ça, c'était surtout utile avant, quand les compilos étaient cons comme des balais. Aujourd'hui, ils optimisent tellement le code qu'il vaut mieux les laisser faire. »
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)
[^] # Re: Bravo mais..
Posté par lasher . En réponse à la dépêche La quintessence des algorithmes bit à bit. Évalué à 3.
Ben tout dépend de quel compilateur on parle. :-)
Au risque de me répéter vis à vis de ce que j'ai pu dire dans d'autres réactions, gcc n'est pas (encore) le plus optimisant des compilos, et on peut clairement faire mieux à la main, si on a le temps et la volonté d'apprendre l'assembleur de la machine cible. Alors que pour faire mieux à la main que certains autres compilateurs, il faut se lever très tôt.
« Enfin, un argument sensé que j'ai lu je ne sais plus où:
avec des "hacks" comme ça, tu gagnes un peu, mais ce peu va se réduire avec les années (progrès du compilo/métériel). Par contre, tu perds en lisibilité, et pour toujours... »
C'est vrai. C'est pour ça que les deux grandes règles de l'optimisation sont :
1°) N'optimise pas.
2°) (pour experts seulement) N'optimise pas encore.
L'optimisation vient en toute fin de développement, lorsque ton code fonctionne déjà bien, sans bug, etc.
Les manipulations de bits, en règle générale, sont tellement dépendants de la machine qu'il est sans doute plus « simple » si on connaît l'architecture cible d'éditer le code assembleur et de les faire soit-même (ou bien d'insérer le code ASM dans le source C, mais non seulement c'est crade, mais en plus les options d'optimisation sont désactivées automatiquement dans certains compilateurs quand ils détectent ce genre de magouille) :-)