Rem: je parle pour le cas d'un PC normal hein...
Rem: je parle pour le cas d'un PC normal hein...
Rem: je parle pour le cas d'un PC normal hein...
Dans l'article <dsa7g1$t0c$,
Laurent Deniau écrit:Pour eviter les surprises, utilise des doubles partout et des long
double dans les calculs intermediaires.
Tout dépend du processeur et de l'OS. Il faut savoir qu'avec le FPU
traditionnel du x86, les calculs se feront soit en double précision
IEEE 754, soit en double étendu, quel que soit le type utilisé.
Plus les bugs du compilateur... Avec d'autres processeurs,
long double = double.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Dans l'article <dsa7g1$t0c$1@sunnews.cern.ch>,
Laurent Deniau <laurent.deniau@cern.ch> écrit:
Pour eviter les surprises, utilise des doubles partout et des long
double dans les calculs intermediaires.
Tout dépend du processeur et de l'OS. Il faut savoir qu'avec le FPU
traditionnel du x86, les calculs se feront soit en double précision
IEEE 754, soit en double étendu, quel que soit le type utilisé.
Plus les bugs du compilateur... Avec d'autres processeurs,
long double = double.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Dans l'article <dsa7g1$t0c$,
Laurent Deniau écrit:Pour eviter les surprises, utilise des doubles partout et des long
double dans les calculs intermediaires.
Tout dépend du processeur et de l'OS. Il faut savoir qu'avec le FPU
traditionnel du x86, les calculs se feront soit en double précision
IEEE 754, soit en double étendu, quel que soit le type utilisé.
Plus les bugs du compilateur... Avec d'autres processeurs,
long double = double.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Et c'est ce qu'ils font (utiliser SSE).
Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Et c'est ce qu'ils font (utiliser SSE).
Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Et c'est ce qu'ils font (utiliser SSE).
Dans l'article <dscqpp$lc8$,
Laurent Deniau écrit:Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Si on inclut le x86 traditionnel, l'arithmétique flottante n'est pas
complètement portable dans le sens où on peut obtenir des résultats
différents sur différentes machines, notamment s'il y a des tests
d'égalité ou si on utilise des algo style (Fast)2Sum / expansions
(qui deviennent faux en cas d'arrondi non suffisamment contrôlé).
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Concernant le 119 bits, si tu fais référence à
http://anp.lip6.fr/~pyr/Arinews/Arinews-printemps2004-F_de_Dinechin.pdf
c'est juste un corollaire des résultats de mes tests exhaustifs de
exp/log en double précision. Ensuite, les pires cas, on peut les
tabuler si besoin est (il y a un exemple dans ma thèse, concernant
le calcul de 2^x). Et il s'agit de l'arrondi en double précision
(53 bits, pas 64 bits).
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)Et c'est ce qu'ils font (utiliser SSE).
Pour MPFR, on se base presque entièrement sur GMP (plus précisément
les couches mpn et mpz). Il reste peut-être quelques calculs flottants
pour le calcul des termes d'erreur ou des choses de ce genre, ce qui
donne parfois des bugs (on corrige au fur et à mesure...). Il y en a
aussi pour les conversions avec les double et long double, évidemment;
mais on ne force pas SSE (l'utilisateur peut le faire via le CFLAGS,
et d'ailleurs, je crois que nous n'avons jamais testé...).
Dans l'article <dscqpp$lc8$1@sunnews.cern.ch>,
Laurent Deniau <laurent.deniau@cern.ch> écrit:
Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Si on inclut le x86 traditionnel, l'arithmétique flottante n'est pas
complètement portable dans le sens où on peut obtenir des résultats
différents sur différentes machines, notamment s'il y a des tests
d'égalité ou si on utilise des algo style (Fast)2Sum / expansions
(qui deviennent faux en cas d'arrondi non suffisamment contrôlé).
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Concernant le 119 bits, si tu fais référence à
http://anp.lip6.fr/~pyr/Arinews/Arinews-printemps2004-F_de_Dinechin.pdf
c'est juste un corollaire des résultats de mes tests exhaustifs de
exp/log en double précision. Ensuite, les pires cas, on peut les
tabuler si besoin est (il y a un exemple dans ma thèse, concernant
le calcul de 2^x). Et il s'agit de l'arrondi en double précision
(53 bits, pas 64 bits).
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)
Et c'est ce qu'ils font (utiliser SSE).
Pour MPFR, on se base presque entièrement sur GMP (plus précisément
les couches mpn et mpz). Il reste peut-être quelques calculs flottants
pour le calcul des termes d'erreur ou des choses de ce genre, ce qui
donne parfois des bugs (on corrige au fur et à mesure...). Il y en a
aussi pour les conversions avec les double et long double, évidemment;
mais on ne force pas SSE (l'utilisateur peut le faire via le CFLAGS,
et d'ailleurs, je crois que nous n'avons jamais testé...).
Dans l'article <dscqpp$lc8$,
Laurent Deniau écrit:Ma proposition visait a donner une solution simple, portable et
purement C qui minimisait les degats.
Si on inclut le x86 traditionnel, l'arithmétique flottante n'est pas
complètement portable dans le sens où on peut obtenir des résultats
différents sur différentes machines, notamment s'il y a des tests
d'égalité ou si on utilise des algo style (Fast)2Sum / expansions
(qui deviennent faux en cas d'arrondi non suffisamment contrôlé).
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Concernant le 119 bits, si tu fais référence à
http://anp.lip6.fr/~pyr/Arinews/Arinews-printemps2004-F_de_Dinechin.pdf
c'est juste un corollaire des résultats de mes tests exhaustifs de
exp/log en double précision. Ensuite, les pires cas, on peut les
tabuler si besoin est (il y a un exemple dans ma thèse, concernant
le calcul de 2^x). Et il s'agit de l'arrondi en double précision
(53 bits, pas 64 bits).
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Le nec plus ultra etant d'utiliser la bibliotheque MPFR
(http://www.mpfr.org/) si possible.
Oui. :)Et c'est ce qu'ils font (utiliser SSE).
Pour MPFR, on se base presque entièrement sur GMP (plus précisément
les couches mpn et mpz). Il reste peut-être quelques calculs flottants
pour le calcul des termes d'erreur ou des choses de ce genre, ce qui
donne parfois des bugs (on corrige au fur et à mesure...). Il y en a
aussi pour les conversions avec les double et long double, évidemment;
mais on ne force pas SSE (l'utilisateur peut le faire via le CFLAGS,
et d'ailleurs, je crois que nous n'avons jamais testé...).
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce que je voulais dire c'est que pour que les fonctions elementaires
soient correctes sur du IEEE754 64bits (et donc 53bits de mantisse),
il faut une ALU de 128 bits en interne.
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos sans SSE?
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce que je voulais dire c'est que pour que les fonctions elementaires
soient correctes sur du IEEE754 64bits (et donc 53bits de mantisse),
il faut une ALU de 128 bits en interne.
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos sans SSE?
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si mes
souvenirs sont bons) pour etre conforme sur 64bits apres arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme exp,
ne sont pas considérées dans la norme IEEE 754 (elles devraient
l'être dans la révision en cours).
Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce que je voulais dire c'est que pour que les fonctions elementaires
soient correctes sur du IEEE754 64bits (et donc 53bits de mantisse),
il faut une ALU de 128 bits en interne.
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du FPU
traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos sans SSE?
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Dans l'article <dsf33f$ioj$, Laurent Deniau
écrit:Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si
mes souvenirs sont bons) pour etre conforme sur 64bits apres
arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme
exp, ne sont pas considérées dans la norme IEEE 754 (elles
devraient l'être dans la révision en cours).Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce n'est donc pas de "conformité" dont tu veux parler.
Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
D'ailleurs, SCSLib, sur laquelle est basée CrLibm, semble utiliser
des entiers 32 bits:
struct scs { /** the digits, as 32 bits words */ uint32_t
h_word[SCS_NB_WORDS]; /** Used to store Nan,+/-0, Inf, etc and then
let the hardware handle them */ db_number exception; /** This
corresponds to the exponent in an FP format, but here we are in base
2^32 */ int index; /** The sign equals 1 or -1*/ int sign;
};Crlibm ne se base pas sur SSE, mais change le mot de contrôle du
FPU traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos
sans SSE?
Le code a:
#if defined(PROCESSOR_HAS_FMA)
Mais l'arrondi exact fourni par le FMA n'est apparemment pas utilisé.
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Dans l'article <dsf33f$ioj$1@sunnews.cern.ch>, Laurent Deniau
<laurent.deniau@cern.ch> écrit:
Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si
mes souvenirs sont bons) pour etre conforme sur 64bits apres
arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme
exp, ne sont pas considérées dans la norme IEEE 754 (elles
devraient l'être dans la révision en cours).
Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce n'est donc pas de "conformité" dont tu veux parler.
Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
D'ailleurs, SCSLib, sur laquelle est basée CrLibm, semble utiliser
des entiers 32 bits:
struct scs { /** the digits, as 32 bits words */ uint32_t
h_word[SCS_NB_WORDS]; /** Used to store Nan,+/-0, Inf, etc and then
let the hardware handle them */ db_number exception; /** This
corresponds to the exponent in an FP format, but here we are in base
2^32 */ int index; /** The sign equals 1 or -1*/ int sign;
};
Crlibm ne se base pas sur SSE, mais change le mot de contrôle du
FPU traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos
sans SSE?
Le code a:
#if defined(PROCESSOR_HAS_FMA)
Mais l'arrondi exact fourni par le FMA n'est apparemment pas utilisé.
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Dans l'article <dsf33f$ioj$, Laurent Deniau
écrit:Elle n'avait pas la pretention d'etre l'unique bonne solution.
Notament parce que meme en mode etendu (80 bits sur x86), le
resultat peut-etre incorrect. En fait le passage par SSE est
obligatoire puisque pour etre conforme a IEEE754, il est prouve
qu'il faut faire les calculs sur 128bits (119bits pour exp si
mes souvenirs sont bons) pour etre conforme sur 64bits apres
arondi.
Tu as l'air de confondre... Les fonctions élémentaires, comme
exp, ne sont pas considérées dans la norme IEEE 754 (elles
devraient l'être dans la révision en cours).Non, je ne confonds pas. Je parle des intervalles representable par
IEEE754 comme domaine des fonctions elementaires.
Ce n'est donc pas de "conformité" dont tu veux parler.
Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
D'ailleurs, SCSLib, sur laquelle est basée CrLibm, semble utiliser
des entiers 32 bits:
struct scs { /** the digits, as 32 bits words */ uint32_t
h_word[SCS_NB_WORDS]; /** Used to store Nan,+/-0, Inf, etc and then
let the hardware handle them */ db_number exception; /** This
corresponds to the exponent in an FP format, but here we are in base
2^32 */ int index; /** The sign equals 1 or -1*/ int sign;
};Crlibm ne se base pas sur SSE, mais change le mot de contrôle du
FPU traditionnel.
Et que deviennent les FMA que l'on trouve dans tous leurs algos
sans SSE?
Le code a:
#if defined(PROCESSOR_HAS_FMA)
Mais l'arrondi exact fourni par le FMA n'est apparemment pas utilisé.
Ok. Ceci dit, cr-libm semble etre plus rapide que MPFR.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Vincent Lefevre wrote:Dans l'article <dsf33f$ioj$, Laurent Deniau
écrit:Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Meaculpa, je voulais dire une FPU de 128bits (decidement ce matin j'ai
du brouillard dans la tete).
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
Je parle de support natif par le processeur. Biensur que l'emulation est
possible et existe depuis des lustres. Mais je suppose que tu as eu
cette reponse en raison de mon erreur ALU vs FPU.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Rien n'empeche de faire des specialisations conditionnelles a-la-FFTW,
mais je crois que ce n'est pas le but de la bib ;-)
Vincent Lefevre wrote:
Dans l'article <dsf33f$ioj$1@sunnews.cern.ch>, Laurent Deniau
<laurent.deniau@cern.ch> écrit:
Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Meaculpa, je voulais dire une FPU de 128bits (decidement ce matin j'ai
du brouillard dans la tete).
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
Je parle de support natif par le processeur. Biensur que l'emulation est
possible et existe depuis des lustres. Mais je suppose que tu as eu
cette reponse en raison de mon erreur ALU vs FPU.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Rien n'empeche de faire des specialisations conditionnelles a-la-FFTW,
mais je crois que ce n'est pas le but de la bib ;-)
Vincent Lefevre wrote:Dans l'article <dsf33f$ioj$, Laurent Deniau
écrit:Ce que je voulais dire c'est que pour que les fonctions
elementaires soient correctes sur du IEEE754 64bits (et donc 53bits
de mantisse), il faut une ALU de 128 bits en interne.
Non, et de toute façon, y a-t-il des processeurs qui ont une ALU de
128 bits?
Meaculpa, je voulais dire une FPU de 128bits (decidement ce matin j'ai
du brouillard dans la tete).
Que ce soit en entier ou en flottant, tu peux émuler de la
précision supérieure avec une précision réduite. C'est ce que les
algo font en pratique.
Je parle de support natif par le processeur. Biensur que l'emulation est
possible et existe depuis des lustres. Mais je suppose que tu as eu
cette reponse en raison de mon erreur ALU vs FPU.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Évidemment, car MPFR est à précision arbitraire et n'est pas
optimisée pour une précision donnée.
Rien n'empeche de faire des specialisations conditionnelles a-la-FFTW,
mais je crois que ce n'est pas le but de la bib ;-)
Les FPU n'ont de toute façon pas 128 bits. Pour x86: 64 bits de
mantisse, 1 bit de signe et 15 bits d'exposant, ça fait 80 bits
en tout.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Ça dépend peut-être de la fonction. Dans le code que j'ai sous les
yeux, pour la fonction atan, il y a:
atan-itanium.c
atan-pentium.c
atan_accurate.c
atan_fast.c
Les FPU n'ont de toute façon pas 128 bits. Pour x86: 64 bits de
mantisse, 1 bit de signe et 15 bits d'exposant, ça fait 80 bits
en tout.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Ça dépend peut-être de la fonction. Dans le code que j'ai sous les
yeux, pour la fonction atan, il y a:
atan-itanium.c
atan-pentium.c
atan_accurate.c
atan_fast.c
Les FPU n'ont de toute façon pas 128 bits. Pour x86: 64 bits de
mantisse, 1 bit de signe et 15 bits d'exposant, ça fait 80 bits
en tout.
Ce que j'avais vu etait du code C (code que Florent avait sur son
portable) contenant des parties assembleurs utilisant du SSE ainsi que
du C99 comme les constantes flottantes hexadecimales pour remplir les
tables avec une meilleure precision (evite les arrondis du compilateur
lui-meme lors du changement de base). Mais c'etait probablement une
version dediee x86+SSE+C99. Je crois que cr-libm a une multitudes de
variantes non-officielles et que celle dont tu parles est la version
"portable" environ 2-3 fois plus lente que celle que j'ai vu.
Ça dépend peut-être de la fonction. Dans le code que j'ai sous les
yeux, pour la fonction atan, il y a:
atan-itanium.c
atan-pentium.c
atan_accurate.c
atan_fast.c
Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Dans l'article <dsftf0$g78$,
Laurent Deniau écrit:Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Je ne sais pas.
Ça correspond respectivement à x * y + z et x * y - z,
mais je ne connais pas les rôles des premier et 5e arguments.
Dans l'article <dsftf0$g78$1@sunnews.cern.ch>,
Laurent Deniau <laurent.deniau@cern.ch> écrit:
Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Je ne sais pas.
Ça correspond respectivement à x * y + z et x * y - z,
mais je ne connais pas les rôles des premier et 5e arguments.
Dans l'article <dsftf0$g78$,
Laurent Deniau écrit:Est-ce que tu as une version qui defini ce que font _Asm_fma et _Asm_fms?
Je ne sais pas.
Ça correspond respectivement à x * y + z et x * y - z,
mais je ne connais pas les rôles des premier et 5e arguments.