🚀 go-pugleaf

In article <1992Oct6.183610.17142@news.lrz-muenchen.de> jolly@next3.cis.uni-muenchen.de (Patrick Stein) writes:
>/*
>
>Hiho again from munich B)
>
>
>I posted the mach kernel bug , but nobody answered B(
>
>So if you don't believe me ... test this program under NS2.1 and NS3.0
>It's unbelievable slow under 3.O. WHY ???
>Didn't NeXT remove the DEBUG Messages ?????
>My first thought was, that the mutex_unlock,mutex_lock and the conditon_*
>functions are so slow : There are not slow, the cthread_detach(cthread_fork...
>is the major speed problem. 
>I need a fast thread execution time, so i will be very very very inter-
>ested in hints or improvements to solve that situation.
>
>					Jolly

Yep, looks like you've found something interesting here.
I compiled and ran your program on a 2.1 and 3.0 machine.
Here are the results.

2.1 machine: 25MHz mono slab, 20MB RAM
carib [3] % time a.out
...
All 150 slaves have finished.
1.4u 2.6s 0:04 92% 0+0k 4+0io 0pf+0w

3.0 machine: 25MHz mono slab, 32MB RAM
bowen [4] % time a.out      
...
All 150 slaves have finished.
2.16u 50.734s 2:09 98% 0+0k 0+0io 0pf+0w

By reducing the number of threads created, I noticed
a dropoff point. 100 threads:62sec, 75 threads:40sec, 50 threads:5sec.
(I tried to find a similar dropoff for 2.1, but the buggy kernel
crashes the machine when too many threads are created.)

My guess is that the kernel in 3.0 is not designed to handle a
large number of threads.  Perhaps they are doing some dynamic
allocation and garbage collection when some threshold is reached.

I would be very interested in hearing something from NeXT
about these observed results.  My area is operating systems,
and I'm implementing a kernel of my own.

...Stuart