En fait, si j'ai bien compris, tu compares un code pas thread-safe à un code thread-safe et tu en conclue que le thread-safe va plus vite alors qu'il est en théorie plus lourd (i.e.: instruction atomiques).
Hum… Et il se passe quoi si dans ta boucle pas thread-safe qui compte le nombre d'essais tu saute un increment ? Et bien le pas thread-safe va faire un tour de boucle de plus, donc il sera plus lent (mais bon, c'est bugé).
Donc soit j'ai raté une étape, soit ton bench n'a pas de sens ?
Ce qu'il faudrait que tu fasses c'est mesurer le temps en sinle core avec la version pas thread safe et mesurer le temps en multi-core avec la version thread safe, tu auras ainsi une idée du cout de la synchronisation.
ou
Faire une version thread-safe lourde et comparer avec la thread safe légère.
Note que les instructions atomique sont optimistes (au contraire des instructions lourdes genre verrous et autre qui sont pessimistes). Cela signifie que tes instructions atomiques supposent que les choses se passent bien (et coûtent du temps quand les choses se passent mal).
Alors qu'un verrou fait l'inverse. Quand cela se passe bien, il coûte du temps, quand cela se passe mal, il coûte le même temps.
En gros, si tu as beaucoup d'accès partagés sur une variable, cela peu valoir le coup de mettre un vrai mutex. Si dans l'autre main tu as peu d'accès partagés, un atomique est génial (en utilisant au maximum les atomiqueInc/Dec contrairement au CompareAndSwap qui sont plus lent).
Dernièrement, je n'ai pas accès à ton code, mais il peut être intéressant de regarder sur quelles lignes de cache sont les données partagées. En effet, si elles sont sur des lignes identiques, un atomique sur un ligne va faire échouer toutes les variables atomiques de la ligne. Cela peut donc valoir le coup de mettre cela sur des lignes différentes.
tl;dr; Le benchmark me semble pourri par définition, il compare du code buggé a du code non bugé (ou j'ai raté une étape)
# Ai-je bien compris ?
Posté par Guillaum (site web personnel) . En réponse au journal Performances des processeurs Intel et optimisation. Évalué à 10.
En fait, si j'ai bien compris, tu compares un code pas thread-safe à un code thread-safe et tu en conclue que le thread-safe va plus vite alors qu'il est en théorie plus lourd (i.e.: instruction atomiques).
Hum… Et il se passe quoi si dans ta boucle pas thread-safe qui compte le nombre d'essais tu saute un increment ? Et bien le pas thread-safe va faire un tour de boucle de plus, donc il sera plus lent (mais bon, c'est bugé).
Donc soit j'ai raté une étape, soit ton bench n'a pas de sens ?
Ce qu'il faudrait que tu fasses c'est mesurer le temps en sinle core avec la version pas thread safe et mesurer le temps en multi-core avec la version thread safe, tu auras ainsi une idée du cout de la synchronisation.
ou
Faire une version thread-safe lourde et comparer avec la thread safe légère.
Note que les instructions atomique sont optimistes (au contraire des instructions lourdes genre verrous et autre qui sont pessimistes). Cela signifie que tes instructions atomiques supposent que les choses se passent bien (et coûtent du temps quand les choses se passent mal).
Alors qu'un verrou fait l'inverse. Quand cela se passe bien, il coûte du temps, quand cela se passe mal, il coûte le même temps.
En gros, si tu as beaucoup d'accès partagés sur une variable, cela peu valoir le coup de mettre un vrai mutex. Si dans l'autre main tu as peu d'accès partagés, un atomique est génial (en utilisant au maximum les atomiqueInc/Dec contrairement au CompareAndSwap qui sont plus lent).
Dernièrement, je n'ai pas accès à ton code, mais il peut être intéressant de regarder sur quelles lignes de cache sont les données partagées. En effet, si elles sont sur des lignes identiques, un atomique sur un ligne va faire échouer toutes les variables atomiques de la ligne. Cela peut donc valoir le coup de mettre cela sur des lignes différentes.
tl;dr; Le benchmark me semble pourri par définition, il compare du code buggé a du code non bugé (ou j'ai raté une étape)