Re: [gentoo-user] The NPTL difference
Grant wrote: How do you tell an app to use linuxthreads instead? What is the point of +nptlonly? A more compact installation? A trick to make an app use linuxthreads is set LD_ASSUME_KERNEL=2.4.19 in the env your app will run in. -- . These pages are best viewed by coming to my house and looking at . . my monitor. [S. Lucas Bergman (on his website)]. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
How do you tell an app to use linuxthreads instead? What is the point of +nptlonly? A more compact installation? A trick to make an app use linuxthreads is set LD_ASSUME_KERNEL=2.4.19 in the env your app will run in. Why don't apps set that on their own if they require it? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On 5/16/05, Grant [EMAIL PROTECTED] wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? - Grant I switched. (Quite awhile ago.) It was not apparent to me that there was any difference at the command line in terms of speed but I didn't measure it. I also didn't have any problems like you're having with Mozilla so it wasn't much of an issue except for completely rebuilding the machine. - Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
Grant wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? I can't say I see a speed difference, but then again, I haven't really tried to benchmark it either. No noticeable problems in the applications I run (KDE, VMWare, Thunderbird Firefox, OOo1.9.XX) 'nptl' enables support for NPTL, but the old linuxthreads library is still available. You essentially end up building 2 glibc's, one with NPTL and the other with linuxthreads. 'nptlonly' does away with the linuxthreads build, so every application that uses threads must use NPTL. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On 5/16/05, Grant [EMAIL PROTECTED] wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? - Grant I switched. (Quite awhile ago.) It was not apparent to me that there was any difference at the command line in terms of speed but I didn't measure it. I also didn't have any problems like you're having with Mozilla so it wasn't much of an issue except for completely rebuilding the machine. - Mark Hi Mark, What do you mean by rebuilding the machine? Do packages need to be recompiled under the new glibc to take advantage of NPTL? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
Grant wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? - Grant Java apps benefit a lot from ntpl. Loki's Sim City 3000 Unlimited, for example, doesn't work with nptl. Some other binary apps too, perhaps. nptlonly makes the ebuild not build a non-nptl libc, which means you can't fall back on linux threads like so: LD_ASSUME_KERNEL=2.4.5 foo -- [Name ] :: [Matan I. Peled] [Location ] :: [Israel] [Public Key] :: [0xD6F42CA5] [Keyserver ] :: [keyserver.kjsl.com] encrypted/signed plain text preferred signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] The NPTL difference
On Mon, May 16, 2005 at 01:25:37PM -0700, Grant wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? I switched a while back and noticed a couple of nice improvements. First, apps are more responsive while doing heavy processing like compiling. that's a definite speed improvement. But the best improvement for me was that audio doesn't hiccup last it used to when other apps suck up resources. So, now I can rip and encode audio files while listening to music in another app without interference. - Grant -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On 5/16/05, Grant [EMAIL PROTECTED] wrote: On 5/16/05, Grant [EMAIL PROTECTED] wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? - Grant I switched. (Quite awhile ago.) It was not apparent to me that there was any difference at the command line in terms of speed but I didn't measure it. I also didn't have any problems like you're having with Mozilla so it wasn't much of an issue except for completely rebuilding the machine. - Mark Hi Mark, What do you mean by rebuilding the machine? Do packages need to be recompiled under the new glibc to take advantage of NPTL? - Grant Grant, I'm a little chicken so I rebuilt everything. This was probably 6 months ago when i did this. I think at the time I was unclear whether everything had to be rebuilt. IIRC I was told it was not necessary but I could be wrong about that. I just decided that logically everything would get rebuilt over time anyway so if a problem showed up later I might not know it was due to this or something else. With that in mind I rebuilt the machine. On this little XBox I'm building right now I haven't enable nptl. I don't know if that will be an issue or not. We'll see... Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
Grant wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? I recently updated a Mysql box from Mysql 3.2.x, 2.4 kernel, dual PIII, and 2GB RAM to Mysql 4.0.x, 2.6 kernel and nptl, dual P4 Xeons, and 4GB of RAM. With hardware upgrade it's been hard to tell exectly what improvements were caused by which upgrades. The db's themselves are around 4-5 GB in total so the new server can fit a significant percentage more of the Mysql data into RAM. We moved from Mysql 3.2.54 to 4.0.24. The disk I/O is U320 on the new server compared to U160 on the old, but both with RAID cards and similar RAID setups. The old server was running 400-500 mysql threads, a number of apache boxes make calls to it, and averaging 300 queries/sec. The load would peak at around 2 with the number of threads being the main influnce of load. The new server is doing the same number of queries and has not been completing them any faster than the old server. However load remains a steady 0.10-0.20 whether there are 300 threads or 500. This appears to be the main benefit of the new threading. Better scalabilty and more efficient use of resources in a highly threaded application rather than any outright speed increase. That may translate into a speed increase if NPTL helps eliminate any resource contentions you may have had. kashani -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On Mon, 16 May 2005, kashani wrote: completing them any faster than the old server. However load remains a steady 0.10-0.20 whether there are 300 threads or 500. This appears to be the main benefit of the new threading. Better scalabilty and more efficient use of resources in a highly threaded application rather than any outright speed increase. That may translate into a speed increase if NPTL helps eliminate any resource contentions you may have had. Are you using nptlonly or just nptl? -- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
Tried it out a few months ago and didn't notice much of a difference speedwise. I found pretty quickly that it broke transcode (dunno if this is still the case) so I reverted to linuxthreads. That caused me quite a bit of headache as I had already rebuilt half the system with nptl and had to re-rebuild without it. On 5/16/05, Grant [EMAIL PROTECTED] wrote: Has anyone switched to NPTL and noticed a speed difference? If so, what seems faster? Has anyone run across any packages that don't work well with NPTL? What about the practical difference between + and - nptlonly? - Grant -- gentoo-user@gentoo.org mailing list -- Why do we drink cow's milk? Who was the first guy who first looked at a cow and said I think I'll drink whatever comes out of these things when I squeeze 'em!?-- Calvin -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On Monday 16 May 2005 22:43, Grant wrote: What do you mean by rebuilding the machine? Do packages need to be recompiled under the new glibc to take advantage of NPTL? no, just no. There is almost never the need to recompile your system, and this is one of the points, where recompiling is pointless. Spend your time doing something more usefull. NPTL is a drop in replacement ... just go not ntplonly, because some apps don't like it. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
A. Khattri wrote: On Mon, 16 May 2005, kashani wrote: completing them any faster than the old server. However load remains a steady 0.10-0.20 whether there are 300 threads or 500. This appears to be the main benefit of the new threading. Better scalabilty and more efficient use of resources in a highly threaded application rather than any outright speed increase. That may translate into a speed increase if NPTL helps eliminate any resource contentions you may have had. Are you using nptlonly or just nptl? just nptl. kashani -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
What do you mean by rebuilding the machine? Do packages need to be recompiled under the new glibc to take advantage of NPTL? no, just no. There is almost never the need to recompile your system, and this is one of the points, where recompiling is pointless. Spend your time doing something more usefull. NPTL is a drop in replacement ... just go not ntplonly, because some apps don't like it. If I use -nptlonly instead of +, do I still risk incompatibilities? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On Tuesday 17 May 2005 01:04, Grant wrote: If I use -nptlonly instead of +, do I still risk incompatibilities? with ntplonly you WILL have problems. With 'nptl', you can say the apps which implementation to use. Great for broken/old apps with problems. BUT if you use ntplonly you can NOT go back, and if an app has a problem with nptl, you are out of luck. So, just remove ntplonly from your make.conf and everything will be fine. Since nptlonly should not be set by default, removing nptlonly should be as good as -nptlonly ;) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
If I use -nptlonly instead of +, do I still risk incompatibilities? with ntplonly you WILL have problems. With 'nptl', you can say the apps which implementation to use. Great for broken/old apps with problems. BUT if you use ntplonly you can NOT go back, and if an app has a problem with nptl, you are out of luck. So, just remove ntplonly from your make.conf and everything will be fine. Since nptlonly should not be set by default, removing nptlonly should be as good as -nptlonly ;) How do you tell an app to use linuxthreads instead? What is the point of +nptlonly? A more compact installation? - Grant -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On 5/16/05, Grant [EMAIL PROTECTED] wrote:
If I use -nptlonly instead of +, do I still risk incompatibilities?
with ntplonly you WILL have problems. With 'nptl', you can say the apps
which
implementation to use. Great for broken/old apps with problems. BUT if you
use ntplonly you can NOT go back, and if an app has a problem with nptl, you
are out of luck. So, just remove ntplonly from your make.conf and everything
will be fine. Since nptlonly should not be set by default, removing nptlonly
should be as good as -nptlonly ;)
How do you tell an app to use linuxthreads instead? What is the point
of +nptlonly? A more compact installation?
- Grant
Well, I'm certainly no example of doing things right but I've been
running nptlonly for quite awhile now and I personally don't know of
any problems caused by running that way. Theer may certainly be apps
that don't like it but maybe I don't run them. I don't know. It works
for me.
CFLAGS=-O2 -march=pentium4 -pipe -fomit-frame-pointer
CHOST=i686-pc-linux-gnu
USE=mozilla gnome kde -arts ladspa nptl nptlonly ladcca audiofile
gimp gimpprint ppds usb alsa cdr dvd dvdr dvdread mmx sse sse2
mozcalendar caps jack jack-tmpfs fluidsynth tcltk sndfile v4l v4l2
mysql flac xscreensaver samba i8x0 mythtv apache2 lirc mjpeg xvid
CXXFLAGS=${CFLAGS}
MAKEOPTS=-j2
Cheers,
Mark
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On Tuesday 17 May 2005 01:37, Grant wrote: If I use -nptlonly instead of +, do I still risk incompatibilities? with ntplonly you WILL have problems. With 'nptl', you can say the apps which implementation to use. Great for broken/old apps with problems. BUT if you use ntplonly you can NOT go back, and if an app has a problem with nptl, you are out of luck. So, just remove ntplonly from your make.conf and everything will be fine. Since nptlonly should not be set by default, removing nptlonly should be as good as -nptlonly ;) How do you tell an app to use linuxthreads instead? What is the point of +nptlonly? A more compact installation? - Grant Matan Peled answered all this in his email to this thread: Matan Peled [EMAIL PROTECTED] wrote: Loki's Sim City 3000 Unlimited, for example, doesn't work with nptl. Some other binary apps too, perhaps. nptlonly makes the ebuild not build a non-nptl libc, which means you can't fall back on linux threads like so: LD_ASSUME_KERNEL=2.4.5 foo so, with nptl flag, you are building glibc basically two times, one with nptl, one with linuxthreads as fallback. If you set nptlonly, you will not have this fallback, and some apps, mostly games, will not work anymore. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
Grant wrote: If I use -nptlonly instead of +, do I still risk incompatibilities? with ntplonly you WILL have problems. With 'nptl', you can say the apps which implementation to use. Great for broken/old apps with problems. BUT if you use ntplonly you can NOT go back, and if an app has a problem with nptl, you are out of luck. So, just remove ntplonly from your make.conf and everything will be fine. Since nptlonly should not be set by default, removing nptlonly should be as good as -nptlonly ;) How do you tell an app to use linuxthreads instead? What is the point of +nptlonly? A more compact installation? +nptlonly avoids building a second libc with linuxthreads supports. It saves compilation time and a bit of space. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] The NPTL difference
On Mon, 16 May 2005 17:10:32 -0700 Mark Knecht [EMAIL PROTECTED] wrote: On 5/16/05, Grant [EMAIL PROTECTED] wrote: If I use -nptlonly instead of +, do I still risk incompatibilities? with ntplonly you WILL have problems. With 'nptl', you can say the apps which implementation to use. Great for broken/old apps with problems. BUT if you use ntplonly you can NOT go back, and if an app has a problem with nptl, you are out of luck. So, just remove ntplonly from your make.conf and everything will be fine. Since nptlonly should not be set by default, removing nptlonly should be as good as -nptlonly ;) snip Well, I'm certainly no example of doing things right but I've been running nptlonly for quite awhile now and I personally don't know of any problems caused by running that way. Theer may certainly be apps that don't like it but maybe I don't run them. I don't know. It works for me. Earlier, I was going to send the same thought but I, too, am not a shining example of 'linux master'. I am running a ~x86 nptlonly system with no problems that I can attribute to it being a nptlonly system snip -- gentoo-user@gentoo.org mailing list
