Il serait probablement plus pertinent de commenter tous les appels à SDL_* pour benchmarker l'effet du layout mémoire.
(sinon sur ma machine, une large majorité du temps est consommé par la stack graphique).
Comme profiler pour ce genre de cas, je te conseille perf, par ex:
perf record -e cycles,cache-misses,stalled-cycles-frontend,branch-misses ./superpaflaballe
perf report
Ça permet de voir assez finement les effets des choix d'organisation de la mémoire.
Dernier point, ton benchmark étant simple, il omet une des difficultés (à mon goût) des E/S : comment stocker de manière efficaces des composants pour N entités sachant que les entités n'ont pas toutes les mêmes composants.
(dans mon cas j'ai choisis après divers test : une entité représente un index, et les composants sont stockés dans des std::vector. Ça permet d'améliorer l'utilisation du cache pour l'opération la plus couteuse : la maj des systèmes)
# Benchmark
Posté par pepp . En réponse au journal Veuillez instancier ce journal avant de le lire. Évalué à 4.
Il serait probablement plus pertinent de commenter tous les appels à SDL_* pour benchmarker l'effet du layout mémoire.
(sinon sur ma machine, une large majorité du temps est consommé par la stack graphique).
Comme profiler pour ce genre de cas, je te conseille perf, par ex:
perf record -e cycles,cache-misses,stalled-cycles-frontend,branch-misses ./superpaflaballe
perf report
Ça permet de voir assez finement les effets des choix d'organisation de la mémoire.
Dernier point, ton benchmark étant simple, il omet une des difficultés (à mon goût) des E/S : comment stocker de manière efficaces des composants pour N entités sachant que les entités n'ont pas toutes les mêmes composants.
(dans mon cas j'ai choisis après divers test : une entité représente un index, et les composants sont stockés dans des std::vector. Ça permet d'améliorer l'utilisation du cache pour l'opération la plus couteuse : la maj des systèmes)