Re: libthread_xu VS libc_r

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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