On Wed, Mar 17, 2010 at 11:29:00AM +0100, Vincent Lefevre wrote:
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead
On 2010-03-21 16:14:49 +0100, Aurelien Jarno wrote:
On Wed, Mar 17, 2010 at 11:29:00AM +0100, Vincent Lefevre wrote:
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead of
-0.85220084976718879499 (correctly rounded
On Sun, Mar 21, 2010 at 04:30:36PM +0100, Vincent Lefevre wrote:
On 2010-03-21 16:14:49 +0100, Aurelien Jarno wrote:
On Wed, Mar 17, 2010 at 11:29:00AM +0100, Vincent Lefevre wrote:
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for
On 2010-03-21 20:55:01 +0100, Aurelien Jarno wrote:
On Sun, Mar 21, 2010 at 04:30:36PM +0100, Vincent Lefevre wrote:
Actually the sincos() function uses the x87 FPU (fsincos instruction),
so that's not surprising that you get the same result.
That just means that the precision is not an
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead of
-0.85220084976718879499 (correctly rounded value). Even the sign
is
On 2010-03-06 11:42:51 +0100, Jerome Vizcaino wrote:
After many tests and research I've come to the conclusion that the
float variants of
sin/cos (and maybe others) are anormaly slow Debian amd64.
Note that on amd64, sin and cos may be slow, but at least they are
mostly correct (in rounding to
On 17.03.2010 11:29, Vincent Lefevre wrote:
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns 0.46261304076460174617 for the sine instead of
On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote:
On 17.03.2010 11:29, Vincent Lefevre wrote:
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy. For instance, on 1e22,
sincos returns
On 17.03.2010 14:36, Vincent Lefevre wrote:
On 2010-03-17 13:41:04 +0100, Giacomo A. Catenazzi wrote:
On 17.03.2010 11:29, Vincent Lefevre wrote:
On 2010-03-07 16:17:08 +0100, Aurelien Jarno wrote:
On amd64, only sincos has an optimized version,
It may be optimized, but completely buggy.
On 2010-03-17 17:14:37 +0100, Giacomo A. Catenazzi wrote:
From C standard (not really the standard, but the draft n1256:
5.2.4.2.2, point 5):
: The accuracy of the floating-point operations (+, -, *, /) and of
: the library functions in math.h and complex.h that return
: floating-point
Hi,
I do not complain about the sin/cos performance but only on the float variants.
Using -ffast-math gives a nice performance boost but leads to bad results (in
our
cases which may be different from the simple given example) so it's not really
a
workaround.
In fact, I don't really care
On 2010-03-17 19:31:16 +0100, Jerome Vizcaino wrote:
I do not complain about the sin/cos performance but only on the
float variants.
OK. I haven't looked at the code, but if sinf() simply calls sin(),
this is suboptimal and there would be room for performance boost
without sacrifying accuracy.
Ok, running sinf/cosf with bounded values gives better performance results
(close to sin/cos ones).
I think the binding trick should be written in the manpages as a note on
amd64
(at least) because the behavior is different on i386 and clearly not expected...
Anyway, I still can't get the
What do you mean sinf/cosf is supposed to be twice faster ?
You're mentionning calling it with bound values ?
Thank you.
Jerome
On Monday 08 March 2010, Aurelien Jarno wrote:
On Mon, Mar 08, 2010 at 12:17:41AM +0100, Jerome Vizcaino wrote:
Ok about the patches : there had to be a reason for
Jerome Vizcaino a écrit :
What do you mean sinf/cosf is supposed to be twice faster ?
You're mentionning calling it with bound values ?
Yes, with the current code and bounded values, it is twice faster. This
is not the case anymore with the assembly code, as the same FPU
instruction
On Sat, Mar 06, 2010 at 11:42:51AM +0100, Jerome Vizcaino wrote:
Package: libc6
Version: 2.10.2-6
Severity: normal
Hi,
After many tests and research I've come to the conclusion that the float
variants
of
sin/cos (and maybe others) are anormaly slow Debian amd64.
The performance loss
On Sun, Mar 07, 2010 at 04:17:08PM +0100, Aurelien Jarno wrote:
On Sat, Mar 06, 2010 at 11:42:51AM +0100, Jerome Vizcaino wrote:
Package: libc6
Version: 2.10.2-6
Severity: normal
Hi,
After many tests and research I've come to the conclusion that the float
variants
of
Hi,
I could not say for sure the difference between sin and sinf (for example) on
Suse but the performance ratio I had on 32 bits, stayed the same on 64 bits.
This is why I was surprised to get impressive slowness when moving to debian :(
Thanks for pointing out the Suse patch : as we only have
On Sun, Mar 07, 2010 at 07:43:46PM +0100, Jerome Vizcaino wrote:
Hi,
I could not say for sure the difference between sin and sinf (for example) on
Suse but the performance ratio I had on 32 bits, stayed the same on 64 bits.
This is why I was surprised to get impressive slowness when moving
On Mon, Mar 08, 2010 at 12:17:41AM +0100, Jerome Vizcaino wrote:
Ok about the patches : there had to be a reason for those not to be merged
upstream.
Also I think they have never been submitted upstream. They are from
2002...
Some of my co-workers noticed the performance improvement when
Ok about the patches : there had to be a reason for those not to be merged
upstream.
Some of my co-workers noticed the performance improvement when binding values
between -pi and pi but the thing is, this kind of trick do not need to be
applied when on 32 bits systems... Libm's behavior is not
Package: libc6
Version: 2.10.2-6
Severity: normal
Hi,
After many tests and research I've come to the conclusion that the float
variants
of
sin/cos (and maybe others) are anormaly slow Debian amd64.
The performance loss is really impressive (around 8 to 9 times slower).
I've attached the prog
22 matches
Mail list logo
