FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 07-18-2012, 01:05 AM
Miles Bader
 
Default glibc very old

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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k3y1nak5.fsf@catnip.gol.com">http://lists.debian.org/87k3y1nak5.fsf@catnip.gol.com
 
Old 07-21-2012, 09:46 PM
Artem Leschev
 
Default glibc very old

I think you need to file a bug against libc6 package about this.
--
Artem Leschev <wolf@gwerewolf.ru>
 
Old 07-22-2012, 06:20 AM
Andreas Metzler
 
Default glibc very old

Artem Leschev <wolf@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4nisd9-jn3.ln1@argenau.downhill.at.eu.org">http://lists.debian.org/4nisd9-jn3.ln1@argenau.downhill.at.eu.org
 
Old 07-22-2012, 08:07 AM
Artem Leschev
 
Default glibc very old

Andreas Metzler <ametzler@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1342944464.3827.11.camel@localhost
 
Old 07-22-2012, 01:36 PM
Philipp Kern
 
Default glibc very old

On Sun, Jul 22, 2012 at 12:07:44PM +0400, Artem Leschev wrote:
> Andreas Metzler <ametzler@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
 
Old 07-22-2012, 06:50 PM
Steve Langasek
 
Default glibc very old

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/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120722185005.GC14267@virgil.dodds.net">http://lists.debian.org/20120722185005.GC14267@virgil.dodds.net
 
Old 07-23-2012, 05:49 AM
Miles Bader
 
Default glibc very old

Steve Langasek <vorlon@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87k3xvhvrk.fsf@catnip.gol.com">http://lists.debian.org/87k3xvhvrk.fsf@catnip.gol.com
 
Old 07-23-2012, 12:35 PM
Vincent Lefevre
 
Default glibc very old

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 <vincent@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723123534.GA9743@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120723123534.GA9743@ypig.lip.ens-lyon.fr
 
Old 07-24-2012, 04:45 AM
Miles Bader
 
Default glibc very old

Vincent Lefevre <vincent@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d33lhinf.fsf@catnip.gol.com">http://lists.debian.org/87d33lhinf.fsf@catnip.gol.com
 
Old 07-24-2012, 09:06 AM
Vincent Lefevre
 
Default glibc very old

On 2012-07-24 13:45:08 +0900, Miles Bader wrote:
> Vincent Lefevre <vincent@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 <vincent@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-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120724090651.GA6808@ypig.lip.ens-lyon.fr">http://lists.debian.org/20120724090651.GA6808@ypig.lip.ens-lyon.fr
 

Thread Tools




All times are GMT. The time now is 09:25 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org