[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Low benchmark performance

Simon Derr wrote:

While running a simple thread wake-up benchmark on a 4-way ia64 system I
noticed an interesting behaviour.

The program was stolen from Ian Wienand's pthreadbench suite.
It is a simple producer/consumer program with 1 producer and N consumers.
The thing is, with some values of N, the program runs almost 10 times
slower with NPTL than with LinuxThreads.

Why does the test program use pthread_cond_broadcast() instead of pthread_cond_signal() to wake up a consumer?

/* if the queue is full, signal for worker to clean it */ if ( condition.value ) { pthread_cond_broadcast( &condition.full ); //pthread_cond_signal( &condition.full ); pthread_cond_wait( &condition.empty , &condition.mutex); }

What is broadcast going to do other than create a burst of scheduling? Maybe you just see LinuxThreads deficiencies in that area.

What happens when you use pthread_cond_signal() instead?

Has anybody compared NPTL vs. LinuxThreads performance with Apache 2 plus worker MPM? It has a similar model to the test program (but uses cond_signal instead of cond_broadcast at steady-state), and with LinuxThreads has bad scheduling performance and in particular scheculing-after-unlock performance with any interesting number of threads.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]