44.3ns ? C'est faux ...

44.3ns ? C'est faux ... - Carte mère - Hardware

Marsh Posté le 19-05-2008 à 21:05:03    

fsin et fcos sur 2 cores au lieu du fsincos ? soit ... glissons ...
 
La question demandait le temps minimum.
 
Or que ce soit avec fsin, fcos ou fsincos le temps de calcul fluctue en fonction de l'angle demandé.  Et dans le cas où l'angle en question est 0, le temps est radicalement inférieur à celui nécessaire avec les autres paramètres (De 50% à 66% en fonction de l'algorithme implémenté dans le cpu. ie: dans les Core2 c'est 66%).
 
Faites le test (mesurez) vous verrez ^_^
 
Si des lecteurs ici savent encore ce qu'est l'"assembleur" la mesure est facile grâce à rdtsc
 
Une approximation est également possible avec un nombre très élevé d'itérations du calcul mesuré avec une horloge RT. (Il ne faut pas oublier de soustraire le temps nécessaire à la boucle et à l'init de la commande bien sûr.
 
Mes 2 cents...

Reply

Marsh Posté le 19-05-2008 à 21:05:03   

Reply

Marsh Posté le 21-05-2008 à 22:20:19    

question : tu te drogues ? :sarcastic:

Reply

Marsh Posté le 21-05-2008 à 22:22:31    

:ouch: Moi qui pensais qu'Einstein était mort....

Reply

Marsh Posté le 21-05-2008 à 22:26:55    

fais tourner tonton... [:aras qui rit]

Reply

Marsh Posté le 21-05-2008 à 22:42:09    

Je comprends rien a ton truc mais tu m'impressionne.. (En même temps vu que j'y comprends rien ça pourrait être nimporte quoi :pt1cable: )
 
Bon courage en tout cas pour ta quete de verité et de reconnaissance ;)  
http://www.hardware.fr/news/lire/18-05-2008/
 
Pourquoi tu vises les 200?
 
Demande 1500 direct  :D  
http://www.hardware.fr/news/lire/19-05-2008/
 
Et file moi 10% si ca marche  :whistle:


Message édité par polarkraken le 21-05-2008 à 22:45:04
Reply

Marsh Posté le 21-05-2008 à 22:46:01    

topic sous ricard a haute dose....:D


Message édité par Cizia le 21-05-2008 à 22:46:23

---------------

Reply

Marsh Posté le 21-05-2008 à 22:47:44    

Drapal :D pour le garder sous le coude en cas de baisse de moral :D

Reply

Marsh Posté le 21-05-2008 à 22:47:59    

je sais pas mai en 8 messages il arrive avec du bagage celui-là!

Reply

Marsh Posté le 21-05-2008 à 22:53:17    

Reply

Marsh Posté le 21-05-2008 à 22:54:37    

arretez c'est obiwan qui débarque sur le fofo !

Reply

Marsh Posté le 21-05-2008 à 22:54:37   

Reply

Marsh Posté le 21-05-2008 à 22:55:49    

orionx31 a écrit :

je sais pas mai en 8 messages il arrive avec du bagage celui-là!


 
Inscrit en 2005.. C'est un lurker de luxe!!

Reply

Marsh Posté le 21-05-2008 à 23:01:05    

lurker ???

Reply

Marsh Posté le 21-05-2008 à 23:02:33    

Dans la culture internet, un lurker est un individu qui lit les discussions sur un forum Internet, newsgroup, messagerie instantanée ou tout autre espace d'échange mais sans y participer.
 
http://fr.wikipedia.org/wiki/Lurker


Message édité par polarkraken le 21-05-2008 à 23:02:49
Reply

Marsh Posté le 21-05-2008 à 23:05:12    

okay, je m'endormirais moins teubé ce soir, non mai plus sérieusmeent vous croyez qu'il veut qu'on réponde à sa question?

Reply

Marsh Posté le 21-05-2008 à 23:07:00    

je pense surtout que demain au reveil et donc la "gueule dans le cul",il ce souviendra jamais avoir posté...:D


Message édité par Cizia le 21-05-2008 à 23:07:58

---------------

Reply

Marsh Posté le 21-05-2008 à 23:14:39    

Ca à l'air super intéressant ... mais on a pas le début :(

Reply

Marsh Posté le 21-05-2008 à 23:18:19    

Hurricane_san a écrit :

