Re: libthread_xu VS libc_r

From:

Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>

Date:

Wed, 30 Apr 2008 15:44:49 -0700 (PDT)

:I've been writing a report on threading and wanted to test our threading
:libraries for fun (and graphs), so I wrote a short program to test the
:time for:
:pthread_create()
:pthread_join()
:fork() to wait()
:
:It was done on my Athlon X2 6000+ with the frequency taken from
:kern.cputimer.freq
:My questions are now:
:
:1 - How come libthread_xu has two peaks in both pthread tests?
:
:2 - How come libthread_xu is overall faster with fork() ?
:
:3 - What are those spikes near 0 in fork() ?
:
:Here are the results:
:http://www.rluciani.com/files/fork.png
:http://www.rluciani.com/files/pthread_create.png
:http://www.rluciani.com/files/pthread_join.png
The TSC between the two cpu's are not synchronized with each other,
so your results are going to be really messed up. You'll have to use
gettimeofday() and then take into account its overhead. I'm guessing
that is one of the reasons why you are seeing such weird results.
The two peaks I see for libthread_xu are fairly close together
and look fairly similar to the libc_r curse, what you are seeing
are probably scheduler artifacts determined by which cpu(s) the
threads are scheduled on.
Thread creation times are probably not a very useful statistic. libc_r
doesn't create real threads, libthread_xu does. So libthread_xu will
always take a bit longer to create the thread. But once created, the
kernel does a much better job managing the light weight processes
libthread_xu creates then libc_r does managing its threads.
-Matt