[MUD-Dev] Re: OT: Java multithreading performance

[Vadim Tkachenko]

Chris Gray wrote:
> 
> [Vadim Tkachenko:]
> 
> :Test algorithm:
> :
> :record the time;
> :fire the thread;
> :wait until it's started;
> :record the interval between the creation time and this moment;
> :wait 100 ms;
> :fire another;
> :perform something in the current thread.
> 
> :P2/300, 128M running Linux & JDK 1.1.3 - no significant impact on other
> :programs, except load very close to 1 (for obvious reasons)
> 
> I'm finally approaching that, except only 64M - am I likely to need more?

Usually no, I didn't specifically select the 128M computer - this is
just my office workstation.

> What happens if your delay is increased from 100ms to, say, 1s? (Other than
> the experiment taking a lot more real-time.)

Don't know yet

> I guess I'm wondering just what is consuming the time - is it the JVM flapping around with 3400 threads,
> or is it a lot of allocs and frees that are consuming the time? If the
> objects for the threads are as simple as possible, doing an
> absolute minimum of allocations/deallocations, how do the numbers change? 

Don't know
> How expensive is the "perform something in the current thread"?

Least expensive. The goal was to test the ability to create some number
of threads, not to benchmark the thread performance. The operation is:

Keep static vector of startup delays;
Calculate the average delay and print it (for every successful start);
while ( isEnabled() ) Thread.sleep( 1000 );

Thread performance should be estimated in a different way, full report
on Monday.

> Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are

--
MUD-Dev: Advancing an unrealised future.