Ça semble évident que si la performance est le principal critère, que tu développes une architecture adaptée. Mais dans 99% des cas, les performances sont suffisante en faisant attention à ce qu’on fait. Pour un tri, on peut choisir le tri à bulle pour des petites quantités, mais sinon un bon quicksort c’est mieux.
Mon propos était surtout sur le codage. Si l’architecture ne répond pas au besoin, de toute façon, tu es mal.
On peut optimiser ce genre de chose en C par exemple, je mets côte à côte des champs de structure proche pour le sens, voir des structure de structure. Mais on peut aussi déstructurer pour mettre côte à côte les éléments souvent accédé ensemble... ça rend la structure moins lisible, mais comme les champs on de grande chance d’être sur la même ligne de cache, on gagne en performance. On peut aussi faire du prefetch ça évite de trop déstructurer. On peut aussi éloigner les éléments accédés par des thread différents, surtout si on défini des affinités sur les CPU/cœur.
Mais rendre le code moins lisible doit toujours venir en dernier recours, après l’architecture et le choix des algorithmes ayant les complexités les plus efficaces pour le problème traité.
[^] # Re: attention au microbenchmark
Posté par Anthony Jaguenaud . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 2.
Ça semble évident que si la performance est le principal critère, que tu développes une architecture adaptée. Mais dans 99% des cas, les performances sont suffisante en faisant attention à ce qu’on fait. Pour un tri, on peut choisir le tri à bulle pour des petites quantités, mais sinon un bon quicksort c’est mieux.
Mon propos était surtout sur le codage. Si l’architecture ne répond pas au besoin, de toute façon, tu es mal.
On peut optimiser ce genre de chose en C par exemple, je mets côte à côte des champs de structure proche pour le sens, voir des structure de structure. Mais on peut aussi déstructurer pour mettre côte à côte les éléments souvent accédé ensemble... ça rend la structure moins lisible, mais comme les champs on de grande chance d’être sur la même ligne de cache, on gagne en performance. On peut aussi faire du prefetch ça évite de trop déstructurer. On peut aussi éloigner les éléments accédés par des thread différents, surtout si on défini des affinités sur les CPU/cœur.
Mais rendre le code moins lisible doit toujours venir en dernier recours, après l’architecture et le choix des algorithmes ayant les complexités les plus efficaces pour le problème traité.