Par contre, concernant les arrondis, l'utilisation de fonction explicite ou des mode de fpu influe sur quoi ? Uniquement la vitesse ? Ou il existe encore des subtilités ?
Ca influe principalement sur trois choses : (en théorie)
- La vitesse (ie le nombre de cycles nécessaires à une opération)
- Le groupement des opérations. Par exemple supposons une opération trigonométrique. En FPU classique disons qu'elle va prendre 6 cycles, par contre pendant toute son execution elle va bloquer le pipeline. Donc c'est maximum 2 opérations (pairage pentium) par block de 6 cycles, et encore à condition de les lancer en même temps. La même interruption vectorisée va prendre 10 cycles mais elle ne bloquera le pipeline que si on change de type d'opération, dans le cas contraire on pourra recharger des valeurs deux cycles plus tard. Donc on aura une réponse au bout de 10 cycles, une seconde au bout de 12, une troisième au bout de 14 etc. Soit un cout degressif qui va tendre vers 2 cycles par opérations (contre trois en FPU classique). Par contre ce type d'opérations est très sensible aux interruptions.
- Les ressources. La FPU classique tend à bouffer quelques registres éventuellement doublés, éventuellement étendus en interne et de la pile. Les opérations vectorielles elles bouffent des regsitres à la pelle, mais ne touchent pas trop à pile (en théorie toujours)
En pratique, la différence entre ce qui devrait se passer en théorie d'après le code machine "en direct de l'assembleur" et se qui se passe réellement au niveau microcode fait que tout celà est de moins en moins vrai. Les processeurs modernes sont capables dans une certaine mesure d'aller piocher dans les regsitres de l'unité d'à coté quand celles-ci (les unités de traitement) ne sont pas tout simplement fusionnées au niveau hard et émulent un comportement ou l'autre en fonction du code machine. (à ce niveau là les processeurs des cartes graphiques sont un vrai bonheur). Bref pour optimiser correctement, il faut la doc complète du processeur (quand elle existe pour le grand public bien sur)
Les modes fast sont souvent des optimisations et des réglages faits au niveau logiciel. Il y a en grosso modo de trois sortes :
- désactivation de certains flags du CPU. (genre la carry sur off, le NAN qui devient une sentinelle et j'en passe)
- réquisition de registres "pas fait pour" dans certains calculs. Ca permet d'avoir plus de registres et donc d'accélerer les calculs, mais certains évènements ne se déclenchent pas lorsqu'il y a des débordements par exemple, ou des nombres qui sont furieusement proches de 0
- réorganisation des opérations dans un ordre qui est plus favorable au processeur (du coup on ne peut plus additionner des fourmis et des éléphants)
Le fast math c'est la soupe du compilo.
Les modes dit rapides sur les processeurs sont souvent des modes qui substituent ou ajoutent aux registres possédants une précision interne plus forte que la précision apparente des registres possédant une précision exacte. Mais on trouve aussi des modes rapides qui font des calculs complètement différents en fonction du mode choisi. C'est le cas par exemple des directives OpenGL de GLHint qui peuvent changer le comportement (et le rendu) du tout au tout en fonction de si on est en GL_NICEST ou en GL_FASTESt
cela n'est génant que pour la detection d'errreur et non pour le fonctionnement nominal
Oui et non. Quand on s'ampute du NAN il vaut mieux savoir ce que l'on fait. car on a plus aucun moyen de savoir si l'on a saturé l'espace de retour (le ou les regsitres qui contiennent le résultat), si l'on a passé des arguments incohérents ou si tout va bien. Bref il faut avoir borné à priori l'intervalle de des paramètres et celui du résultat. Si on décide, par exemple, pour gagner du temps d'utiliser des fonctions logiques (AND, OR etc.) sur des regsitres qui sont supposés être en FPU faut pas venir se plaindre après si les résultats ne veulent pas dire grand chose....
[^] # Re: Ecrire du code avec des flottants
Posté par Jerome Herman . En réponse au journal Comment les programmeurs écrivent du code flottant ?. Évalué à 2.
Ca influe principalement sur trois choses : (en théorie)
- La vitesse (ie le nombre de cycles nécessaires à une opération)
- Le groupement des opérations. Par exemple supposons une opération trigonométrique. En FPU classique disons qu'elle va prendre 6 cycles, par contre pendant toute son execution elle va bloquer le pipeline. Donc c'est maximum 2 opérations (pairage pentium) par block de 6 cycles, et encore à condition de les lancer en même temps. La même interruption vectorisée va prendre 10 cycles mais elle ne bloquera le pipeline que si on change de type d'opération, dans le cas contraire on pourra recharger des valeurs deux cycles plus tard. Donc on aura une réponse au bout de 10 cycles, une seconde au bout de 12, une troisième au bout de 14 etc. Soit un cout degressif qui va tendre vers 2 cycles par opérations (contre trois en FPU classique). Par contre ce type d'opérations est très sensible aux interruptions.
- Les ressources. La FPU classique tend à bouffer quelques registres éventuellement doublés, éventuellement étendus en interne et de la pile. Les opérations vectorielles elles bouffent des regsitres à la pelle, mais ne touchent pas trop à pile (en théorie toujours)
En pratique, la différence entre ce qui devrait se passer en théorie d'après le code machine "en direct de l'assembleur" et se qui se passe réellement au niveau microcode fait que tout celà est de moins en moins vrai. Les processeurs modernes sont capables dans une certaine mesure d'aller piocher dans les regsitres de l'unité d'à coté quand celles-ci (les unités de traitement) ne sont pas tout simplement fusionnées au niveau hard et émulent un comportement ou l'autre en fonction du code machine. (à ce niveau là les processeurs des cartes graphiques sont un vrai bonheur). Bref pour optimiser correctement, il faut la doc complète du processeur (quand elle existe pour le grand public bien sur)
Les modes fast sont souvent des optimisations et des réglages faits au niveau logiciel. Il y a en grosso modo de trois sortes :
- désactivation de certains flags du CPU. (genre la carry sur off, le NAN qui devient une sentinelle et j'en passe)
- réquisition de registres "pas fait pour" dans certains calculs. Ca permet d'avoir plus de registres et donc d'accélerer les calculs, mais certains évènements ne se déclenchent pas lorsqu'il y a des débordements par exemple, ou des nombres qui sont furieusement proches de 0
- réorganisation des opérations dans un ordre qui est plus favorable au processeur (du coup on ne peut plus additionner des fourmis et des éléphants)
Le fast math c'est la soupe du compilo.
Les modes dit rapides sur les processeurs sont souvent des modes qui substituent ou ajoutent aux registres possédants une précision interne plus forte que la précision apparente des registres possédant une précision exacte. Mais on trouve aussi des modes rapides qui font des calculs complètement différents en fonction du mode choisi. C'est le cas par exemple des directives OpenGL de GLHint qui peuvent changer le comportement (et le rendu) du tout au tout en fonction de si on est en GL_NICEST ou en GL_FASTESt
cela n'est génant que pour la detection d'errreur et non pour le fonctionnement nominal
Oui et non. Quand on s'ampute du NAN il vaut mieux savoir ce que l'on fait. car on a plus aucun moyen de savoir si l'on a saturé l'espace de retour (le ou les regsitres qui contiennent le résultat), si l'on a passé des arguments incohérents ou si tout va bien. Bref il faut avoir borné à priori l'intervalle de des paramètres et celui du résultat. Si on décide, par exemple, pour gagner du temps d'utiliser des fonctions logiques (AND, OR etc.) sur des regsitres qui sont supposés être en FPU faut pas venir se plaindre après si les résultats ne veulent pas dire grand chose....