Reprise du message précédent :

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

Je suppose que pour la réponse 1, 5€ est aussi accepté ?
Cf de lien que Zenli a donné : https://secure.ldlc.com/-com-/pages [...] l?q=830084
 
Un avis ? Oui non non oui ?

Non

 
Et en quoi les infos d'une page du site de LDLC sont moins bonnes que les infos d'une autre page du site de LDLC ?
Si on part de ce principe là, on peut se fier à aucune page du site.

 
J'ai répondu 7€, mais si c'est marqué sur le site de LDLC, la réponse 5€ doit être acceptée.

 
AMD ne précise ni sur quel CPU ces données sont valables, ni à quoi correspond ce nombre de cycles. Ce n'est pas forcément une latence (temps d'une exécution seule), mais certainement un temps d'exécution moyen pour un grand nombre d'exécution enchainées (puisque cette valeur est plus faible, il est logique qu'ils la mettent en avant)

9a aussi ça revient chaque année, le site LDLC qui est pas clair/se contredit, si Marc est de bonne humeur il acceptera aussi 5€

 
cf plus haut

 
C'est marrant ça, quand on ne parlait que du Fastsincos, c'était valable. Maintenant qu'on parle du Fastsin et du Fastcos, ce n'est plus valable

Bonjour,
La réponse 5 est probablement fausse puisque AMD annonce clairement que lorsque des instructions sont executées parrallelement, des cycles supplémentaires sont nécessaires par rapport aux nombre de cycles "statiques" annoncés dans leurs tableaux.
 
Par exemple, une documentation d'AMD: http://www.amd.com/us-en/assets/co [...] /22007.pdf  
 
Page 281: It is the best case scenario which assumes no other instructions executing in the processor. The following format is used to describe the static execution.  
 
Ce qui induit que l'execution de FSIN(x) et FCOS(x) sur deux cores en même temps est probablement superieur en temps et ne corresponds absolument pas eu temps "statique" annoncés. Il est même fortement probable que l'instruction FSINCOS(x) soit plus rapide.  
 
Finalement, je ne sais pas ce qui est le plus rapide (entre FSIN+FCOS ou FSINCOS), mais ce qui est sur c'est que FSIN+FCOS n'est pas égal au 93 cycles statiques.
 
Sébastien.
(divxdede,nephri)

 
je n'ai jamais dit que le fastsincos était valable, c'est pareil, on n'a pas les données.

 
D'autres l'ont dit à ta place, c'était un de leurs arguments sortis de nul part.

 
déjà dit : FSIN et FCOS ne font pas d'accès mémoire, donc il n'y a aucune interaction entre les cores

En même temps, la question était "selon AMD".
 
Et donc selon AMD, deux instructions executées parrallement prends plus de cycles que le nombre de cycle statique.
Ils ne disent rien sur l'execution particulière FSIN // FCOS.
 
AMD ne disant pas explicitement (et donc ne garantissant pas) que ces deux opérations n'ajoutent pas de coût suplémentaire,  
on ne peut que considerer leur remarque générale et on doit partir du principe que FSIN // FCOS à un temps de latence > 93 cycles.
 
Je sais qu'a ce stade, ce n'est plus une reflexion "technique" mais plutôt "literaire" sur l'ennoncé.
 

 
Et d'où provient les données en radian pour réussir à sortir un résultat??? Même si la majorité des instructions n'accède pas à la mémoire directement pour faire leur calcul, il faut charger les régistres qu'ils utilisent avec les bonnes donnée et ces données proviennent forcément de la mémoire.
 
La communication entre core est exécrablement lente comparé à la communication dans le même core. Lorsqu'on utilise plusieurs cores on le fait sur des calculs indépendant, de cette façon pas besoin de transféré des données entre les cores, sinon on perd beaucoup de perfo.
 
La question 5 n'était pas assez claire, et une question qui laisse place à autant d'interprétation n'est jamais bon dans un concours!
 
Je vote pour que cette question soit tout bonnement annulé  

La question porte sur le calcul proprement dit, pas sur le chargement des données.
C'est forcément un cas purement théorique, la pratique est largement plus compliquée, et donc ne peut pas faire l'objet d'une question de concours.
Dans un cas pratique, le temps d'exécution n'aurait certainement aucune importance tant il est faible par rapport à la lenteur des E/S en général (un programme est toujours destiné à avoir un impact sur un périphérique : écran, disque, ...). Là où il est important, c'est lorsqu'il s'agit de faire beaucoup de calculs, et la le problème est différent.

J'ai quand même hésité à cause de la formulation de la question, mais si elle avait été plus explicite, elle aurait été beaucoup plus simple.
Au final, j'ai choisi la solution avec deux cores, car FSINCOS était trop simple : il y a 2 ans, le piège était sur la différence de la latence sur les différents P4, là il en fallait un autre.

Ce que AMD dit dans ce qui est en gras est valable également pour les monocore ainsi que FSINCOS.
Donc on se place dans le cas "idéal".
 
Au fait, HFR a publié les réponses :

Bien qu'ayant défendu la thèse du FCOS et FSIN en //, j'avais répondu 50ns (FSINCOS). J'ai donc perdu

Perso pour la Q4 je me suis pas fait chier, j'ai fait une recherche "Topic Unique" dans chaque sous catégorie de "Hardware" et en 2 minutes j'ai trouvé les 16 topics qui avaient plus de 500'000 "vues"

Edit: Bien qu'ayant vu les fonctions FCOS et FSIN dans la doc, j'ai répondu 50ns pour la Q5.
Je me doutais bien qu'il y avait un truc tordu avec l'utilisation de plusieurs cores en // mais finalement je me suis dit autant ne pas se prendre la tête pendant 10 ans avec ce concours (grave erreur !!) étant donné que j'avais trouvé les autres réponses assez facilement.
J'ai même cru pendant un moment que l'exécution de FCOS et de FSIN auraient pu être partagé sur les 3 cores en même temps ce qui aurait donné un temps d'exécution de folie

Sinon je suis plutôt d'accord avec ceux qui ont trouvé 44.3ns puisqu'on demande clairement et simplement le temps de calcul le plus rapide de cos(x) et de sin(x). En aucun cas, la mémoire et autres registres n'interviennent dans cette affaire. Pour moi il est clair que la bonne réponse est celle donnée par M.arc puisque c'est l'utilisation en // de FCOS et de FSIN qui au final exécute le code le plus rapidement (on se contrefiche de ce qu'il y a avant et après l'exécution de ce(s) calcul(s) !)

Sauf que l'énnoncé ne demande pas uniquement le "cas idéal", il demande également ce que "dit AMD".
Or AMD, ne nous dit rien sur l'execution FSIN//FCOS mis à part que d'une façon générale deux instructions // prennent chacune respectivement plus de temps que leur latences statiques.
 
Du coup on ne peut que considerer ce qu'AMD donne pour répondre à la question, c'est à dire execution sequentielle avec 2 cores completement en idle. Dans ce cas on peut utiliser les temps de latences statiques et FSINCOS devient plus interressant que FSIN+FCOS.
 
Bref, tout ceci est un merveilleux mélange d'interpretation.
En tout cas, je me suis planté également, et je félicite malgrés tout ceux qui ont bien répondus.

AMD donne le nombre de cycles d'une instructions sur 1 core, dans le cas idéal (cad sans "perturbation" sur ce même core). Les autres cores (s'il y en a) n'intervienne pas et n'ont pas d'influence sur les temps d'exécution des instructions.

Non, non, non et non. Il ne faut pas confondre la parallélisation d'instructions dans une unité et la parallélisation d'instructions entre des cœurs.
 
La question a d'ailleurs déjà été débattue plus haut avec la doc du Phenom (car là tu as dépoussiéré la doc de l'Athlon... de 2002 Alors pour parler de cœur avec ça c'est un peu limite).
 
Dans tous les cas, la doc parle de parallélisation d'instructions au sein d'un même cœur, ce qui est rendu possible par l'architecture superscalaire du cœur.
En revanche, l'exécution d'une instruction en virgule flottante sur un cœur n'a aucune influence sur l'unité de calcul en virgule flottante d'un autre cœur (encore heureux).
 
Donc si tu fais un FSIN sur un cœur et un FCOS sur un autre cœur, pas d'interaction de l'un sur l'autre, tu peux prendre le cas optimal pour chacun d'eux, et les instructions s'exécutent rigoureusement en même temps.
 
Par contre effectivement, si tu faisais les 2 instructions sur un seul cœur, par le jeu du pipeline elles pourraient se retrouver à être exécutées simultanément, certes, mais de toute façon décalées dans le temps, et en plus il faudrait rajouter des latences par-ci par-là pour gérer l'encombrement des sous-unités. Là oui, c'est ingérable, mais ça tombe bien, c'est pas le cas qui nous intéresse pour le concours.

 
Cette explication me convient assez bien.
Effectivement, je n'avais pas pensé que la remarque d'AMD pouvait concerner les pipelines et non les coeurs, j'accepte mieux mon erreur.
 
PS: concernant la documentation, c'est celle que j'ai retrouvé en l'état, mais celle de la 10ème archi possèdait la même remarque.
 
 

Je sais bien, 'suffit de voir le lien que j'ai donné dans mon post quand je disais qu'on en avait déjà parlé : http://forum.hardware.fr/hfr/Discu [...] #t14898903

Oué enfin en relisant le contenu du concours, ça ne me paraît toujours pas clair
Pour moi faire fsin et fcos sur un core chacun ça revient à faire deux opérations/calculs (synonymes) en parallèle
Dans l'énoncé on nous demande un calcul de sin et de cos
L'idéal aurait été un calcul de sin puis de cos, ou au moins inverser sin et cos dans l'énoncé
La on se demande si tout n'a pas été mis en oeuvre pour nous planter
Même si j'avais eu faux au 4 précédentes j'aurais eu les nerfs de me planter sur cette question à cause de l'énoncé
J'arrive bientôt à la limite de smileys alors j'arrête  

