View previous topic :: View next topic |
Author |
Message |
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Tue Feb 21, 2006 2:22 am Post subject: |
|
|
nesl247 wrote: | Your version of gcc probably doesn't support __thread. (According to the error). You need to update gcc first. | I tried that but it wanted to emerge glibc first.
Ahh.. perhaps I should first update gcc and then go about with glibc.. will comment out the glibc from my keywords and emerge gcc first.. why didn't I think of that before posting.. very well.. here I go..
Edit:
Hmm.. not that easy after all... I upgraded to gcc-3.4.4 first, but get the same error still..
well.. it's getting late.. probably check it out again tomorrow.. |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Tue Feb 21, 2006 8:26 am Post subject: |
|
|
Your systems seems a bit screwed up. You are using the default-linux/x86/2006.0 profile but your CHOST is x86_64-pc-linux-gnu and you have ACCEPT_KEYWORDS="amd64 x86".
Since your'e using the x86 profile your CHOST should be i686-pc-linux-gnu and ACCEPT_KEYWORDS should be x86. On the amd64 profile however your CHOST should be x86_64-pc-linux-gnu and ACCEPT_KEYWORDS should be amd64 but your'e not using that. You can only choose one profile and never mix them like that. An you can't switch betwen 32 bit (x86) and 64 bit (amd64) profiles since they are different arches. I'm not sure it it's possbile to resuce your system. Reinstalling and doing it right from the beginning might be the best solution. |
|
Back to top |
|
|
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Tue Feb 21, 2006 6:07 pm Post subject: |
|
|
thats a screwup by me. I did never intent to use the x86 profile.
I did scratch my installation and reinstalled, without changing profiles: Code: | armour etc # ls -l make*
-rw-r--r-- 1 root root 761 Feb 21 09:02 make.conf
-rw-r--r-- 1 root root 16044 Feb 21 10:41 make.conf.example
-rw-r--r-- 1 root root 2278 Feb 21 10:41 make.globals
lrwxrwxrwx 1 root root 50 Feb 21 08:46 make.profile -> ../usr/portage/profiles/default-linux/amd64/2005.1 |
Should I switch to the amd64 2006.0 profile?
Anyway.. I still have the "__thread" problem... Code: | rmour / # emerge --resume
*** Resuming merge...
>>> emerge (1 of 5) sys-libs/glibc-2.3.6-r3 to /
>>> md5 files ;-) glibc-2.3.6-r3.ebuild
>>> md5 files ;-) files/digest-glibc-2.3.6-r3
>>> md5 src_uri ;-) glibc-2.3.6.tar.bz2
>>> md5 src_uri ;-) glibc-linuxthreads-2.3.6.tar.bz2
>>> md5 src_uri ;-) glibc-libidn-2.3.6.tar.bz2
>>> md5 src_uri ;-) glibc-2.3.6-patches-1.8.tar.bz2
>>> md5 src_uri ;-) glibc-manpages-2.3.6-1.tar.bz2
>>> md5 src_uri ;-) glibc-infopages-2.3.6.tar.bz2
>>> md5 src_uri ;-) glibc-fedora-20041219T2331.tar.bz2
>>> Unpacking source...
* Checking gcc for __thread support ... no
* Could not find a gcc that supports the __thread directive!
* please update to gcc-3.2.2-r1 or later, and try again.
!!! ERROR: sys-libs/glibc-2.3.6-r3 failed.
!!! Function check_nptl_support, Line 787, Exitcode 0
!!! No __thread support in gcc!
!!! If you need support, post the topmost build error, NOT this status message. |
I'm now using gcc-4.0.2-r3 from portage (unmasked). How can I get this "__thread" support in gcc? Your gcc-4.0.3-CVS overlay perhaps?
Code: | armour / # emerge info
Portage 2.0.54 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r3, 2.6.15-gentoo-r5-1ct x86_64)
=================================================================
System uname: 2.6.15-gentoo-r5-1ct x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.6.13
ccache version 2.4 [enabled]
dev-lang/python: 2.3.5-r2
sys-apps/sandbox: 1.2.11
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils: 2.16.1
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks fixpackages sandbox sfperms strict"
GENTOO_MIRRORS="http://mirror.gentoo.no/ http://ftp.du.se/pub/os/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="amd64 alsa avi berkdb bitmap-fonts bzip2 crypt cups eds emboss encode expat foomaticdb fortran gif gmp gpm gstreamer imlib ipv6 jpeg kde lzw lzw-tiff mppeg ncurses nls nptl nptlonly opengl pam pdflib perl png python qt quicktime readline sdl spell ssl symlink tcpd tiff truetype-fonts type1-fonts udev unicodeb userlocales xpm xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS |
Update 1:If I removed my glibc overlay where I had commented out the two lines that excluded the Bdirect and hashvals patches, thus using the portage provided glibc-2.3.6-r3 the emerge goes fine: Code: | * Checking gcc for __thread support ... yes
* Checking kernel version (>=2.6.9) ... yes
* Checking linux-headers version (>=2.6.9) ... yes | It also applies a bunch of patches, but it did not to that with my overlay (only change was the two comment marks to enable bdirect and hashvals). I read that sys-devel/binutils-2.16.1 included those patches, right? So I don't need the binutils overlay (2.16.90.x) right?
I'm confused... I guess there is more to it that copying the ebuild file to /usr/local/portage/sys-libs/glibc and edit it, and then run a ebuild digest on it...
will look a bit more on the official ebuilds...
Update 2: Ok. Now I copied the entire /usr/portage/sys-libs/glibc folder into /usr/local/portage/sys-libs/glibc, and enabled the bdirect and hashvals patches; ran a ebuild digest and it does not stop any more. Guess I needed all those files inside /usr/portage/sys-libs/glibc/files... ebuilding is not that easy after all.. will have to do some reading about that later I guess... starting (re)compiling now..
Last edited by Joffer on Wed Feb 22, 2006 12:18 am; edited 3 times in total |
|
Back to top |
|
|
6D7474 Tux's lil' helper
Joined: 08 Sep 2005 Posts: 135
|
Posted: Tue Feb 21, 2006 7:06 pm Post subject: |
|
|
i'll be probably recompiling my system in a few days, so i'am interested if anyone has noticed any improvements/benefits of running 2.3.90 glibc..
thx |
|
Back to top |
|
|
duby2291 Guru
Joined: 17 Oct 2004 Posts: 583
|
Posted: Wed Feb 22, 2006 10:00 am Post subject: |
|
|
duby2291 wrote: | Just for curiosity, I dont think it wasever fully explained what hashvals does exactly
What does it do? What kind of impact on the system does it have? |
I just wanted to bump this question to maybe get someones attention on it..... |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Wed Feb 22, 2006 10:14 am Post subject: |
|
|
duby2291 wrote: | Just for curiosity, I dont think it wasever fully explained what hashvals does exactly. What does it do? What kind of impact on the system does it have? |
Speed up linking, as far I understand it. I found this. I guess that explains it, haven't read the whole thread though.
6D7474 wrote: | i'll be probably recompiling my system in a few days, so i'am interested if anyone has noticed any improvements/benefits of running 2.3.90 glibc..thx |
I'd like to know this too, I saw one post that talked about the system being dog slow after upgrading. Was that just the one poor poster? |
|
Back to top |
|
|
gAzo0o n00b
Joined: 22 Feb 2006 Posts: 22
|
Posted: Wed Feb 22, 2006 4:44 pm Post subject: |
|
|
Failed to compile here.
Code: | i686-pc-linux-gnu-gcc gconv.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -march=pentium3 -pipe -Wstrict-prototypes -mpreferred-stack-boundary=2 -I../include -I/var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads/iconv -I/var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads -I../sysdeps/i386/elf -I../linuxthreads/sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux/i386 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../linuxthreads/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../linuxthreads/sysdeps/unix -I../libidn/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../linuxthreads/sysdeps/i386/i686 -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../linuxthreads/sysdeps/i386 -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/include -isystem //usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads/iconv/gconv.o -MD -MP -MF /var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads/iconv/gconv.o.dt -MT /var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads/iconv/gconv.o
gconv.c: In function `__gconv':
gconv.c:54: error: structure has no member named `pointer_guard'
make[2]: *** [/var/tmp/portage/glibc-2.3.90.20060207/work/build-default-i686-pc-linux-gnu-linuxthreads/iconv/gconv.o] Error 1
make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060207/work/glibc-2.3.6/iconv'
make[1]: *** [iconv/subdir_lib] Error 2
make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.90.20060207/work/glibc-2.3.6'
make: *** [all] Error 2
!!! ERROR: sys-libs/glibc-2.3.90.20060207 failed.
Call stack:
ebuild.sh, line 1894: Called dyn_compile
ebuild.sh, line 941: Called src_compile
glibc-2.3.90.20060207.ebuild, line 1213: Called toolchain-glibc_src_compile
!!! (no error message)
!!! If you need support, post the topmost build error, and the call stack if relevant.
|
Here's my `emerge --info`
Code: | Portage 2.1_pre4-r1 (default-linux/x86/2005.1, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-nitro3 i686)
=================================================================
System uname: 2.6.15-nitro3 i686 Celeron (Coppermine)
Gentoo Base System version 1.12.0_pre15
dev-lang/python: 2.4.2-r1
sys-apps/sandbox: 1.2.17
sys-devel/autoconf: 2.13, 2.59-r7
sys-devel/automake: 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils: 2.16.91.0.6
sys-devel/libtool: 1.5.22
virtual/os-headers: 2.6.11-r3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -pipe -ftracer -mmmx -msse -mfpmath=sse"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium3 -pipe -ftracer -mmmx -msse -mfpmath=sse"
DISTDIR="/mnt/hda1/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms"
GENTOO_MIRRORS="http://gentoo.itdnet.net/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
LDFLAGS="-Wl,-O1 -Wl,--relax,-Bdirect -Wl,-hashvals -Wl,-zdynsort"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X aac alsa apm asf avi berkdb bitmap-fonts crypt cups dts dvd dvdread eds emboss encode foomaticdb fortran gdbm gif gpm gstreamer gtk gtk2 imlib ipv6 jpeg kde libg++ libwww mad matroska mikmod mmx motif mp3 mpeg ncurses nls ogg oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl spell sse ssl symlink tcpd truetype truetype-fonts type1-fonts vorbis win32codecs x86 xml2 xmms xv zlib elibc_glibc kernel_linux userland_GNU"
Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LINGUAS, MAKEOPTS
|
I tried 'save' cflags and different ldflags, but everytime got the same error. |
|
Back to top |
|
|
nesl247 Veteran
Joined: 15 Jun 2004 Posts: 1614 Location: Florida
|
Posted: Wed Feb 22, 2006 5:13 pm Post subject: |
|
|
Try emerging it without these flags: "-mmmx -msse -mfpmath=sse" |
|
Back to top |
|
|
immudium Guru
Joined: 12 Oct 2004 Posts: 332 Location: Utah
|
Posted: Wed Feb 22, 2006 5:35 pm Post subject: |
|
|
kireru wrote: |
I'd like to know this too, I saw one post that talked about the system being dog slow after upgrading. Was that just the one poor poster? |
Err, if you're referring to my comments, I was talking about Java being dog slow, not necessarily my system. This is on an x86 system as well and thus woudn't benefit as much, from the optimized amd64 routines that this patched glibc is tailored for. That said, after running a few basic benchmarks, nbench and a sat solver, I cannot say with any certainty that 2.3.90 is significantly slower or faster on x86 than 2.3.6. Java does remain slightly slower on my 2.3.90 x86 machine verses my 2.3.6 x86 machine, but at this point I'm inclined to attribute the performance to factors beyond glibc. My 2.3.90 amd64 machine is definitely faster in memcpy scores (as others have reported) than my unpatched amd64 machine, but both run about the same on the sat solver that I got from the other thread. However, my patched amd64 machine is dual core X2 and is much faster than my 2.3.6 amd64 machine, so again I can't arrive at any definitive conclusion. The only thing I can tell you for certain is give it a try and test it for yourself. |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Wed Feb 22, 2006 6:25 pm Post subject: |
|
|
You're right, I was looking at PrakashP comments in the old thread and he was talking about a performance issue with the 2.3.90-snapshot and I didn't notice you were talking about specifically java in your post, sorry about that. I'm a way to fast reader . Doesn't seem to common though so I'll think about taking the plunge myself and check it out if there are some positive reports! |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Wed Feb 22, 2006 7:05 pm Post subject: |
|
|
Keep in mind, I couldn't test whether this version of the SAT solver shows the same behaviour, but it should as the core is the same as the one with which I experienced the trouble. But if the problem went away - that's great.
(EDIT:)
Ok, I remembered on my home machine I had the broken version as well and quickpkg'ed it, so here you see the sympton with the böhm sat solver:
Code: |
sat32 static
sat time assign br-nodes name
0 2.3 3564384 90149 250-1125-3/d00
0 3.1 5109057 130094 250-1125-3/d01
0 1.2 1971921 50919 250-1125-3/d02
0 1.5 2400184 62269 250-1125-3/d03
0 2.3 3916438 98107 250-1125-3/d04
0 1.8 2793395 70799 250-1125-3/d05
1 0.7 1174949 29681 250-1125-3/d06
0 2.6 4401101 112560 250-1125-3/d07
0 1.0 1539147 39780 250-1125-3/d08
0 2.6 4153532 104798 250-1125-3/d09
1 19.1
sat64 static
./runme10.sh: line 8: ./sat64: cannot execute binary file
sat compiled
sat time assign br-nodes name
0 3.5 3564384 90149 250-1125-3/d00
0 5.1 5109057 130094 250-1125-3/d01
0 2.2 1971921 50919 250-1125-3/d02
0 2.4 2400184 62269 250-1125-3/d03
0 3.8 3916438 98107 250-1125-3/d04
0 2.8 2793395 70799 250-1125-3/d05
1 1.1 1174949 29681 250-1125-3/d06
0 4.2 4401101 112560 250-1125-3/d07
0 1.6 1539147 39780 250-1125-3/d08
0 4.0 4153532 104798 250-1125-3/d09
1 30.7
|
This is an AthlonXP@2178MHz.
sys-libs/glibc-2.3.90.20051211 [2.3.6-r3] USE="glibc-omitfp linuxthreads-tls nls nptl nptlonly pic userlocales -build -debug% -erandom -gcc4ssp% -glibc-compat20 -hardened
-nomalloccheck% -profile" using kernel 2.6.16-rc4 and linux-headers-2.6.11-r3.
But following glibc is OK for me (as was -r2 from the overlay):
sys-libs/glibc-2.3.6-r3 USE="glibc-omitfp linuxthreads-tls nls nptl nptlonly pic userlocales -build -erandom -glibc-compat20 -hardened -profile" |
|
Back to top |
|
|
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Wed Feb 22, 2006 7:40 pm Post subject: |
|
|
Nxsty, do I need to your your Glibc Overlay and Binutils Overlay to get Bdirect and hashvals to work? I was about to use your overlay (2.3.6-r2) but now I'm using 2.3.6-r3, where I have enabled the Bdirect and hashvals patches.. I'm also using binutils-2.16.1-r1 and gcc-4.0.2.
I'm asking, since I get misc problems compiling emerge -e world with gcc4 and glibc-2.3.6-r3, and nasl247 says I have to use your or his glibc overlay... se my post here: https://forums.gentoo.org/viewtopic-p-3131453.html |
|
Back to top |
|
|
immudium Guru
Joined: 12 Oct 2004 Posts: 332 Location: Utah
|
Posted: Wed Feb 22, 2006 8:26 pm Post subject: |
|
|
My Bohm SAT scores (gcc -O3 sat.c -o sat):
Athlon 64 X2 2.4Ghz, glibc-2.3.90.20060207, gcc-4.0.3-20060209
sat32 static - 112.4
sat64 static - 156.4
sat compiled - 260.4
Athlon 64 3500+ 2.2GHz, glibc-2.3.90.20060121, gcc-4.0.2
sat32 static - 126.0
sat64 static - 169.8
sat compiled - 283.4
P4 2.8GHz (Northwood), glibc-2.3.6-r3, gcc-4.1.0-pre20060219
sat32 static - 168.7
sat compiled - 167.5
P4 3.0GHz (Northwood), glibc-2.3.6-r2, gcc-3.4.5
sat32 static - 150.4
sat compiled - 151.6
P4 3.2GHz (Prescott), glibc-2.3.90.20060207, gcc-4.0.3-20060209
sat32 static - 187.5
sat compiled - 311.0
Anyway, I'll leave you to your own conclusions. Lot's of variables in my hardware and configurations, though, so be wary of the results above as you should with any micro benchmark.
[Edit]
Lower is better.
Results are from the full test case, runme.sh
Test cases were run twice, taking the better score
[/Edit]
Last edited by immudium on Wed Feb 22, 2006 10:54 pm; edited 1 time in total |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Wed Feb 22, 2006 9:34 pm Post subject: |
|
|
@immudium
Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2.
BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete.
Last edited by PrakashP on Wed Feb 22, 2006 10:31 pm; edited 1 time in total |
|
Back to top |
|
|
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Wed Feb 22, 2006 9:42 pm Post subject: |
|
|
PrakashP wrote: | @immudium
Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2. |
I'm not familiar with the sat benchmark or so.. higher score is better or worse? betterI presume? |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Wed Feb 22, 2006 9:47 pm Post subject: |
|
|
Joffer wrote: | PrakashP wrote: | @immudium
Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2. |
I'm not familiar with the sat benchmark or so.. higher score is better or worse? betterI presume? |
It is run-time, so lower is better!
BTW: The problem with the snapshot glibc is in the headers, not the libs, because compiling to objects on non-broken system and linking on broken, leads to fast sat solver, and vice-versa. So are there some debug options enabled in the headers? |
|
Back to top |
|
|
Joffer Guru
Joined: 10 Sep 2002 Posts: 585 Location: Arendal, Norway
|
Posted: Wed Feb 22, 2006 10:25 pm Post subject: |
|
|
Ok. i did not find any 'sat' in portage. How can I check my score? |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Wed Feb 22, 2006 10:30 pm Post subject: |
|
|
Quote: |
So, I uploaded the Böhm sat solver including a test case. Get it here:
[url]http://punnoor.de/various/böhm-sat.tar.bz2[/url]
Just run "runme10.sh" and check the last lines of each run. If this isn't precise enough, run the full test-case (runme.sh).
|
|
|
Back to top |
|
|
immudium Guru
Joined: 12 Oct 2004 Posts: 332 Location: Utah
|
Posted: Wed Feb 22, 2006 10:59 pm Post subject: |
|
|
PrakashP wrote: | @immudium
Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2. |
Yeah, my memcpy results are so much faster on my Athlons, though, I'm not sure what to think. I guess the best resolution would be to figure out what's going on with the glibc snapshot and this particular benchmark. I'll have to try and do some digging this weekend.
Quote: | BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete. |
What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core. |
|
Back to top |
|
|
duby2291 Guru
Joined: 17 Oct 2004 Posts: 583
|
Posted: Wed Feb 22, 2006 11:50 pm Post subject: |
|
|
immudium wrote: | PrakashP wrote: | @immudium
Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2. |
Yeah, my memcpy results are so much faster on my Athlons, though, I'm not sure what to think. I guess the best resolution would be to figure out what's going on with the glibc snapshot and this particular benchmark. I'll have to try and do some digging this weekend.
Quote: | BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete. |
What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core. |
No real big surprize there.....
The netburst architecture was never intended to be anything more than a marketers dream... Clock speed sells... After all its a bigger number right? So it must be faster.....
At least that is what Intel was hoping people would think.... |
|
Back to top |
|
|
PrakashP Veteran
Joined: 27 Oct 2003 Posts: 1249 Location: C.C.A.A., Germania
|
Posted: Thu Feb 23, 2006 7:11 am Post subject: |
|
|
immudium wrote: |
Quote: | BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete. |
What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core. |
The Prescott's pipeline is even deeper than the Northwood's, so it fits into the picture. (31 vs 20 stages, if I read sandpile.org correctly.) Athlon64 only has 12 stages for integers (which is what sat uses). |
|
Back to top |
|
|
gAzo0o n00b
Joined: 22 Feb 2006 Posts: 22
|
Posted: Thu Feb 23, 2006 7:31 am Post subject: |
|
|
nesl247 wrote: | Try emerging it without these flags: "-mmmx -msse -mfpmath=sse" |
Tried it, but still - the same error. Could it be my gcc version (3.4.5)? |
|
Back to top |
|
|
StringCheesian l33t
Joined: 21 Oct 2003 Posts: 887
|
Posted: Thu Feb 23, 2006 7:51 am Post subject: |
|
|
immudium wrote: | What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core. |
Careful, different versions of GCC there. (not arguing with you about prescott vs northwood - I'm an AMD fan, I know nothing about Intel) |
|
Back to top |
|
|
mrcs Tux's lil' helper
Joined: 10 Oct 2003 Posts: 137
|
Posted: Thu Feb 23, 2006 8:29 am Post subject: |
|
|
PrakashP wrote: | [url]http://punnoor.de/various/böhm-sat.tar.bz2[/url] |
I'd like to try this out, but I get a 404 error when trying to download? |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Thu Feb 23, 2006 11:30 am Post subject: |
|
|
Joffer wrote: | Nxsty, do I need to your your Glibc Overlay and Binutils Overlay to get Bdirect and hashvals to work? I was about to use your overlay (2.3.6-r2) but now I'm using 2.3.6-r3, where I have enabled the Bdirect and hashvals patches.. I'm also using binutils-2.16.1-r1 and gcc-4.0.2.
I'm asking, since I get misc problems compiling emerge -e world with gcc4 and glibc-2.3.6-r3, and nasl247 says I have to use your or his glibc overlay... se my post here: https://forums.gentoo.org/viewtopic-p-3131453.html |
Glibc 2.3.6-r3 has the patches so you don't need my glibc overlay. You just need to enable them in the ebuild, but I guess you've already done that. Binutils 2.16.1-r1 has an older -Bdirect patch but lacks hashvals and dynsort so it's a better idea to use a overlay for it with the latest stuff. |
|
Back to top |
|
|
|
|
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
|
|