On 2012-07-26 13:33:46 +0900, Miles Bader wrote:
> Vincent Lefevre writes:
> > I think that there could be an optimization like that in
> > fesetround() too.
>
> Do you think it's worth proposing this to the glibc people?
Yes, since this makes the code much faster on some processors,
I think it
Vincent Lefevre writes:
> But with:
...
> int r = fegetround();
> if (r != FE_TONEAREST)
> fesetround (FE_TONEAREST);
> y = exp(x);
...
> I only get a 9% slowdown. I suppose that withing glibc code, it can
> be lower.
Makes sense... I can imagine the way overworked CPU d
On 2012-07-26 03:58:33 +0900, Miles Bader wrote:
> Vincent Lefevre writes:
> >> So... these functions were made almost an order of magnitude slower
> >> in the (overwhelmingly) common case, in order to handle rare and
> >> exceptional cases...?
> >
> > This depends on the processor. You should get
Vincent Lefevre writes:
>> So... these functions were made almost an order of magnitude slower
>> in the (overwhelmingly) common case, in order to handle rare and
>> exceptional cases...?
>
> This depends on the processor. You should get a processor that
> handles rounding-mode change in a better
On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre writes:
> > By "correct", I mean that the result is somewhat acceptable (not
> > that the result is correctly rounded and the rounding direction is
> > honored), instead of getting completely wrong values or even a
> > crash.
>
>
Vincent Lefevre writes:
>> Based on a glance at the source, it seems like the math libraries
>> were changed in lots of little ways between 2.13 and 2.16 [and it
>> looks like the FPU-twiddling that made expf slow in 2.13 has been
>> _added_ to the generic version of the "exp" (double-precision)
>
On 2012-07-23 14:49:35 +0900, Miles Bader wrote:
> Based on a glance at the source, it seems like the math libraries were
> changed in lots of little ways between 2.13 and 2.16 [and it looks
> like the FPU-twiddling that made expf slow in 2.13 has been _added_ to
> the generic version of the "exp"
Steve Langasek writes:
>> Is there a reason that Debian has such an old version of glibc, even in
>> unstable?
>
>> The current upstream version of glibc seems to be 2.16, whereas Debian
>> has 2.13 (which is circa 2011-02).
>
> The basic reasons are that 2.14 was a dud of an upstream release, and
On Wed, Jul 18, 2012 at 10:05:14AM +0900, Miles Bader wrote:
> Is there a reason that Debian has such an old version of glibc, even in
> unstable?
> The current upstream version of glibc seems to be 2.16, whereas Debian
> has 2.13 (which is circa 2011-02).
The basic reasons are that 2.14 was a du
On Sun, Jul 22, 2012 at 12:07:44PM +0400, Artem Leschev wrote:
> Andreas Metzler
> > That would be a duplicate, http://bugs.debian.org/672934 exists.
> Okay, the Maintainer is debian-glibc list. I don't see any discussion
> about it in the archive, so... Maybe ask again in debian-glibc?
Maybe wai
Andreas Metzler
> That would be a duplicate, http://bugs.debian.org/672934 exists.
Okay, the Maintainer is debian-glibc list. I don't see any discussion
about it in the archive, so... Maybe ask again in debian-glibc?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subj
Artem Leschev wrote:
> [-- text/plain, Encoding quoted-printable, Zeichensatz: UTF-8, 4 Zeilen --]
> I think you need to file a bug against libc6 package about this.
That would be a duplicate, http://bugs.debian.org/672934 exists.
cu andreas
--
`What a good friend you are to him, Dr. Maturin.
I think you need to file a bug against libc6 package about this.
--
Artem Leschev
signature.asc
Description: This is a digitally signed message part
Is there a reason that Debian has such an old version of glibc, even in
unstable?
The current upstream version of glibc seems to be 2.16, whereas Debian
has 2.13 (which is circa 2011-02).
[The particular improvement I'm interested in is a (significantly)
faster version of the "expf" function (unf
14 matches
Mail list logo
