1 thread > 0.8204 seconds
2 threads => 0.8129 seconds
5 threads => 0.7964 seconds
10 threads => 0.7680 seconds
50 threads => 0.7408 seconds
100 threads => 0.7464 seconds
200 threads => 0.7539 seconds
500 threads => 0.7746 seconds
1000 threads => 0.7981 seconds
Henry Wong wrote:You may need more time to counter the affects of the JIT compiler -- run the test many times in a loop, just to warm it up.... then go into another loop for your official test.
Remember because of the JIT, the first iterations will always be slower. So, if you have more threads, the average speed will be faster as the JIT compile time will be amortized across more threads. You may also want to use the "-client" JIT compiler, as the server version will optimize better if it is executed longer (or with more threads).
Henry
You may also want to use the "-client" JIT compiler, as the server version will optimize better if it is executed longer (or with more threads).
view plaincopy to clipboardprint?
1. /*----------------------------------------------------------------
2. C) WAIT THAT THE TEST FINISHES
3. ----------------------------------------------------------------*/
4. try{Thread.sleep(wait_time_milli);}
5. catch(Exception e) {System.out.println(e);}
How does this waits for the threads to finish? For all you know, it can still be running upon return from sleep.
Henry
You also seem to be starting the clock after the start() method is called. I would recommend having each thread have it's own start and end time.... So, you can guarantee that the start time is in the run() method, and doesn't count the time for the actual thread to start.
I would also have a longer test -- less than a second is too short.
Henry
Test with 1 threads
Total test time: 0.0 seconds
Avg test time: 0.0 seconds
Test with 2 threads
Total test time: 0.813 seconds
Avg test time: 0.4065 seconds
Test with 5 threads
Total test time: 10.298 seconds
Avg test time: 2.0596 seconds
Test with 10 threads
Total test time: 51.373 seconds
Avg test time: 5.1373 seconds
Test with 50 threads
Total test time: 1434.278 seconds
Avg test time: 28.68556 seconds
Test with 100 threads
Total test time: 5460.621 seconds
Avg test time: 54.606210000000004 seconds
the threads[100] is started really later than threads[0]. They don't start in the same time!!! threads[100] has to wait the creation and the starts of 99 threads before. It's not fare for the poor threads[100]! :-)
"Computer science is no more about computers than astronomy is about telescopes" - Edsger Dijkstra
Rusty Shackleford wrote:
the threads[100] is started really later than threads[0]. They don't start in the same time!!! threads[100] has to wait the creation and the starts of 99 threads before. It's not fare for the poor threads[100]! :-)
I could be wrong, but Henry moved the timing routine into the threads execution(ie inside run) so the clock on thread 100 doesn't actually start until threads[i].start(); is invoked on that thread.
Seems pretty fair.
1th => average of 1 thread execution 0.4848 seconds
2th => average of 1 thread execution 0.4490 seconds
5th => average of 1 thread execution 0.4375 seconds
10th => average of 1 thread execution 0.4410 seconds
50th => average of 1 thread execution 0.4174 seconds
100th => average of 1 thread execution 0.4168 seconds
500th => average of 1 thread execution 0.4178 seconds
rajesh bala wrote:There is a basic flaw in the way you are benchmarking.
As per your program, NOT all the threads are started at the same point. That is the reason, you dont experience the context switching problem.
You started the threads and initialized them well in advance. Perfect!!..But the moment you say .start() it starts working. So, you have to introduce some GREEN_LIGHT signal in your run() method, which would proceed only when all the threads are started.
~Rajesh.B
Pat Farrell wrote:
The Java folks have greatly improved programming to use threads in 1.5 by adding built in functions/API for Barriers, and other functions that are standard in any multi-threading or multi-tasking function.
See Henry's wonderful Java Threads book, which I bought long ago.
It does not make sense to have thousands of threads unless you have a thousand CPUs.
Look at the ThreadPool APIs. They help a lot.
Enrico Tamellin wrote:Do you think they reduced also the context switches effect? Do you have some link to it?
Pat Farrell wrote:
Enrico Tamellin wrote:Do you think they reduced also the context switches effect? Do you have some link to it?
Done properly, and while I haven't looked into it in depth, the JVM should be able to switch between threads with only a few times more overhead than any other subroutine call. its orders of magnitude less overhead than a process to process clank.
Enrico Tamellin wrote:But is the JVM that perform the context switches?
I thought that the JVM create a thread with a native thread of the OS that will be the only responsable of the scheduling, and so also the context switches. I mean a Jave Thread behaves like a normal OS thread in the System. That's why I was expected that my test with 1000 threads have some context switches effects
Consider Paul's rocket mass heater. |