fsin et fcos sur 2 cores au lieu du fsincos ? soit ... glissons ...
 
La question demandait le temps minimum.
 
Or que ce soit avec fsin, fcos ou fsincos le temps de calcul fluctue en fonction de l'angle demandé.  Et dans le cas où l'angle en question est 0, le temps est radicalement inférieur à celui nécessaire avec les autres paramètres (De 50% à 66% en fonction de l'algorithme implémenté dans le cpu. ie: dans les Core2 c'est 66%).
 
Faites le test (mesurez) vous verrez ^_^
 
Si des lecteurs ici savent encore ce qu'est l'"assembleur" la mesure est facile grâce à rdtsc
 
Une approximation est également possible avec un nombre très élevé d'itérations du calcul mesuré avec une horloge RT. (Il ne faut pas oublier de soustraire le temps nécessaire à la boucle et à l'init de la commande bien sûr.
 
Mes 2 cents...


 

outre que ton post ressemble a une réponse d'un thread imaginaire qui existerait dans un monde parallèle proche qui s'appelle la catégorie programmation du forum...
 
en termes de coût d'une instruction (débit et latence) on parle en cycle d'horloge cpu (puisque la fréquence est variable suivant les modèles), et les mesures d'une instruction se font bien sûr en ayant éliminé les dépendances mémoires (pour éviter de mesurer les pénalitées de cache miss et les page faults).

 
----
 
edit: oki j'avais pas vu que tu parlais d'une question du jeu :D (j'avais même pas été voir)
en fait t'as pas complètement tord :D


Message édité par bjone le 21-05-2008 à 23:24:30
Reply

Marsh Posté le 21-05-2008 à 23:20:10    

un courageux....

Reply

Marsh Posté le 21-05-2008 à 23:21:54    

d'ailleurs:
 

Citation :


Sachant toutefois que l’on dispose de trois core, le plus rapide pour effectuer un tel calcul est de se servir de deux core en parallèles, l’un pour FSIN, l’autre pour FCOS. L’exécution prend donc 93 cycles, soit 44.3ns à une fréquence de 2.1 GHz


 
c'est ptet un peu tiré par les cheveux :D
dans la pratique pour rentabiliser l'overhead de la création de thread (et de la boucle de contrôle) t'as intérêt a avoir a avoir de la trigo a faire a gogo :D
ou alors tu fais un loop unrolling de 900000 fsin/fcos :D

Message cité 1 fois
Message édité par bjone le 21-05-2008 à 23:26:21
Reply

Marsh Posté le 21-05-2008 à 23:31:57    

ptain ils sont 2 !

Message cité 2 fois
Message édité par orionx31 le 21-05-2008 à 23:32:09
Reply

Marsh Posté le 21-05-2008 à 23:33:17    

orionx31 a écrit :

ptain ils sont 2 !


 
Bjone c'est un classique par contre..

Message cité 1 fois
Message édité par polarkraken le 21-05-2008 à 23:33:35
Reply

Marsh Posté le 21-05-2008 à 23:34:33    

c'est pas un modo qu'il faut ici,mais un prêtre-exorcistes....:D


Message édité par Cizia le 21-05-2008 à 23:34:50

---------------

Reply

Marsh Posté le 21-05-2008 à 23:39:29    

entre ça et le san trop lent ça va loin...
 
je laisse ouvert pour le fun.


Message édité par DraX le 21-05-2008 à 23:39:58

---------------
| Un malentendu du cul | boum boum ! | La roulette
Reply

Marsh Posté le 21-05-2008 à 23:48:02    

orionx31 a écrit :

ptain ils sont 2 !


 
 
ptdr

Reply

Marsh Posté le 22-05-2008 à 00:14:28    

Jean claude vandamme, sort de ce corps  :D


Message édité par manatime le 22-05-2008 à 00:14:43
Reply

Marsh Posté le 22-05-2008 à 00:28:22    

bjone a écrit :

d'ailleurs:

 
Citation :


Sachant toutefois que l’on dispose de trois core, le plus rapide pour effectuer un tel calcul est de se servir de deux core en parallèles, l’un pour FSIN, l’autre pour FCOS. L’exécution prend donc 93 cycles, soit 44.3ns à une fréquence de 2.1 GHz

 

c'est ptet un peu tiré par les cheveux :D
dans la pratique pour rentabiliser l'overhead de la création de thread (et de la boucle de contrôle) t'as intérêt a avoir a avoir de la trigo a faire a gogo :D
ou alors tu fais un loop unrolling de 900000 fsin/fcos :D

 

Thread ? Quelle thread ? Ah la solution donnée ? C'est vrai qu'utiliser 2 threads sur 2 cpus pour obtenir le résultat est idiot dans la pratique.  Mais aussi stupide/ambigü/ridicule que ce soit, ce n'est pas inexact vu que la question demandais le temps minimum, pas de savoir si ça avait un sens.  Evidemment la majorité des techies ont donné la solution technique par réflexe ^^ (y compris votre serviteur).

 

Par contre là où ça ne va pas c'est le temps d'exécution du fsin/fcos pour la valeur particulière 0

 

De tête, une mesure devrait être:
fclex
fldz ; ou fld variable_dans_un_double pour comparer la différence de vitesse si on utilise une autre valeur que zéro
rdtsc
mov ecx,eax
mov ebx,edx
fsin
fwait
rdtsc
sub eax,ecx
sbb edx,ebx
fst resultat_dans_un_double ; fstp si fsincos utilisé au lieu de fsin ou fcos

 

Il faut bien entendu retirer à EDX:EAX (64 bits) l'overhead des 2 mov R32,R32 et du fwait
Ah, et vu que les AMDs ont tendance à être nazes en ce qui concerne le TSC (valeurs différentes selon les cores et selon la fréquence du cpu) La mesure a intérêt à être prise plusieurs fois.  La bonne étant bien entendu la réponse minimum.

 

La solution plus "simple" avec une boucle consiste simplement à faire cent millions de calculs de sinus ou cosinus, de préférence par :

 

; Mesurer la clock RT du start
mov ecx,100000000
loop:
sub ecx,1 ; et non, un dec ecx n'est plus optimal depuis quelques générations de cpu
fldz
fsin
fst
jnz loop
; Mesurer la clock RT du stop
; faire la différence stop-start

 

et calculer la différence de temps sur une horloge à la milliseconde ou moins.  Une approximation de l'overhead de la boucle peut être calculé en refaisant l'opération sans les opérations fpu (en remplaçant les 3 opérations "f" par un nop par exemple).  Encore qu'il ne doit pas être terrible vu que le tout devrait tenir dans une ligne de cache L1 (si aligné 32) et que le pipeline est suffisement bien exploité. (Un loop unrolling n'est pas intéressant vu tout les cache-miss qu'il génèrerait, bien plus coûteux qu'une petite boucle dans une ligne de cache)

 

