iwannabeamaki (./25) :
./23 : justement, sur Ti il y a eu des fanatiques de l' "optimisation" à grand coups de remplacements d'instruction pour gagner 2 cycles, voire déroulage de boucle, et finalement ça n'a souvent pas le même ordre de grandeur d'efficacité que de repenser le problème autrement

iwannabeamaki (./25) :
./28 : oui oui, mais je ne parlais pas nécessairement de différence de niveaux de complexité (c'est effectivement pas ce qu'il y a de plus pertinent ici), à complexité "mathématique" égales il y a souvent une grosse marge à travailler avant que s'intéresser au cycles ne commence à être la meilleure solution.

.. et une bonne connaissance de l'architecture cible peut etre primordial pour le design d'un algo haut niveau... certains "details" extremement bas niveau peuvent faire choisir des algos haut niveau radicalement differents.
optimisations bas niveau != comptage de cycles.

et j'irais meme jusqu'a dire que dans pas mal de cas, c'est quelquechose qui est trop souvent ignore. justement parcequ'on rabat les oreilles de tout le monde avec "optimize algorithms before code", et que ca se fait traduire par "you don't need to care about architecture details during early algorithm-design".

rien qu'avant-hier j'ai encore eu un exemple d'une amelioration x60 en perfs, juste en prenant en compte les details de l'archi, et en produisant un algo qui, sur le papier, est sous-optimal au possible, compare a celui qui etait utilise avant...