Reprise du message précédent :

La question porte sur le temps de calcul

 
Le temps d'un calcul unique, pas le temps de deux calculs séparés.
(et ça n'a strictement rien à voir avec le nombre d'instructions utilisées ou autre)
 
Si tu veux vraiment utiliser les deux cores comme Marc le fait, faut réassembler quelquepart les 2 résultats pour n'en faire qu'un.

 
Justement par rapport à comment était formulé la question, j'ai exclu la solution du FSIN sur un core et FCOS sur l'autre, car elle ne correspond pas à l'énoncé.

Où doit on s'adresser pour les réclamation ?  

Franchement je vois pas pkoi exclure cette solution, que ce soit consécutif (93+93 cycles) ou en // (93 cycles). Un calcul n'a jamais nécessite l'utilisation d'une seule instruction, ni que les les résultats (lorsqu'il y en a plusieurs) soient "regroupés". Surtout si c'est pour les séparer derrière (dans la vraie vie)...
De toute façon, un fastsincos ne prend que 99 cycles parait-il, donc exit le FSINCOS et ses 105 cycles

T'as 2 applis qui n'ont strictement rien à voir entre elles qui tournent sur 2 cœurs différents.
L'une fait un calcul de sinus alors qu'en même temps l'autre fait un calcul de cosinus.
 
Le Phenom X3 8450 a calculé un sinus et un cosinus en 44.3ns, ce qui répond précisément à la question

 
La question porte sur UN calcul. Pas deux calculs indépendants.
 
L'énoncé de la question désigne explicitement FSINCOS.

Ca peut être même une seule appli, voire une seul fonction qui prend x en entrée et renvoie y et z en sortie. Ce qu'il y a dedans (nombres d'instructions, de thread et de variables utilisées) n'est important. Mais le temps que ça a pris si, puisque c'est ce que demande la question

edit: et pourquoi FSINCOS plutôt que fastsincos ?

...sur un calcul de sinus et de cosinus
FSINCOS fait les 2 calculs. Mais du point de vue du temps d'exécution c'est pas minimal.

Tout à fait d'accord.  
Je reposerai le problème de la manière suivante:
on a une valeur x dans un registre d'un processeur st(0). On a besoin d'avoir dans le registre de ce même processeur les valeurs de sin(x) et cos(x). On cherche donc la méthode la plus rapide.
Méthode 1: fsincos 105 cycles
Méthode 2: on envoie la valeur de x dans une variable mémoire commune aux deux threads, donc au mieux situé dans le cache L3, 30 cycles minimum pour envoyer la donnée. Autant pour que le deuxième thread la rapatrie dans son registre.
Puis fsin dans un thread, fcos dans le second thread 93 cycles
Encore 60 cycles pour récupérer la donnée dans le premier thread.  
Et encore je ne parle pas de la synchronisation via mutex ou autre entre les deux threads.
 
Comme je suis généreux on peut partir du cas où la variable x est en mémoire. Avec un thread la variable pourra se retrouver dans le cache L1 (3 cycles), avec deux threads c'est forcément le cache L3, 30 cycles.
 
Donc dans tous les cas réalistes, la méthode multicoeur sera plus lente.

Enfin quand on voit les points de vues différents sur l'interprétation de  cette question on peut se poser des questions sur l'énoncé .... il y a plusieurs personnes qui ont trouvé les deux résultats mais ont choisi l'une ou l'autre selon une interprétation aléatoire basée sur une formulation qui l'est autant à mon sens . Les autres questions d'ailleurs n'ouvrent pas à polémiques car elles sont "carrées" .... le probleme c'est que préciser la question c'était orienter la réponse donc sans doute le choix a été de laisser à la libre interprétation de chacun ...

 
 
c'est ce que j'avais cru lire quelque part aussi . le fait de faire deux opérations sru deux cores rajouterait des latences  !?!

 
Ca tombe bien, FSINCOS fait justement ce calcul.
Est-ce que FCOS ou FSIN savent faire ce calcul, bizarrement j'ai pas l'impression.  

Absolument d'accord, mais LightKyle nous fait une fixette sur la présentation du résultat, je tente seulement de montrer que ça n'a pas d'importance

Parceque fastsincos prend au minimum 6 cycles de plus
( selon AMD )

 
Ca a une importance énorme.
 