L'expérience devrait être "facile" à faire pour au moins un pourcentage des utilisateurs du forum.

 

Sinon, pour répondre aux autres : ce n'est pas une quête de vérité.  C'est juste un fait.  Et quand on fait un questionnaire sur un site orienté hardware il faut s'attendre à ce que des types cherchent très loin la solution et laissent de coté les solutions "faciles" mais pour eux inexactes. ^^ (Et je me fiche des prix du concours :p )
J'imagine qu'il y a plus d'un "motivé" sur ce site ^^;;

 

C'est la première fois que je vois le terme "lurker" utilisé ^^  En gros c'est l'opposé de Troll ... donc flatteur ^^

 

Message cité 1 fois
Message édité par Hurricane_san le 22-05-2008 à 00:31:18
Reply

Marsh Posté le 22-05-2008 à 00:36:10    

en plus il dort pas la nuit  :cry:, et il dis des mots en triple exemplaire :
 
 

Citation :

Mais aussi stupide/ambigü/ridicule que ce soit

Reply

Marsh Posté le 22-05-2008 à 01:01:08    

polarkraken a écrit :


 
Bjone c'est un classique par contre..


:D

Reply

Marsh Posté le 22-05-2008 à 01:05:01    

Hurricane_san a écrit :


 
Thread ? Quelle thread ? Ah la solution donnée ? C'est vrai qu'utiliser 2 threads sur 2 cpus pour obtenir le résultat est idiot dans la pratique.  Mais aussi stupide/ambigü/ridicule que ce soit, ce n'est pas inexact vu que la question demandais le temps minimum, pas de savoir si ça avait un sens.  Evidemment la majorité des techies ont donné la solution technique par réflexe ^^ (y compris votre serviteur).
 
Par contre là où ça ne va pas c'est le temps d'exécution du fsin/fcos pour la valeur particulière 0
 
De tête, une mesure devrait être:
fclex
fldz ; ou fld variable_dans_un_double pour comparer la différence de vitesse si on utilise une autre valeur que zéro
rdtsc
mov ecx,eax
mov ebx,edx
fsin
fwait
rdtsc
sub eax,ecx
sbb edx,ebx
fst resultat_dans_un_double ; fstp si fsincos utilisé au lieu de fsin ou fcos
 
Il faut bien entendu retirer à EDX:EAX (64 bits) l'overhead des 2 mov R32,R32 et du fwait
Ah, et vu que les AMDs ont tendance à être nazes en ce qui concerne le TSC (valeurs différentes selon les cores et selon la fréquence du cpu) La mesure a intérêt à être prise plusieurs fois.  La bonne étant bien entendu la réponse minimum.
 
La solution plus "simple" avec une boucle consiste simplement à faire cent millions de calculs de sinus ou cosinus, de préférence par :
 
; Mesurer la clock RT du start
mov ecx,100000000
loop:
sub ecx,1 ; et non, un dec ecx n'est plus optimal depuis quelques générations de cpu
fldz
fsin
fst
jnz loop
; Mesurer la clock RT du stop
; faire la différence stop-start
 
et calculer la différence de temps sur une horloge à la milliseconde ou moins.  Une approximation de l'overhead de la boucle peut être calculé en refaisant l'opération sans les opérations fpu (en remplaçant les 3 opérations "f" par un nop par exemple).  Encore qu'il ne doit pas être terrible vu que le tout devrait tenir dans une ligne de cache L1 (si aligné 32) et que le pipeline est suffisement bien exploité. (Un loop unrolling n'est pas intéressant vu tout les cache-miss qu'il génèrerait, bien plus coûteux qu'une petite boucle dans une ligne de cache)
 
L'expérience devrait être "facile" à faire pour au moins un pourcentage des utilisateurs du forum.
 
Sinon, pour répondre aux autres : ce n'est pas une quête de vérité.  C'est juste un fait.  Et quand on fait un questionnaire sur un site orienté hardware il faut s'attendre à ce que des types cherchent très loin la solution et laissent de coté les solutions "faciles" mais pour eux inexactes. ^^ (Et je me fiche des prix du concours :p )
J'imagine qu'il y a plus d'un "motivé" sur ce site ^^;;
 
C'est la première fois que je vois le terme "lurker" utilisé ^^  En gros c'est l'opposé de Troll ... donc flatteur ^^
 


 
en même temps avec un loop unrolling d'instructions trigo t'as suffisamment de temps passé dans le fpu pour masquer le remplissage des lignes de cache  [:ddt]

Message cité 1 fois
Message édité par bjone le 22-05-2008 à 01:05:28
Reply

Marsh Posté le 22-05-2008 à 09:12:39    

bjone a écrit :


 
en même temps avec un loop unrolling d'instructions trigo t'as suffisamment de temps passé dans le fpu pour masquer le remplissage des lignes de cache  [:ddt]


 
 
purée c'est exactement ce que je voulais dire...
 
 
 :D
 
edit : arf je viens de piger de quoi il parle en fait  :sol:


Message édité par monsieurtof le 22-05-2008 à 09:17:31
Reply

Marsh Posté le 22-05-2008 à 10:14:43    

Hurricane_san a écrit :

fsin et fcos sur 2 cores au lieu du fsincos ? soit ... glissons ...
 
La question demandait le temps minimum.
 
Or que ce soit avec fsin, fcos ou fsincos le temps de calcul fluctue en fonction de l'angle demandé.  Et dans le cas où l'angle en question est 0, le temps est radicalement inférieur à celui nécessaire avec les autres paramètres (De 50% à 66% en fonction de l'algorithme implémenté dans le cpu. ie: dans les Core2 c'est 66%).
 
Faites le test (mesurez) vous verrez ^_^
 
Si des lecteurs ici savent encore ce qu'est l'"assembleur" la mesure est facile grâce à rdtsc
 
Une approximation est également possible avec un nombre très élevé d'itérations du calcul mesuré avec une horloge RT. (Il ne faut pas oublier de soustraire le temps nécessaire à la boucle et à l'init de la commande bien sûr.
 
Mes 2 cents...

Si tel est le cas, ce n'est pas documenté par AMD, donc impossible d'avoir une réponse pour le concours.

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed