Re: performance....

  Richard Seaman, Jr. wrote:

>On Mon, Apr 15, 2002 at 01:39:06PM -0500, Richard Seaman, Jr. wrote:
>
>>On Mon, Apr 15, 2002 at 09:52:03AM -0400, Bill Abt wrote:
>>
>>>Most of our benchmarking and testing has involved the same test cases that
>>>are included in the LinuxThreads package.  In these tests, NGPT is faster
>>>in virtually every area.
>>>
>>Since you're able to do thread context switches in userland, as compared to
>>Linuxthreads that does thread context switches in the kernel, your context
>>switches *ought* to be much more efficient.  But I haven't measured this 
>>directly.
>>
>>It also appears to me that things like syscalls that can block, mutex locking,
>>and pthread_self among others, are likely to be less efficient in NGPT than
>>Linuxthreads.
>>
>>I would guess that benchmarks that are dominated by the cost of context switches
>>would favor NGPT.  Other benchmarks might show the opposite, depending on the
>>mix of code.
>>
>
>Well, I was very wrong about the context switching.  NGPT is very slow.
>I'm attaching some very simple and very crude benchmark code.
>
>Basically, I started 10 threads each doing 1,000,000 yields simultaneously,
>as a very crude measure of context switch overhead. The results (average of
>3 runs, details attached):
>
>        NGPT          44.1 secs
>        Linuxthreads   7.3 secs
>
>Or, NGPT is slower by a factor of 6! By all logic, NGPT should be faster.
>
I'm not so sure about that. NGPT should be able to do much better than 6 
times, of course. But Linux is very optimized on task switching already 
and switching between LWP doesn't require MMU reloads, TLB misses, or 
any other costly operations. NGPT currently has to make two kernel trips 
to for every task switch for signal mask updates because it's using 
setjmp/longjmp to do the task switch (which itself is a problem because 
it doesn't save floating point or MMX context). It could reduce this to 
one, perhaps, by implementing a context switch routine for the 
architecture. But if you have to make a kernel call to do a task switch, 
it's probably a wash on performance. If you could avoid the kernel call, 
it would be better, but I'm not sure that's possible to do and still 
meet POSIX.

If you put the signal mask in user memory and had the kernel fetch it 
from a specific location when it needed it, that would be a big win, 
much like the ability to have a thread set itself unpreemtable by 
setting a userspace variable that the scheduler looks at (NGPT doesn't 
do this, I don't think, but I've read about it in the threading 
research). But the update would probably need to be atomic somehow.

>
>I also did some read/write comparisons.  Basically I did 10 threads each
>doing 100,000 reads and writes, yielding after each read and write.  The results
>(average of 3 runs, details attached):
>
>        NGPT          59.3 secs
>        Linuxthreads  40.3 secs
>
>Or, NGPT is close to 50% slower.  This might be expected based on the overhead
>in the read/write wrappers in the NGPT code.
>   
>
Linuxthreads also has read/write wrappers (for cancellation). I guess 
NGPT has to do more work, though.

-Corey