Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

glibc very old

35 views
Skip to first unread message

Miles Bader

unread,
Jul 17, 2012, 9:10:01 PM7/17/12
to
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 (unfortunately only on x86-64,
although the silly lossage [FPU mode twiddling] that makes the old
version (currently in Debian!) slow might not be as severe on other
architectures).]

Thanks,

-miles

--
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87k3y1n...@catnip.gol.com

Artem Leschev

unread,
Jul 21, 2012, 5:50:02 PM7/21/12
to
I think you need to file a bug against libc6 package about this.
--
Artem Leschev <wo...@gwerewolf.ru>
signature.asc

Andreas Metzler

unread,
Jul 22, 2012, 2:30:01 AM7/22/12
to
Artem Leschev <wo...@gwerewolf.ru> 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. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/4nisd9-...@argenau.downhill.at.eu.org

Artem Leschev

unread,
Jul 22, 2012, 4:30:02 AM7/22/12
to
Andreas Metzler <amet...@downhill.at.eu.org>
> 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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/1342944464.3827.11.camel@localhost

Philipp Kern

unread,
Jul 22, 2012, 9:40:02 AM7/22/12
to
On Sun, Jul 22, 2012 at 12:07:44PM +0400, Artem Leschev wrote:
> Andreas Metzler <amet...@downhill.at.eu.org>
> > 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 wait until the freeze is over?

Kind regards
Philipp Kern
signature.asc

Steve Langasek

unread,
Jul 22, 2012, 3:00:02 PM7/22/12
to
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 dud of an upstream release, and no one
found the time after 2.15 came out to get it into shape for all our ports
before the freeze.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20120722185...@virgil.dodds.net

Miles Bader

unread,
Jul 23, 2012, 2:00:01 AM7/23/12
to
Steve Langasek <vor...@debian.org> 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 no one
> found the time after 2.15 came out to get it into shape for all our ports
> before the freeze.

Thanks Steve (etc) ...

I wonder if it's worth filing a bug about expf in particular; I dunno
whether that change is isolated enough to make a patch easy...

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) function, meaning
it might actually be (much) _slower_ in 2.16 on ports without
optimized implementations... :( ]

-miles

--
Carefully crafted initial estimates reward you not only with
reduced computational effort, but also with understanding and
increased self-esteem. -- Numerical methods in C,
Chapter 9. "Root Finding and Nonlinear Sets of Equations"


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87k3xvh...@catnip.gol.com

Vincent Lefevre

unread,
Jul 23, 2012, 8:40:02 AM7/23/12
to
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" (double-precision) function, meaning
> it might actually be (much) _slower_ in 2.16 on ports without
> optimized implementations... :( ]

However (if this is the change I'm thinking of) this makes math functions
"correct" in directed rounding modes and potentially more secure.

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 Lef�vre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012072312...@ypig.lip.ens-lyon.fr

Miles Bader

unread,
Jul 24, 2012, 12:50:01 AM7/24/12
to
Vincent Lefevre <vin...@vinc17.net> 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)
>> function, meaning it might actually be (much) _slower_ in 2.16 on
>> ports without optimized implementations... :( ]
>
> However (if this is the change I'm thinking of) this makes math
> functions "correct" in directed rounding modes and potentially more
> secure.
>
> 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.

But how often are directed rounding modes used? Like 0.001% of the
time?

So... these functions were made almost an order of magnitude slower in
the (overwhelmingly) common case, in order to handle rare and
exceptional cases...?

I can see that as an emergency workaround when the deadline is next
week, but it seems kind of questionable as a general technique.

Is there no more sane method?

E.g.:

(1) have the FPU-twiddling functions (<fenv.h> stuff?) set a global
flag "FPU_is_twiddled = 1;"

(2) write these rounding-mode-sensitive functions like:

if (FPU_is_twiddled)
return slow_ass_FPU_twiddling_version ();
/* ... otherwise fall through to normal fast code ... */

thanks,

-miles

--
Alone, adj. In bad company.


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87d33lh...@catnip.gol.com

Vincent Lefevre

unread,
Jul 24, 2012, 5:10:02 AM7/24/12
to
On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre <vin...@vinc17.net> 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.
>
> But how often are directed rounding modes used? Like 0.001% of the
> time?

They are not used often. However they must be correct.

> 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 way (the slowdown
should not be noticeable when you just run the program, without
looking at the exact running time).

> I can see that as an emergency workaround when the deadline is next
> week, but it seems kind of questionable as a general technique.
>
> Is there no more sane method?
>
> E.g.:
>
> (1) have the FPU-twiddling functions (<fenv.h> stuff?) set a global
> flag "FPU_is_twiddled = 1;"
>
> (2) write these rounding-mode-sensitive functions like:
>
> if (FPU_is_twiddled)
> return slow_ass_FPU_twiddling_version ();
> /* ... otherwise fall through to normal fast code ... */

There's only one code, which is run in both cases. The difference
is that the rounding mode is set to FE_TONEAREST at the beginning
of the function and restored at the end of the function.

The only sensible change that can be done (without requiring the
compiler a choice based on the FENV_ACCESS pragma) is to test a
global (actually TLS) flag as you propose so that the instruction
to control the rounding mode is not used if the processor was
already in FE_TONEAREST. But note that this could actually be
slower with some processors: the processor already knows the
rounding mode it is running under, so that if the rounding mode
is not changed, the rounding-mode control instruction should be
no slower than no-op!

--
Vincent Lef�vre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012072409...@ypig.lip.ens-lyon.fr

Miles Bader

unread,
Jul 25, 2012, 3:00:02 PM7/25/12
to
Vincent Lefevre <vin...@vinc17.net> 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 way (the slowdown should
> not be noticeable when you just run the program, without looking at
> the exact running time).

It's about 5 times slower on both phenom2 (AMD) and core2 (Intel)
cpus.... I dunno if these are unusual.

> But note that this could actually be slower with some processors:
> the processor already knows the rounding mode it is running under,
> so that if the rounding mode is not changed, the rounding-mode
> control instruction should be no slower than no-op!

Ok, I guess there's no really guaranteed way to make it fast, so
glibc's method (with arch-specific reimplementations for those cases
where it proves to be slow) it is reasonable enough ...

-miles

--
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87vchbf...@catnip.gol.com

Vincent Lefevre

unread,
Jul 25, 2012, 8:40:02 PM7/25/12
to
On 2012-07-26 03:58:33 +0900, Miles Bader wrote:
> Vincent Lefevre <vin...@vinc17.net> 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 way (the slowdown should
> > not be noticeable when you just run the program, without looking at
> > the exact running time).
>
> It's about 5 times slower on both phenom2 (AMD) and core2 (Intel)
> cpus.... I dunno if these are unusual.

I can reproduce a 3.4x slowdown with:

#include <stdio.h>
#include <float.h>
#include <math.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON

int main (void)
{
volatile double x = 1.0, y;
int i;

for (i = 0; i < 100000000; i++)
{
fesetround (FE_TONEAREST);
y = exp(x);
fesetround (FE_TONEAREST);
}
return y == 0.0;
}

and Debian's glibc and Intel Core 2 Duo. I'll try to have more
information about why the processor doesn't detect that the
rounding mode doesn't change.

But with:

#include <stdio.h>
#include <float.h>
#include <math.h>
#include <fenv.h>
#pragma STDC FENV_ACCESS ON

int main (void)
{
volatile double x = 1.0, y;
int i;

for (i = 0; i < 100000000; i++)
{
int r = fegetround();
if (r != FE_TONEAREST)
fesetround (FE_TONEAREST);
y = exp(x);
if (r != FE_TONEAREST)
fesetround (r);
}
return y == 0.0;
}

I only get a 9% slowdown. I suppose that withing glibc code, it can
be lower. The advantage of this method compared to remembering the
rounding mode in glibc is that it is 100% safe, in case the user or
some library bypasses the C libary to change the rounding mode.

I think that there could be an optimization like that in
fesetround() too.

> Ok, I guess there's no really guaranteed way to make it fast, so
> glibc's method (with arch-specific reimplementations for those cases
> where it proves to be slow) it is reasonable enough ...

Yes, the chosen method could depend on the processor.

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2012072600...@xvii.vinc17.org

Miles Bader

unread,
Jul 26, 2012, 12:40:01 AM7/26/12
to
Vincent Lefevre <vin...@vinc17.net> 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 designers not
bothering to optimize mode setting at all (e.g.., just flush all
pipelines when it happens...), on the assumption that setting the
rounding mode is a very rare operation...

> The advantage of this method compared to remembering the
> rounding mode in glibc is that it is 100% safe, in case the user or
> some library bypasses the C libary to change the rounding mode.
>
> 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?
[I'm always a little scared to do that, nest of vipers, etc...]

-miles

--
In New York, most people don't have cars, so if you want to kill a person, you
have to take the subway to their house. And sometimes on the way, the train
is delayed and you get impatient, so you have to kill someone on the subway.
[George Carlin]


--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/87pq7jf...@catnip.gol.com

Vincent Lefevre

unread,
Jul 26, 2012, 7:40:01 AM7/26/12
to
On 2012-07-26 13:33:46 +0900, Miles Bader wrote:
> Vincent Lefevre <vin...@vinc17.net> 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 is. Then they'll have to decide what to do depending
on the processor (in particular on non-x86).

I've attached a new test program. It is also available here:

http://www.vinc17.net/software/rndmode.c

It shows that this change would be useful on all the processors
I've tested: AMD Opteron, Intel Xeon, Intel Core2, POWER7. It
would be particularly important on Intel Core2 and, in a less
extent, AMD Opteron.

Summary of the results:

AMD Opteron 4.62s 8.92s 4.72s
Intel Xeon X5650 3.22s 4.69s 3.51s
Intel Xeon E5520 3.37s 5.20s 3.66s
Intel Core2 Duo P8600 3.35s 11.77s 3.70s
POWER7 7.29s 11.16s 7.86s

1st timing: no calls to fegetround/fesetround.
2nd timing: fegetround/fesetround/fesetround to set and restore the RM.
3rd timing: fegetround with tests before fesetround, so that fesetround
doesn't need to be called.

This shows that the rounding mode test could be done in fesetround.
When the rounding mode really changes, this would just be a little
slower.
rndmode.c
0 new messages