More in info gcc: Thread-local storage (TLS) is a mechanism by which variables are allocated such that there is one instance of the variable per extant thread. The run-time model GCC uses to implement this originates in the IA-64 processor-specific ABI, but has since been migrated to other processors as well. It requires significant support from the linker (`ld'), dynamic linker (`ld.so'), and system libraries (`libc.so' and `libpthread.so'), so it is not available everywhere.
etc. On Sun, 09 Nov 2003 08:42:27 +0200, Zvi Har'El wrote about "Re: Redhat 9 slowness - continued": > DOn't trust them. tls is "thread local storage". If you look at info libc > (better source for information about libc than your inner soul ;-) and search > for tls, you'll find > > > `--without-tls' > By default the C library is built with support for thread-local > storage if the used tools support it. By using `--without-tls' > this can be prevented though there generally is no reason since it > creates compatibility problems. > > I admit this is not much information, but it is a correct one! > > On Sun, 09 Nov 2003 00:55:35 +0200, Oleg Kobets wrote about "Re: Redhat 9 slowness - > continued": > > Hmm, I always trust my inner instincts, and right now, they tell me that > > "tls" has something to do with encryption. Perhaps they made an encrypted > > version of C lib to prevent trojans and stuff and that added to the time > > programs run ? > > > > Makes sence to me. > > > > ----- Original Message ----- > > From: "Nadav Har'El" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, November 08, 2003 10:19 PM > > Subject: Redhat 9 slowness - continued > > > > > > > A few days ago, somebody complained about KDE being slower on Redhat 9 > > > than it was in earlier versions. I don't know if my experience is related, > > > but it confirms something bizarre is going on in Redhat 9. > > > > > > I just switched from a Pentium 500Mhz running Redhat 8, to a Pentium 1500 > > > running Redhat 9. > > > > > > Remember how Hspell 0.5 took ages to run, and Hspell 0.6 is much much > > faster > > > to start up? Well, being in love with that fact ( ;)) I wanted to see just > > > how quickly it runs on my new fast machine. On my old machine, it took it > > > 0.3 seconds to start up (hspell /dev/null). I expected it to take 0.1 > > seconds > > > (CPU time) to start on the new computer, but... It still took 0.3 seconds! > > > > > > I started cursing the fake CPU I probably have on the new machine, and > > > the bugs I probably have in Hspell, before I had an epiphany: what if > > > some dynamic-linking issues slowed hspell's running, and it wasn't hspell > > > itself which is slow? > > > > > > So I recomiled hspell staticly (-static, i.e., without shared libraries) > > > on both machines. Lo and behold, Hspell now takes just 0.23 seconds on > > > the old machine, and 0.095 seconds on the new machine. > > > > > > So, apparently, on Redhat 8 the dynamic linking added 21% to > > > "hspell /dev/null"'s static running time, while on Redhat 9, the > > > dynamic linking added 200% (!!!) to the running time of the static > > > program. In absolute terms, 0.2 extra CPU seconds were wasted on > > > Redhat 9, and this is on my new fast machine - on an old machine the > > > added time would have been enormous. > > > > > > But why is this happening? And why does it effect hspell, and not, say > > > "cat /dev/null"? > > > > > > One thing I noticed is that when I do "ldd" to hspell (or cat, or > > anything), > > > I don't get /lib/i686/... like I got in Redhat 8 - instead I get some > > > /lib/tls/.... What is that? setting LD_LIBRARY_PATH to /lib/i686 made > > > hspell very speedy again - 0.12 seconds - back to the acceptable 20% > > > overhead for dynamic linking. > > > > > > Does anybody know what these "tls" version of the C library are? Why > > > are they so much slower to load? Or is there another explanation to the > > > problems I'm seeing? > > > > > > Thanks for any insights, > > > Nadav. > > > > > > > > > -- > > > Nadav Har'El | Saturday, Nov 8 2003, 14 Heshvan > > 5764 > > > [EMAIL PROTECTED] > > |----------------------------------------- > > > Phone: +972-53-790466, ICQ 13349191 |Seen on the back of a dump truck: > > > http://nadav.harel.org.il |<---PASSING SIDE . . . . . > > SUICIDE---> > > > > > > ================================================================= > > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > > the word "unsubscribe" in the message body, e.g., run the command > > > echo unsubscribe | mail [EMAIL PROTECTED] > > > > > > > > > > > > > > ================================================================= > > To unsubscribe, send mail to [EMAIL PROTECTED] with > > the word "unsubscribe" in the message body, e.g., run the command > > echo unsubscribe | mail [EMAIL PROTECTED] > > -- > Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics > tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology > fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL > "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) > Sunday, 14 Heshvan 5764, 9 November 2003, 8:39AM > > ================================================================= > To unsubscribe, send mail to [EMAIL PROTECTED] with > the word "unsubscribe" in the message body, e.g., run the command > echo unsubscribe | mail [EMAIL PROTECTED] -- Dr. Zvi Har'El mailto:[EMAIL PROTECTED] Department of Mathematics tel:+972-54-227607 icq:179294841 Technion - Israel Institute of Technology fax:+972-4-8293388 http://www.math.technion.ac.il/~rl/ Haifa 32000, ISRAEL "If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942) Sunday, 14 Heshvan 5764, 9 November 2003, 8:53AM ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
