Re: depending on a customized library
>>>>> "Michael" == Michael K Edwards <m.k.edwards@gmail.com> writes:
Michael> This is going to sound stupid, but have you tried it with
Michael> either glibc 2.3.4 or Ubuntu's modified glibc? ...
No, I haven't. I think I'll wait until it hits sid.
Michael> Just to check: you are using the same compilation and linking
Michael> scheme for both builds you are benchmarking, right? -fPIC and
Michael> dynamic library thunks can add more than a little overhead to a
Michael> slab-ish, usually-available-from-free-list malloc().
Yes, I'm using the same compilation scheme. I'm only changing the
configure flags for libgc, and toggling linking with libpthread.a.
Michael> Oh, and are there things in the header files that change from
Michael> macros / inline functions to real function calls when you
Michael> switch on threading?
Not that I know of. Any such changes would be in the Boehm gc source;
Asymptote doesn't care about whether or not the garbage collector is
multithreaded. (Asymptote itself isn't multithreaded.)
Michael> Note also the tuning issues discussed in
Michael> http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html , which
Michael> includes benchmarks done on a now ancient kernel (2.2.12). If
Michael> you are using -DPARALLEL_MARK on an SMP (or hyperthreaded)
Michael> machine, and the scheduler gets the processor affinity wrong
Michael> for the dedicated marking threads, I could see that having
Michael> unfortunate performance consequences. If you have compiled
Michael> with -DTHREAD_LOCAL_ALLOC but are not using the API in
Michael> gc_local_alloc.h, you will be hurting.
The configure flags for compiling libgc are: --disable-threads
--disable-shared --enable-cplusplus (obviously with --disable-threads
toggled for the different tests). I'm also running on a
single-processor machine.
Michael> In general, I think that the tool you need for this purpose is
Michael> oprofile. You want to see where threads are sleeping (if at
Michael> all), how much time is spent fiddling with spinlocks, etc. I'm
Michael> a novice with oprofile but I'll be needing to learn about it
Michael> Real Soon Now. Ryan, have you had occasion to throw this or
Michael> other profiling tools at libgc?
I'll take a look at oprofile, but I bet it'll take we a while to figure
it out.
--
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Reply to: