Discussion :

[GregWar]

Bonjour, je viens d'apprendre qu'il existait des fonctions comme fsin, fcos ou fsqrt pour faire des opérations de math lourdes sur des flottants directement avec des opcodes. par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
float sinus(float r) {
        float s;
        asm("flds 8(%ebp)");
        asm("fsin");
        asm("fstp -4(%ebp)");
        return s;
}

Depuis combien de temps ce genre de trucs existe t-il ?
Est-ce que c'est dans tous les processeurs ?
Les performances sont t-elles vraiment améliorées par l'utilisation d'opcodes comme fsin (au lieu d'algorithme comme un développement en série de Taylor) ?


Greg

[Neitsa]

Bonjour,

Depuis combien de temps ce genre de trucs existe t-il ?

Dans leur première forme, depuis 28 ans (1980 : premier 8087). Pour une implémentation qui suit fidèlement la norme IEEE 754, depuis 1987 (80387).

Est-ce que c'est dans tous les processeurs ?

Oui, tous les x86 actuels implémentent un FPU (Floating Point Unit) on-chip. Depuis le 486DX en fait. Autant dire que les x86 sans coprocesseur pour flottants n'existent plus.

Les performances sont t-elles vraiment améliorées par l'utilisation d'opcodes comme fsin (au lieu d'algorithme comme un développement en série de Taylor) ?

Oui, ça ira plus vite qu'une série de taylor sur l'ALU.

Maintenant, pour être tout à fait complet, le FPU est en perte de vitesse par rapport aux instructions SIMD (Single Instruction Multiple Data), les "fameux" SSE lorsqu'il s'agit d'optimisation (toutes les fonctions trigos ne sont pas non plus présentes dans les jeux SIMD). Pour de l'utilisation de base, le FPU reste majoritaire.

[dapounet]

Les performances sont t-elles vraiment améliorées par l'utilisation d'opcodes comme fsin (au lieu d'algorithme comme un développement en série de Taylor) ?

Ça dépend de la précision qu'il te faut à mon avis. Je crois qu'Intel et AMD fournissent des fonctions mathématiques optimisées et qu'elles ne sont pas IEEE compliantes, donc elles n'utilisent sûrement pas les instructions comme FSIN.
Le code que tu montres est "evil", tu ne peux pas deviner ce que contient EBP à l'appel de la fonction (ça dépend des flags d'optimisation). Il faut utiliser la syntaxe de l'ASM inline pour accéder aux paramètres ou écrire toute la fonction toi-même en assembleur pour être sûr que le compilateur ne vienne pas ajouter sa tambouille.

[GregWar]

Je sais bien, c'est juste un exemple. Et quant bien même je voudrais utiliser une fonction comme sinus, je prendrais celle de la libc et non pas ce genre d'horreur . C'est juste que ça m'impressione.

Si je poste c'est surtout parce que je suis perplexe, en désasemblant la fonction sin (faisant partie de la libC) de tomber sur un opcode fsin. Je pensais que la libc integrait un algorithme pour calculer un sinus et que ça n'était pas directement une opération du processeur

Ca veut dire qu'il existe quelque part un circuit booléen (avec uniquement des transistor) qui sert à calculer un sinus, un cosinus ou encore une racine carrée ?

Dans ce cas là ces circuits doivent être encore extremement lourds pour que des algorithmes comme l'approximation de John Carmack (http://fr.wikipedia.org/wiki/John_Carmack) soient intéréssantes, non ?

Grégoire

[Obsidian]

Ca veut dire qu'il existe quelque part un circuit booléen (avec uniquement des transistor) qui sert à calculer un sinus, un cosinus ou encore une racine carrée ?

Objectivement, un microprocesseur est un circuit intégré logique hardware, le fait qu'il y ait une couche de soft par dessus ne l'éloigne pas tant que ça d'un circuit « statique » câblé dédié au calcul ...

Plus précisément, je ne sais pas ce qu'il en coûte de calculer un sinus parce que je ne me suis jamais penché sur l'algorithme, mais en ce qui concerne la racine carrée, c'est une opération purement arithmétique, dont la complexité ne dépend que du nombre de chiffres.

La bonne vieille méthode que l'on enseignait autrefois à l'école est tout-à-fait applicable au binaire, qui la simplifie d'autant, d'ailleurs.