Hi,
I did an archive rebuild to evaluate the impact of switching to eglibc 2.11
in unstable. The rebuild was done by using the experimental packages.
129 packages failed to build in the eglibc 2.11 chroot (and didn't fail
in the eglibc 2.10 chroot). 110 of them failed to build because of
dependen
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
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-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 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 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
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 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.
I had just built the machine about a month before, so my guess is that
it was the last published version, but happy to try to find out more.
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archi
10 matches
Mail list logo
