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
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.4626130407646017
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 round
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 inst
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.
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 about
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 and that return
> : floating-point results is imp
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. For
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 retur
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
-0.8522008497671887949
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
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
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 pe
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 (fcos/f
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 fo
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 b
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 r
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 mo
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 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
> > varian
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 perfor
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 us
22 matches
Mail list logo
