Gentoo Forums :: View topic - Glibc overlay with amd64 performance patches! (obsolete)

Glibc overlay with amd64 performance patches! (obsolete)

View unanswered posts
View posts from last 24 hours

Goto page Previous 1, 2, 3, ... 21, 22, 23 Next

Gentoo Forums Forum Index

Unsupported Software

View previous topic :: View next topic

Author

Message

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Thu Sep 22, 2005 9:29 pm Post subject:

gringo wrote:

just a a bump and a big thank you to nxsty for his efforts !

You're welcome.

New overlay online btw. No changes except that it's synced with portage.

AMD64 libm + strings:
http://snigel.no-ip.com/~nxsty/linux/glibc-overlay.tar.bz2
AMD64 libm only:
http://snigel.no-ip.com/~nxsty/linux/glibc-overlay2.tar.bz2

Ibn al-Hazardous
Tux's lil' helper

Joined: 02 Sep 2004
Posts: 133
Location: Somewhere deep in the desert.

Posted: Fri Sep 23, 2005 5:20 pm Post subject:

I just installed glibc with these patches (incl the strings patch), and search in nano 1.3.7 works fine. _________________ /Ibn

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Fri Sep 23, 2005 6:15 pm Post subject:

Are there versions for glibc-2.3.5.20050722 ?

Redeeman
l33t
l33t

Joined: 25 Sep 2003
Posts: 958
Location: Portugal

Posted: Fri Sep 23, 2005 7:41 pm Post subject:

hello.. setiathome/boinc for x86_64 runs very slow, but not on fedora and such, because fedora, i saw on the boinc mailinglist has some special library or something, which should make it fast.. is this it? a modified glibc?

makke
n00b
n00b

Joined: 19 Feb 2004
Posts: 32
Location: Sweden/Umea

Posted: Fri Sep 23, 2005 10:20 pm Post subject:

OK, seems to work now for 5 min at least =)

Benchmark :

Before

Code:

makke@idoru ~ $ ./memcpy 2200 1000 1024000
Memory to memory copy rate = 939.245850 MBytes / sec. Block size = 1024000.

After:

Code:

./memcpy 2200 1000 10240000
Memory to memory copy rate = 2285.831055 MBytes / sec. Block size = 10240000.

Someone spoke about slow SETI, tried bench with Distributed.net client, got a slight decrese of speed :
Before :

Code:

dnetc v2.9011-496-CFR-05060815 for Linux (Linux 2.6.12-gentoo-r10).
[Sep 23 21:39:18 UTC] Automatic processor type detection found
an AMD K8-12 processor.
[Sep 23 21:39:18 UTC] RC5-72: Running micro-bench to select fastest core...
[Sep 23 21:39:42 UTC] RC5-72: using core #1 (KBE-64 3-pipe).
[Sep 23 21:40:00 UTC] RC5-72: Benchmark for core #1 (KBE-64 3-pipe)
0.00:00:16.34 [8,689,982 keys/sec]
[Sep 23 21:40:18 UTC] OGR-P2: Benchmark for core #0 (GARSP 6.0-64)
0.00:00:16.20 [29,885,400 nodes/sec]

After :

Code:

dnetc v2.9011-496-CFR-05060815 for Linux (Linux 2.6.12-gentoo-r10).
[Sep 23 22:11:55 UTC] Automatic processor type detection found
an AMD K8-12 processor.
[Sep 23 22:11:55 UTC] RC5-72: Running micro-bench to select fastest core...
[Sep 23 22:12:20 UTC] RC5-72: using core #1 (KBE-64 3-pipe).
[Sep 23 22:12:39 UTC] RC5-72: Benchmark for core #1 (KBE-64 3-pipe)
0.00:00:17.36 [8,342,847 keys/sec]
[Sep 23 22:12:58 UTC] OGR-P2: Benchmark for core #0 (GARSP 6.0-64)
0.00:00:16.17 [28,713,990 nodes/sec]

Difference can be an effect of other things than just glibc...

