Déjà, l'optimisation en assembleur des sources, c'est n'importe quoi. Presque plus personne ne le fait, et uniquement sur des portions de code bien précises. Pourquoi ? Simplement parce que les processeurs actuels sont devenus bien trop complexes. Pour optimiser un code, il faut tenir compte de la gestion des caches, de leur nombre et de leur taille, de la prédiction des branchements, des registres shadow (pour les processeurs Intel), ... C'est absolument impossible à faire.
D'ailleurs souvent, les bouts d'assembleurs (notamment dans le noyau) sont là uniquement parce que ce qu'ils font n'est pas écrivable en C.
Et en plus, si tu mets de l'assembleur dans tes sources, tu tues la portabilité.
DONC c'est le compilo qui doit faire tout le travail d'optimisation du code, pas le développeur (je ne parle pas d'optimisation de l'algo sous-jacent).
Ensuite, dans la plupart des cas, le goulot d'étranglement n'est pas le processeur, mais le disque, la mémoire, etc ... : Je ne pense pas que l'autovectorisation va changer grand chose aux perfs globales du système, mais uniquement à celles de certaines librairies. Et certaines distrib proposeront alors probablement un paquet par famille de proc, comme c'est déjà fait parfois.
# Relativisons un peu ...
Posté par Lucas . En réponse au journal GCC 4.0 et les distributions sources. Évalué à 10.
D'ailleurs souvent, les bouts d'assembleurs (notamment dans le noyau) sont là uniquement parce que ce qu'ils font n'est pas écrivable en C.
Et en plus, si tu mets de l'assembleur dans tes sources, tu tues la portabilité.
DONC c'est le compilo qui doit faire tout le travail d'optimisation du code, pas le développeur (je ne parle pas d'optimisation de l'algo sous-jacent).
Ensuite, dans la plupart des cas, le goulot d'étranglement n'est pas le processeur, mais le disque, la mémoire, etc ... : Je ne pense pas que l'autovectorisation va changer grand chose aux perfs globales du système, mais uniquement à celles de certaines librairies. Et certaines distrib proposeront alors probablement un paquet par famille de proc, comme c'est déjà fait parfois.