Ca c'est incalculable comme je l'ai expliqué 3 ou 4 posts plus haut...

Chapeau à ceux qui ont trouvé la dernière question.
 
Perso j'ai tout sauf celle là, mais bon j'avais déjà gagné l'année dernière, chacun son tour

 
Comment tu peux être dans le même calcul là.
Ca m'intrigue.
Un calcul c'est un ensemble d'instructions liées entre elles, mais là j'ai du mal à voir le lien.

Très honnetement, je trouve les arguments des 2 réponses très convaincants.
Peut être serait-il plus équitable d'accepter les 2 réponses (44.3ns et 50ns) étant donné que 2 interprétations parraissants correct peuvent être faite de la question.

Je sais bien que Marc fait toujours une question difficile avec parfois une interprétation délicate, mais, là, je trouve vraiment les arguments des 2 "camps" défendables...

Etant dans le camps de ceux qui ont perdu juste à cause de la 5eme question je plussoie complètement le fait d'accepter les 2 réponses

 
J'espère que les personnes qui ont inondé la boîte mail de Marc avec des réclamations l'ont fait avec les forme pour ne pas le froisser.    
 
Personnellement, j'aimerais que la réponse "50" soit acceptée, même si pour le coup les rares qui avaient oser le "44.3" sentiraient vraiment la différence de chance (je pense qu'ils auraient presque tous gagné quelque chose).

Et dans ce cas, plein de gens auraient répondus 88.6ns, parce qu'il aurait fallu sortir d'abord le sin, puis le cos, soit 93+93 cycles

Mais dans la doc, et donc "SELON Amd", il est quand même mentionné que faire des ( ici deux)  opérations en parallèle rajoutait de la latence et ceci de façon non déterminable donc un tel résultat , même théorique , ne peut être chiffré selon les propos d'amd non ?!? alors que les fonctions séparés fsin , fos et fsincos avec une seule exécution permettent eux d'établir un résultat théorique non ?!? enfin c'est mon interprétation mais je suis pas expert en cpu ...

Moi je dis que ça en ayant lu tout le topic :
 
Je suis un membre HFR depuis longue date, je fait ce concours sans jamais avoir gagné pour 1 question à chaque fois.
 
Le temps passer pour rechercher toutes les bonnes réponses est non quantifiable mais ce que je n'aprécie pas, c'est une question ambigüe.  
 
Je sais bien que Marc fait ce qu'il peut et ce ne doit pas toujours être facile mais dire, en fonction d'AMD, AMD précisant qu'ils ne peuvent déterminer la latence, le fait qu'il y est écrit UN calcul, le fait que le petit message sur les arrondi arrive après ... et j'en passe me conforte dans ma réponse de 50ns. La où ça fache c'est que je l'ai réfléchi pour le multi core mais cette solution n'était pas acceptable vu la question. (J'ai même pensé à un piège)
 
Toutes les questions chaques années sont dures, 5 euros ou 7 euros, 50 ou 44..., GMT ou GMT+1, sur LDLC (ou le groupe LDLC qui est formé de 10 filliales ?)
 
La difficulté est partout mais je suis déçu pour cette question 5 car elle aurai du être carré, une question = une réponse possible != une interprétation.
 
Je me retire de la discution sur ce mot mais sachez que je suis un joueur HFR qui ne rejouera certainement plus malheureusement,
 
+

Ils ne sont pas assez nombreux pour être pris en compte

La note d'AMD concerne l'execution sur un même core superscalaire de plusieurs instructions en // (ce qui est possible avec nos CPU superscalaires), pas l'execution sur deux core.

Fallait deviner ^^ c'est bon je m'en vais =>

 
Clairement, il y a plusieurs interprétations possibles de la question. Pour enlever toute ambiguité, il aurait fallu dire :
 
Quelle est, exprimé en nanosecondes, le temps minimum nécessaire à l’exécution en virgule flottante d’un calcul de sinus et d'un calcul de cosinus sur un Phenom X3 8450 ?
 
Je trouve que mon interprétation de l'utilisation de FSINCOS un calcul de sinus puis cosinus du résultat est donc valable.

 
ah j'ai du mal interprété alors . j'ai cru que c'était l'exécution en paralléle sans aucune précision sur le fait que ce soit sur un core ou plusieurs.

Rhaaaaaa, mais tout ce que je veux c'est entendre oué la formulation était un piège ahahahah j'en ris aux larmes, c'est pas compliqué
Mon exemple est peut être pas ce qu'il y a de mieux, certes, mais je n'ai pas l'impression d'être la seule victime de la formulation de la question
Bon après c'est pas forcément rassurant, si ça se trouve on est effectivement tous débiles
 

 
La meilleure formulation aurait été: "le temps minimum pour obtenir la valeur du sin et du cos du même nombre".
Dans ce cas, plus d'ambiguité sur le "un calcul".
 
Mode troll on
Personne n'a posé la question directement à AMD, pour avoir la réponse "selon AMD" ?    
Mode troll off