Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
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  
Reply to topic    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

PostPosted: Thu Sep 22, 2005 9:29 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Ibn al-Hazardous
Tux's lil' helper
Tux's lil' helper


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

PostPosted: Fri Sep 23, 2005 5:20 pm    Post subject: Reply with quote

I just installed glibc with these patches (incl the strings patch), and search in nano 1.3.7 works fine.
_________________
/Ibn
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Fri Sep 23, 2005 6:15 pm    Post subject: Reply with quote

Are there versions for glibc-2.3.5.20050722 ?
Back to top
View user's profile Send private message
Redeeman
l33t
l33t


Joined: 25 Sep 2003
Posts: 958
Location: Portugal

PostPosted: Fri Sep 23, 2005 7:41 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
makke
n00b
n00b


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

PostPosted: Fri Sep 23, 2005 10:20 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Sat Sep 24, 2005 8:12 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Sat Sep 24, 2005 8:16 am    Post subject: Reply with quote

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:
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 =))


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?
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Sat Sep 24, 2005 8:38 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Sat Sep 24, 2005 4:27 pm    Post subject: Reply with quote

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:
# 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


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)
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Sun Sep 25, 2005 8:16 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Sun Sep 25, 2005 4:33 pm    Post subject: Reply with quote

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)


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.


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.
Back to top
View user's profile Send private message
no4b
Bodhisattva
Bodhisattva


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

PostPosted: Mon Sep 26, 2005 8:29 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Mon Sep 26, 2005 8:51 pm    Post subject: Reply with quote

gralves wrote:
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.


Is the patch applied with patch -p1 -E? Just using epatch fails with undefined reference errors just like this.
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Mon Sep 26, 2005 11:45 pm    Post subject: Reply with quote

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.


Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Tue Sep 27, 2005 6:42 pm    Post subject: Reply with quote

gralves wrote:
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


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
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Tue Sep 27, 2005 7:33 pm    Post subject: Reply with quote

nxsty wrote:
gralves wrote:
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


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


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: 8O
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.

Back to top
View user's profile Send private message
Redeeman
l33t
l33t


Joined: 25 Sep 2003
Posts: 958
Location: Portugal

PostPosted: Thu Sep 29, 2005 2:02 pm    Post subject: Reply with quote

the libm patch, is that from suse or mandrake? (the dir in the overlay is called mdk, thats why i ask.)
Back to top
View user's profile Send private message
gralves
Guru
Guru


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

PostPosted: Thu Sep 29, 2005 4:04 pm    Post subject: Reply with quote

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 :)
Back to top
View user's profile Send private message
Master_Of_Disaster
l33t
l33t


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

PostPosted: Fri Sep 30, 2005 12:04 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
Redeeman
l33t
l33t


Joined: 25 Sep 2003
Posts: 958
Location: Portugal

PostPosted: Fri Sep 30, 2005 2:47 pm    Post subject: Reply with quote

no, everything linked against glibc dynamically should automatically make use of it.. atleast the libm patch
Back to top
View user's profile Send private message
ts
Tux's lil' helper
Tux's lil' helper


Joined: 15 Dec 2004
Posts: 97

PostPosted: Sun Oct 02, 2005 3:12 am    Post subject: Reply with quote

gralves wrote:

Never again will I compile a program w/o -O(anything) to gcc: 8O
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.



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.
Back to top
View user's profile Send private message
Redeeman
l33t
l33t


Joined: 25 Sep 2003
Posts: 958
Location: Portugal

PostPosted: Sun Oct 02, 2005 3:18 am    Post subject: Reply with quote

try test something which uses libm much - the speed improvements are enormous, and i really do mean enormous - 3-4 times faster
Back to top
View user's profile Send private message
satanskin
Guru
Guru


Joined: 25 Apr 2005
Posts: 353

PostPosted: Sun Oct 02, 2005 6:54 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Redeeman
l33t
l33t


Joined: 25 Sep 2003
Posts: 958
Location: Portugal

PostPosted: Sun Oct 02, 2005 7:20 am    Post subject: Reply with quote

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..
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


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

PostPosted: Sun Oct 02, 2005 8:14 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    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