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
13 matches
Mail list logo
