Aller au contenu

successeur pr SUPER PI en Multi threaded


james_patageul

Messages recommandés

  • Réponses 54
  • Créé
  • Dernière réponse
euh ils gère les CPUs physiques

donc si tu fais ça les threads ne sont pas vraiment calculés... tu fais surement buggé le soft

je viens de test en fait il fait le calcul différemment, en enchainant les calculs et pas en traitant en parallèle ou un truc comme ça

regarde donc le log un peu

et tu m'appelles quand tu fais deux fois le même score d'affilée à S-Pi ^^'

heu...

il divise les calcul a effectué par le nombre de thread

il enchaine pas les calcul il attribut un temps d'execution a chaque thread (sémaphore ...)

si t'avais 2core et 2 thread 

chaque thread s'execute "pleinement"  (il se mange des temps de repos obligatoirement pour le systeme et les autres appli...)

mais c'est la solution optimale normalement

donc non je fais pas buggué le logiciel

et non on fait jamais le meme temps a S-pi pour la meme raison que pré cité a savoir le temps d'execution qui varie

mais ce que je remet en cause c'est que logiquement plus y'a de thread , plus tu met de temps a les executer puisque tu impliques des temps de repos plus nombreux, plus de gestions des thread etc... or on voit qu'avec 10threads je met moins de temps qu'avec 6

ce qui est tout a fais illogique

voilà

Lien vers le commentaire
Partager sur d’autres sites

euh ils gère les CPUs physiques

donc si tu fais ça les threads ne sont pas vraiment calculés... tu fais surement buggé le soft

je viens de test en fait il fait le calcul différemment, en enchainant les calculs et pas en traitant en parallèle ou un truc comme ça

regarde donc le log un peu

et tu m'appelles quand tu fais deux fois le même score d'affilée à S-Pi ^^'

heu...

il divise les calcul a effectué par le nombre de thread

il enchaine pas les calcul il attribut un temps d'execution a chaque thread (sémaphore ...)

si t'avais 2core et 2 thread 

chaque thread s'execute "pleinement"  (il se mange des temps de repos obligatoirement pour le systeme et les autres appli...)

mais c'est la solution optimale normalement

donc non je fais pas buggué le logiciel

et non on fait jamais le meme temps a S-pi pour la meme raison que pré cité a savoir le temps d'execution qui varie

mais ce que je remet en cause c'est que logiquement plus y'a de thread , plus tu met de temps a les executer puisque tu impliques des temps de repos plus nombreux, plus de gestions des thread etc... or on voit qu'avec 10threads je met moins de temps qu'avec 6

ce qui est tout a fais illogique

voilà

Gros +1 ! :transpi:

Alala les sémaphores, ca me rappelle mes cours de système :transpi:

Lien vers le commentaire
Partager sur d’autres sites

wPrime2717.gif

Je trouve que c'est un beau score sachant que c'est sur une oc totalement stable qui endure des tests d'une heure en burn et qui est mon environnement de travail quotidien.

Je suis surpris de voir les résultats des Opterons que je pensais moins performants que les A64 X2. De même j'ai vu dans ce topic un A64 X2 d'un modèle en dessous de mon 4200+ qui obtient un meilleur résultat avec une fréquence inférieure à la mienne !! ça vient sûrement du L2.

Enfin, voilà, c'est mon résultat à moi.

Chris.

Lien vers le commentaire
Partager sur d’autres sites

euh ils gère les CPUs physiques

donc si tu fais ça les threads ne sont pas vraiment calculés... tu fais surement buggé le soft

je viens de test en fait il fait le calcul différemment, en enchainant les calculs et pas en traitant en parallèle ou un truc comme ça

regarde donc le log un peu

et tu m'appelles quand tu fais deux fois le même score d'affilée à S-Pi ^^'

heu...

il divise les calcul a effectué par le nombre de thread

il enchaine pas les calcul il attribut un temps d'execution a chaque thread (sémaphore ...)

si t'avais 2core et 2 thread

chaque thread s'execute "pleinement" (il se mange des temps de repos obligatoirement pour le systeme et les autres appli...)

mais c'est la solution optimale normalement

donc non je fais pas buggué le logiciel

et non on fait jamais le meme temps a S-pi pour la meme raison que pré cité a savoir le temps d'execution qui varie

mais ce que je remet en cause c'est que logiquement plus y'a de thread , plus tu met de temps a les executer puisque tu impliques des temps de repos plus nombreux, plus de gestions des thread etc... or on voit qu'avec 10threads je met moins de temps qu'avec 6

ce qui est tout a fais illogique

voilà

Gros +1 ! :mdr:

Alala les sémaphores, ca me rappelle mes cours de système :roll:

Merci de cette réponse constructive :mdr:

Cela mérite que l'on creuse la question, j'irais faire un post sur leurs forum pour en savoir la raison exacte

Enfin.... celle que les devs me donneront :zarb:

Néanmoins ce bench est quand même reconnu par beaucoup de monde, ce qui ne constitue pas une vérité en soi biensur :mdr:

wPrime2717.gif

Je trouve que c'est un beau score sachant que c'est sur une oc totalement stable qui endure des tests d'une heure en burn et qui est mon environnement de travail quotidien.

Je suis surpris de voir les résultats des Opterons que je pensais moins performants que les A64 X2. De même j'ai vu dans ce topic un A64 X2 d'un modèle en dessous de mon 4200+ qui obtient un meilleur résultat avec une fréquence inférieure à la mienne !! ça vient sûrement du L2.

Enfin, voilà, c'est mon résultat à moi.

Chris.

Les timings RAM, le FSB, le cache etc tout rentre en jeu pour ce type de bench, à l'instar de S-PI

Sinon concernant les Opterons 1xx ou 2xx (comme le mien par exemple) se sont des X2 version serveur, donc c'est normal qu'ils aient de bons résultats.

D'autant plus que ces processeurs sont 99% beaucoup plus facile à faire grimper en fréquence que leurs homologue X2

Contrairement au C2D qui on l'air de tous bien prendre en OC

Après ça reste de l'OC, la roulette russe numérique ^^

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.


×
×
  • Créer...