Seems to work, with speed improvement, now I really speed up my GAIM-convos =))
_________________
AMD Athlon64 3200+, MSI K8 Neo-FSR, 1024Mb Crucial DDR400, Dell 2405FPW 24", Maxtor 200Gb Sata runs gentoo and now Xgl with Compiz

MacBook 1.83GHz /1024Mb /80Gb White, Solid MAN!

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Sat Sep 24, 2005 8:12 am Post subject:

Redeeman wrote:

hello.. setiathome/boinc for x86_64 runs very slow, but not on fedora and such, because fedora, i saw on the boinc mailinglist has some special library or something, which should make it fast.. is this it? a modified glibc?

Fedora/redhat has their own branch of glibc so I don't know if it includes them. But none of the patches are in fedora's SRPM.

Please try it and report back here!

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Sat Sep 24, 2005 8:16 am Post subject:

makke wrote:

OK, seems to work now for 5 min at least =)

Benchmark :

Before

Code:

makke@idoru ~ $ ./memcpy 2200 1000 1024000
Memory to memory copy rate = 939.245850 MBytes / sec. Block size = 1024000.

After:

Code:

./memcpy 2200 1000 10240000
Memory to memory copy rate = 2285.831055 MBytes / sec. Block size = 10240000.

Someone spoke about slow SETI, tried bench with Distributed.net client, got a slight decrese of speed :
Before :

Code:

After :

Code:

Difference can be an effect of other things than just glibc...

Seems to work, with speed improvement, now I really speed up my GAIM-convos =))

Actually I tried runnig ubench and nbench and compared a patched glibc with an unpatched, and both benchmarks showed a slightly decrese in performance. But I can hardly think that several distros including SLES would ship these if they didn't improve anything. So are we doing anything wrong?

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Sat Sep 24, 2005 8:38 am Post subject:

gralves wrote:

Are there versions for glibc-2.3.5.20050722 ?