Si on te demande de coder une fonction qui retourne un sin et un cos, tu codes une fonction qui retourne un sin et un cos.
Tu codes pas une fonction qui retourne un sin et une fonction qui retourne un cos.

Heureusement que dans la vraie vie on raisonne pas comme ça, sinon on ferait pas grand chose

 
Ta doc ne concerne pas les Phenom.

Pas que je sache. C'est juste que dans la vraie vie quand on a trois coeurs, on n'obtient jamais programme qui va pile trois fois plus vite. Et la méthode qui consiste à donner la première instruction au premier coeur, la seconde au deuxième et ainsi de suite, ben elle ne marche pas du tout. Du fait que les registres sont locaux à un coeur et du ralentissement dû à la gestion d'une mémoire partagée entre plusieurs coeurs au lieu d'une mémoire locale par coeur, cette méthode sera systématiquement plus lente.

C'est tjs la même chaque année

[...] temps minimum nécessaire à l'exécution [...] d'un calcul de sinus et de cosinus [...]
 
Pourquoi s'embêter avec tout ce qui n'a rien à voir avec le temps d'exécution du calcul ?

Ben non, dans tous les cas, ta fonction retourne un sin et un cos. Sauf que ta fonction à toi aura utilisé un FSINCOS, un autre aura utilisé un FCOS et un FSIN, un autre fastsincos, un autre aura utilisé encore autre chose (Carmak n'utilisait pas FSQRT pour ses racines carré).
Le principal est que la fonction fasse ce qu'on lui demande, et le plus rapidement possible.

Pour moi 99 c'est 6 de moins que 105 (FSINCOS).

elle va en faire des aigris la question 5 moi je vous le dit !
 
(m'en fout je me suis planté à la Q4   )

Combien de personnes ont répondu correctement à toutes les questions cette année?

 
Faut relire mon post là monsieur.
 
Dans un cas on a une seule fonction au final, dans l'autre cas on a deux fonctions.
Si on te spécifie explicitement de faire une seule fonction, et que tu en fournis deux... ben tu fais pas long feu au boulot.

Selon AMD

 
Sauf que la doc ne concerne pas les Phenom mais les A64 et opteron.
 
Et si tu vas par là, le fastsin et fastcos sont donnés à 88 cycles. Donc la solution avec FSIN et FCOS est fausse.

Mais pas du tout, et puis de toutes façons il n'y aura pas assez de gagnants une fois les octuples inscriptions abusives éliminées

Mais c'est toujours pas l'objet de la question du concours :
 
[...] temps minimum nécessaire à l'exécution [...] d'un calcul de sinus et de cosinus [...]

 
En tout cas dans la  doc il me semble bien qu'il est mentionné que faire des opérations sur deux cores rajoute des temps de latence non déterminés à l'avance et non déterminables. De fait dans l'énoncé le "selon AMD" pousse à comprendre que selon amd le temps d'exécution sur deux cores n'est pas précisemment déterminable du fait des latences en sus contrairement à l'exécution sur un seul core telle qu'avec la fonction fsincos !?!

 
Et tu trouves que ça veut dire que FSIN ou FCOS sait faire le calcul de sin et de cos ?
Moi je lis que FSIN sait juste faire le calcul de sin, et que FCOS sait juste faire le calcul de cos.
Bizarrement ce qui était demandé c'était le calcul de sin et de cos.

Oui oui, j'en perds mon latin, je comparais à un FSIN ou un FCOS

Ouais c'est bon on a compris bande de gagnants  
 

Ouf Marc est là  \o/
 
Je vous laisse vous démerder avec lui
Bonne nuit

Ce qui veut dire que même si la technique des FSIN et FCOS en // était refusée car ne répondant pas à la question, le fastsincos est plus rapide que le FSINCOS.
Donc, dans tous les cas le FSINCOS est une mauvaise réponse. Dommage, j'avais répondu 50ns moi aussi

Ouais parce que s'il avait écrit calcul de cosinus et de sinus on aurait trouvé.
Ca n'aurait pas été aussi marrant

 
Si je prends tes sources, t'a pas l'impression que Fsin et Fcos c'est faux, car il y a .... FastSin et FastCos, en 88 cycles chaque.

Et tu pourrais pas te taire, hein, ben pour la peine je le quote et je vais pieuter

 
J'ai répondu 50 à cause de l'énoncé, donc faut bien que je défende mon point de vue.