0

I tried to run a multithread Java program (in MapReduce style) on Google Nexus 7, and measured the execution time with 

System.currentMillis();

I found that the performance varies a lot (w/ 4 threads on Tegra 3 w/ 4 cores), as below:

704 872 729 729 1086 778 1214 1045 749 768

However, when I used the sequential version, I got stable data like this:

928 851 850 842 863 917 873 905 853 870

I thought the garbage collector is concurrent so it also takes a core, is it the reason cause the big variations?

Why sometimes the performance is even much worse than the sequential version?

JackWM
  • 10,085
  • 22
  • 65
  • 92
  • It really depends on how efficient the threads are... Without knowing that, it's hard to say. But in general, you don't want to have too many threads. – PearsonArtPhoto Dec 07 '12 at 23:59

1 Answers1

0

I thought the garbage collector is also multithreaded, is it the reason cause the big variations?

IMO, it is unlikely that the GC is the cause of the variability.

Why sometimes the performance is even much worse than the sequential version?

We would need to look at your code or an SSCE. However, my guess the reasons are that:

  • this is a problem which is a poor fit for the performance characteristics of Java threading (e.g. the high cost of creating threads), or
  • your multi-threaded solution has a significant concurrency bottleneck and or load balance.
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • If it is caused by your guessed reasons, the performance would always be worse. However, most times, it is noticeably better. – JackWM Dec 08 '12 at 00:15
  • @JackWM - *"the performance would always be worse"* - Not necessarily. Thread scheduling effects can often cause a bottleneck etc to manifest *in a non-deterministic way*. Anyway, the bottom line is that we can't give you a real explanation without seeing your code ... or better still an SSCE. – Stephen C Dec 08 '12 at 00:49