You can easily do one yourself. Just untar my overlay, copy the glibc-2.3.5.20050722 ebuild to it, edit it and add the following to the bottom of toolchain-glibc_src_unpack() {

Code:

# This one needs to be applied with -p1 -E so not using epatch
einfo Applying glibc-2.3.3-x86_64-new-libm-20050725.patch
patch -p1 -E < "${FILESDIR}"/mdk/glibc-2.3.3-x86_64-new-libm-20050725.patch > /dev/null

epatch "${FILESDIR}"/mdk/glibc-2.3.3-x86_64-pow10-aliases-20050725.patch
epatch "${FILESDIR}"/mdk/glibc-2.3.5-x86_64-new-libm-aliasing-20050725.patch
epatch "${FILESDIR}"/mdk/glibc-2.3.3-amd64-string-20050813.patch

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Sat Sep 24, 2005 4:27 pm Post subject:

nxsty wrote:

gralves wrote:

Are there versions for glibc-2.3.5.20050722 ?

You can easily do one yourself. Just untar my overlay, copy the glibc-2.3.5.20050722 ebuild to it, edit it and add the following to the bottom of toolchain-glibc_src_unpack() {

Code:

The string patch didn't work:

Code:

***** glibc-2.3.3-amd64-string-20050813.patch *****

===================================================

PATCH COMMAND: patch -p0 -g0 --no-backup-if-mismatch < /usr/local/portage/sys-libs/glibc/files/mdk/glibc-2.3.3-amd64-string-20050813.patch

===================================================
patching file sysdeps/x86_64/strlen.S
patching file sysdeps/x86_64/dl-machine.h
Hunk #1 succeeded at 216 (offset 8 lines).
patching file sysdeps/x86_64/Makefile
patching file sysdeps/x86_64/strcpy.S
patching file sysdeps/x86_64/memset.S
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file sysdeps/x86_64/memset.S.rej
patching file sysdeps/x86_64/memcpy.S
patching file sysdeps/x86_64/mempcpy.S
Hunk #1 succeeded at 1 with fuzz 2.
patching file sysdeps/x86_64/strcmp.S
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file sysdeps/x86_64/strcmp.S.rej
patching file sysdeps/unix/sysv/linux/x86_64/dl-procinfo.c
patching file sysdeps/x86_64/dl-procinfo.c
patching file sysdeps/x86_64/elf/rtld-global-offsets.sym
patching file sysdeps/x86_64/memcmp.S
patching file sysdeps/x86_64/strncmp.S
===================================================

PATCH COMMAND: patch -p1 -g0 --no-backup-if-mismatch < /usr/local/portage/sys-libs/glibc/files/mdk/glibc-2.3.3-amd64-string-20050813.patch

===================================================
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|============================================================
|Index: sysdeps/x86_64/strlen.S
|--- sysdeps/x86_64/strlen.S 29 Apr 2003 22:47:18 -0000 1.2
|+++ sysdeps/x86_64/strlen.S 7 Mar 2004 14:42:19 -0000
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 552
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|============================================================
|Index: sysdeps/x86_64/dl-machine.h
|--- sysdeps/x86_64/dl-machine.h 6 Jan 2005 22:40:15 -0000 1.27
|+++ sysdeps/x86_64/dl-machine.h 17 Jan 2005 10:58:03 -0000
--------------------------
No file to patch. Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 597
Perhaps you used the wrong -p or --strip option?

And the list goes on and on... I'll take a depper look on it latter today.

edit: (forgot the code tags)

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Sun Sep 25, 2005 8:16 am Post subject:

gralves wrote:

And the list goes on and on... I'll take a depper look on it latter today.

edit: (forgot the code tags)

Ok, try patch instead:
http://snigel.no-ip.com/~nxsty/linux/suse-glibc/glibc-2.3.3-amd64-string.diff

Its from one of suse's devel snapshot glibcs from 2005-07-24 so it should apply cleanly to the latest snapshot in portage. The other patches from the srpm are in the same dir if you have more rejects.

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Sun Sep 25, 2005 4:33 pm Post subject:

nxsty wrote:

gralves wrote:

And the list goes on and on... I'll take a depper look on it latter today.

edit: (forgot the code tags)

Now it is compiling. Thanks.

edit: Still got a compile error on libm

Code:

: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm.a
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_j0':
e_j0.c:(.text+0x4f9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j0.os): In function `__ieee754_y0':
e_j0.c:(.text+0x7e9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_j1':
e_j1.c:(.text+0x4d9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_j1.os): In function `__ieee754_y1':
e_j1.c:(.text+0x6b9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/libm_pic.a(e_lgamma_r.os): In function `__ieee754_lgamma_r':
e_lgamma_r.c:(.text+0x284): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x481): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x767): undefined reference to `__cos'
e_lgamma_r.c:(.text+0x78d): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x7b3): undefined reference to `__cos'
collect2: ld returned 1 exit status

Will try the new libm patch.

edit2: Still can't get it to compile cleanly. I'm quitting it for today.

no4b
Bodhisattva

Joined: 18 Jan 2004
Posts: 774
Location: Tarnów, Poland

Posted: Mon Sep 26, 2005 8:29 am Post subject:

I've had the same compile error so I added glibc-2.3.3-amd64-s_ceil.diff glibc-2.3.3-amd64-string.diff glibc-2.3.libm-ulps.diff libm-x86-64.diff from ftp://ftp.suse.com/pub/projects/glibc/2.3.90/x86_64/20050724/ to get it compilled. Try these, they worked for me.

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Mon Sep 26, 2005 8:51 pm Post subject:

gralves wrote:

Now it is compiling. Thanks.

edit: Still got a compile error on libm

Code:

Will try the new libm patch.

edit2: Still can't get it to compile cleanly. I'm quitting it for today.

Is the patch applied with patch -p1 -E? Just using epatch fails with undefined reference errors just like this.

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Mon Sep 26, 2005 11:45 pm Post subject:

no4b wrote:

I've had the same compile error so I added glibc-2.3.3-amd64-s_ceil.diff glibc-2.3.3-amd64-string.diff glibc-2.3.libm-ulps.diff libm-x86-64.diff from ftp://ftp.suse.com/pub/projects/glibc/2.3.90/x86_64/20050724/ to get it compilled. Try these, they worked for me.

I'll try it tomorrow (it's my break) thanks.

nxsty wrote:

Is the patch applied with patch -p1 -E? Just using epatch fails with undefined reference errors just like this.

This is an error long after I start compiling (not a patch error). It happens when the make process is trying to join the various object files that make libm ( I forgot the English term for it... ) .

I think no4b idea might work. It is probably some incompatibility between the different patches applied to glibc.

edit:
Tryed the following combination :

Code:

einfo Applying glibc-2.3.3-amd64-s_ceil.diff
patch -p1 -E < "${FILESDIR}"/mdk/glibc-2.3.3-amd64-s_ceil.diff > /dev/null

#epatch "${FILESDIR}"/mdk/glibc-2.3.3-amd64-s_ceil.diff
epatch "${FILESDIR}"/mdk/glibc-2.3.3-amd64-string.diff
epatch "${FILESDIR}"/mdk/glibc-2.3.libm-ulps.diff
epatch "${FILESDIR}"/mdk/libm-x86-64.diff

All files where found at http://snigel.no-ip.com/~nxsty/linux/suse-glibc/

glibc-2.3.5.20050722 is compiling as I write those lines. Let's hope it finishes this time

edit2:
Some numbers from old glibc:

Code:

./memcpy 2200 1000 1048576
Memory to memory copy rate = 801.684570 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 793.686707 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 794.075745 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 795.869690 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 792.044434 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 801.266785 MBytes / sec. Block size = 1048576.

edit3:
It was really appearing like it would compile then :

Code:

a - mpa.o
a - mpatan2.o
a - mpatan.o
a - mpexp.o
a - mplog.o
a - mpsqrt.o
a - mptan.o
a - sincos32.o
a - slowexp.o
a - slowpow.o
a - w_remainder_piby2.o
a - w_remainder_piby2f.o
: /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-npt l/math/libm.a
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(e_j0.os): In function `__ieee754_j0':
e_j0.c:(.text+0x4f9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(e_j0.os): In function `__ieee754_y0':
e_j0.c:(.text+0x7e9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(e_j1.os): In function `__ieee754_j1':
e_j1.c:(.text+0x4d9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(e_j1.os): In function `__ieee754_y1':
e_j1.c:(.text+0x6b9): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(e_lgamma_r.os): In function `__ieee754_lgamma_r':
e_lgamma_r.c:(.text+0x284): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x481): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x767): undefined reference to `__cos'
e_lgamma_r.c:(.text+0x78d): undefined reference to `__sin'
e_lgamma_r.c:(.text+0x7b3): undefined reference to `__cos'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_casin.os): In function `casin':
s_casin.c:(.text+0x126): undefined reference to `__copysign'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_casinh.os): In function `casinh':
s_casinh.c:(.text+0x9a): undefined reference to `__copysign'
s_casinh.c:(.text+0x192): undefined reference to `__copysign'
s_casinh.c:(.text+0x1c6): undefined reference to `__copysign'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_cacosh.os): In function `cacosh':
s_cacosh.c:(.text+0xac): undefined reference to `__copysign'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_cacosh.os):s_cacosh.c:(.text+0x1b6): more undefined references to `__copysign' follow
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_casinf.os): In function `casinf':
s_casinf.c:(.text+0xfe): undefined reference to `__copysignf'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_casinhf.os): In function `casinhf':
s_casinhf.c:(.text+0xa0): undefined reference to `__copysignf'
s_casinhf.c:(.text+0x1d4): undefined reference to `__copysignf'
s_casinhf.c:(.text+0x20c): undefined reference to `__copysignf'
/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/ math/libm_pic.a(s_cprojf.os): In function `cprojf':
s_cprojf.c:(.text+0x71): undefined reference to `__copysignf'
collect2: ld returned 1 exit status
make[2]: *** [/var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-l inux-gnu-nptl/math/libm.so] Error 1
rm /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-np tl/math/m_finitef.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_6 4-pc-linux-gnu-nptl/math/m_signbit.c /var/tmp/portage/glibc-2.3.5.20050722/work/ build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinfl.c /var/tmp/portage/glibc-2.3. 5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpl.c /var/tmp/po rtage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isna n.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-n ptl/math/m_finite.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_6 4-pc-linux-gnu-nptl/math/m_copysign.S /var/tmp/portage/glibc-2.3.5.20050722/work /build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexpf.c /var/tmp/portage/glibc-2.3 .5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isinf.c /var/tmp/po rtage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_frex p.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-n ptl/math/m_copysignf.S /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x8 6_64-pc-linux-gnu-nptl/math/m_copysignl.S /var/tmp/portage/glibc-2.3.5.20050722/ work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnf.c /var/tmp/portage/glib c-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_finitel.S /var /tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math /m_modf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux -gnu-nptl/math/m_isinff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64 -x86_64-pc-linux-gnu-nptl/math/m_isnanf.c /var/tmp/portage/glibc-2.3.5.20050722/ work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_signbitl.c /var/tmp/portage/gli bc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_isnanl.c /var /tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math /m_signbitf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-l inux-gnu-nptl/math/m_modff.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-am d64-x86_64-pc-linux-gnu-nptl/math/m_frexpl.c /var/tmp/portage/glibc-2.3.5.200507 22/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_ldexp.c /var/tmp/portage/gli bc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/math/m_scalbnl.S /va r/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-linux-gnu-nptl/mat h/m_scalbn.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-amd64-x86_64-pc-li nux-gnu-nptl/math/m_frexpf.c /var/tmp/portage/glibc-2.3.5.20050722/work/build-am d64-x86_64-pc-linux-gnu-nptl/math/m_modfl.c
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3 .5/math'
make[1]: *** [math/others] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5.20050722/work/glibc-2.3 .5'
make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.3.5.20050722 failed.
!!! Function toolchain-glibc_src_compile, Line 254, Exitcode 2
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Tue Sep 27, 2005 6:42 pm Post subject:

gralves wrote:

Code:

Try this:
patch -p1 -E < "${FILESDIR}"/mdk/libm-x86-64.diff > /dev/null
epatch "${FILESDIR}"/mdk/glibc-2.3.3-amd64-string.diff
epatch "${FILESDIR}"/mdk/glibc-2.3.libm-ulps.diff
epatch "${FILESDIR}"/mdk/glibc-2.3.3-amd64-s_ceil.diff

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Tue Sep 27, 2005 7:33 pm Post subject:

nxsty wrote:

gralves wrote:

Code:

That compiled but I didn't noticed any improvement:

Code:

gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 799.318176 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 787.249207 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy 2200 1000 1048576
Memory to memory copy rate = 773.723328 MBytes / sec. Block size = 1048576.

edit:

Never again will I compile a program w/o -O(anything) to gcc:

Code:

gralves@gralves ~ $ gcc -O4 memcpy.c -o memcpy4
gralves@gralves ~ $ gcc -O3 memcpy.c -o memcpy3
gralves@gralves ~ $ gcc -O2 memcpy.c -o memcpy2
gralves@gralves ~ $ gcc -O1 memcpy.c -o memcpy1
gralves@gralves ~ $ gcc memcpy.c -o memcpy
gralves@gralves ~ $ ./memcpy 2000 5000 1048576
Memory to memory copy rate = 712.826660 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy1 2000 5000 1048576
Memory to memory copy rate = 2102.696289 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy2 2000 5000 1048576
Memory to memory copy rate = 2155.582520 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy3 2000 5000 1048576
Memory to memory copy rate = 2140.322266 MBytes / sec. Block size = 1048576.
gralves@gralves ~ $ ./memcpy4 2000 5000 1048576
Memory to memory copy rate = 2159.277588 MBytes / sec. Block size = 1048576.

Redeeman
l33t
l33t

Joined: 25 Sep 2003
Posts: 958
Location: Portugal

Posted: Thu Sep 29, 2005 2:02 pm Post subject:

the libm patch, is that from suse or mandrake? (the dir in the overlay is called mdk, thats why i ask.)

gralves
Guru
Guru

Joined: 20 May 2003
Posts: 389
Location: Sao Paulo, Brazil

Posted: Thu Sep 29, 2005 4:04 pm Post subject:

Redeeman wrote:

the libm patch, is that from suse or mandrake? (the dir in the overlay is called mdk, thats why i ask.)

gralves wrote:

All files where found at http://snigel.no-ip.com/~nxsty/linux/suse-glibc/

I just put everything on that directory because I am lazy

Master_Of_Disaster
l33t
l33t

Joined: 28 Feb 2003
Posts: 610
Location: 15.05072° East, 48.13747° North (aka Mauer), Austria

Posted: Fri Sep 30, 2005 12:04 pm Post subject:

Do I need to recompile everything for this to take effect? </stupidQuestion> _________________ post tenebras lux, post fenestras tux Registered Linux User Nr. 312509 Adopt an unanswered post today!

Redeeman
l33t
l33t

Joined: 25 Sep 2003
Posts: 958
Location: Portugal

Posted: Fri Sep 30, 2005 2:47 pm Post subject:

no, everything linked against glibc dynamically should automatically make use of it.. atleast the libm patch

ts
Tux's lil' helper

Joined: 15 Dec 2004
Posts: 97

Posted: Sun Oct 02, 2005 3:12 am Post subject:

gralves wrote:

Never again will I compile a program w/o -O(anything) to gcc:

Code:

Great, thanks your guys. It works.

Code:

# ./memcpy 2000 5000 1048576
Memory to memory copy rate = 527.588745 MBytes / sec. Block size = 1048576.
# ./memcpy2 2000 5000 1048576
Memory to memory copy rate = 1460.617188 MBytes / sec. Block size = 1048576.

gcc-4.0.2 and glibc--2.3.5.20050722 with patchs.

Redeeman
l33t
l33t

Joined: 25 Sep 2003
Posts: 958
Location: Portugal

Posted: Sun Oct 02, 2005 3:18 am Post subject:

try test something which uses libm much - the speed improvements are enormous, and i really do mean enormous - 3-4 times faster

satanskin
Guru
Guru

Joined: 25 Apr 2005
Posts: 353

Posted: Sun Oct 02, 2005 6:54 am Post subject:

I'm sort of a newbie on this. What exactly does libm do? I mean what/where are we going to notice such drastic speed improvements? Also, has this been mostly stable for most of you?

Redeeman
l33t
l33t

Joined: 25 Sep 2003
Posts: 958
Location: Portugal

Posted: Sun Oct 02, 2005 7:20 am Post subject:

libm is the library for standard math stuff.. stuff like gimp, setiathome and such which links to libm will see the speedups(only on the stuff which uses the libm functions though).. yes, it has been stable for me, and i believe the patches are safe and stable, since suse pro and redhat buy version uses it.. and mandrake does too..

nxsty
Veteran
Veteran

Joined: 23 Jun 2004
Posts: 1556
Location: .se

Posted: Sun Oct 02, 2005 8:14 am Post subject:

satanskin wrote:

I'm sort of a newbie on this. What exactly does libm do? I mean what/where are we going to notice such drastic speed improvements? Also, has this been mostly stable for most of you?

They should be stable since they are shiped with several distributions. I only had a problem with nano crashing once with an older version of the amd64 string routines patch but nothing since it was updated. Although a few people have reported still having problems with nano and azurius (a java p2p client). In that case you could use overlay2.tar.bz2 which only has the libm improvements and not the string routines patch. No problems have been reported with that yet.

Display posts from previous:

	Gentoo Forums Forum Index Unsupported Software	All times are GMT Goto page Previous 1, 2, 3, ... 21, 22, 23 Next
Page 2 of 23

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Copyright 2001-2024 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy