Je suis d'accord avec toi, j'ajouterai juste qu'il ne faut pas se focaliser sur les perfs au début. C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non. Dans le second cas, il faut faire du profiling pour chercher où gagner des perf. Il vaut mieux gagner 1% de perf dans une routine utiliser 50% du temps que 30% dans une utilisé 1% du temps. Ca semble évident, mais ça ne l'ai pas lors de l'analyse.
Sur les perf, le cache joue mais pas que. J'avais benchmark une petite routine il y a une dizaine d'année sur un power PC. Au premier passage elle prenait 2μs. A partir du second 1.8μs le code était dans le cache instruction. Au 18ième passage, on passait d'un coup à 800ns, dû à la mise en route de la prédiction de branchement et au non vidage des caches.
Une chose me semble évidente, c'est qu'un compilateur fera toujours mieux que nous. Sauf peut-être à passer 2 mois sur 50 lignes de code.
[^] # Re: attention au microbenchmark
Posté par Anthony Jaguenaud . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 3.
Je suis d'accord avec toi, j'ajouterai juste qu'il ne faut pas se focaliser sur les perfs au début. C'est à la fin d'un projet qu'il faut voir si les perfs conviennent ou non. Dans le second cas, il faut faire du profiling pour chercher où gagner des perf. Il vaut mieux gagner 1% de perf dans une routine utiliser 50% du temps que 30% dans une utilisé 1% du temps. Ca semble évident, mais ça ne l'ai pas lors de l'analyse.
Sur les perf, le cache joue mais pas que. J'avais benchmark une petite routine il y a une dizaine d'année sur un power PC. Au premier passage elle prenait 2μs. A partir du second 1.8μs le code était dans le cache instruction. Au 18ième passage, on passait d'un coup à 800ns, dû à la mise en route de la prédiction de branchement et au non vidage des caches.
Une chose me semble évidente, c'est qu'un compilateur fera toujours mieux que nous. Sauf peut-être à passer 2 mois sur 50 lignes de code.