Thread View: comp.sys.next.programmer
3 messages
3 total messages
Started by Patrick Stein
Tue, 06 Oct 1992 18:36
another KERNEL BUG : SLOW THREADS
Author: Patrick Stein
Date: Tue, 06 Oct 1992 18:36
Date: Tue, 06 Oct 1992 18:36
113 lines
3627 bytes
3627 bytes
/*
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
post scriptum : the program can be found in the DL too ( only the number of
threads changed )
*/
#include <stdio.h>
#include <cthreads.h>
int count; /* number of slave threads active */
mutex_t lock; /* mutual exclusion for count */
mutex_t print; /* mutual exclusion for printfs */
condition_t done; /* signaled each time a slave thread finishes */
void init()
{
/* Allocate mutex variables "lock" and "print". */
lock = mutex_alloc();
print = mutex_alloc();
/* Allocate condition variable "done". */
done = condition_alloc();
count = 0;
}
/*
* Each slave just loops, yielding the processor on each
* iteration. When it's finished, it decrements the global
* count and signals that it's done.
*/
void slave(int n)
{
int i;
for (i = 0; i < 100; i += 1)
cthread_yield();
/*
* If any thread wants to access the count variable, it
* first locks the mutex. When the mutex is locked, any
* other thread wanting the count variable must wait until
* the mutex is unlocked.
*/
mutex_lock(lock);
count -= 1;
mutex_lock(print);
printf("Slave %d finished.\n", n);
mutex_unlock(print);
/* Signal that this slave has finished. */
condition_signal(done);
mutex_unlock(lock);
}
/*
* The master spawns a given number of slaves and then waits
* for them all to finish.
*/
void master(int nslaves)
{
int i;
for (i = 1; i <= nslaves; i++) {
mutex_lock(lock);
/* Increment count with the creation of each slave thread. */
count += 1;
/* Fork a slave and detach it. */
cthread_detach(cthread_fork((cthread_fn_t)slave, (any_t)i));
mutex_unlock(lock);
}
mutex_lock(lock);
/*
* Master thread loops waiting on the condition done. Each
* time the master thread is signaled by a condition_signal
* call, it tests the count for a value of zero.
*/
while (count != 0)
condition_wait(done, lock);
mutex_unlock(lock);
mutex_lock(print);
printf("All %d slaves have finished.\n", nslaves);
mutex_unlock(print);
cthread_exit(0);
}
main()
{
init();
master(150); /* Create master thread and 15 slaves. */
}
Re: another KERNEL BUG : SLOW THREADS
Author: Stuart Ritchie
Date: Wed, 07 Oct 1992 00:25
Date: Wed, 07 Oct 1992 00:25
49 lines
2340 bytes
2340 bytes
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
Re: another KERNEL BUG : SLOW THREADS
Author: Klaus &
Date: Wed, 07 Oct 1992 10:37
Date: Wed, 07 Oct 1992 10:37
26 lines
1548 bytes
1548 bytes
In article <1992Oct6.183610.17142@news.lrz-muenchen.de>
jolly@next3.cis.uni-muenchen.de (Patrick Stein) writes:
> 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
Hi Jolly,
I have the same problem and I'm very interested in a solution of this
problem. I've implemented an Objective-C Linda Preprocessor, and because
it simulates several processors by threads, my implementation has slowed
down to only 10% performance it had under 2.1, so I'm VERY dissapointed
and a little bit angry.
So, if someone knows a solution, please let me know.
Klaus
--
Klaus Muelheims mulheims@infko.uni-koblenz.de
Eichenwinkel 10 (NeXTmail welcome)
Voice: +49 261 86518
5760 Arnsberg 1 +49 2932 1601
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads