On Wed, Oct 22, 2014 at 2:35 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
The only relevance of the sleep() in my opinion is that it provides an
opportunity to test the runtime performance of the 50 threads running
concurrently by allowing the JVM to complete thread instantiation first,
before the threads go into their 20K loops.
Without sleep() the first threads instantiated would have completed their
loops before subsequent threads were instantiated.
The sleep really *is* there to simulate non-CPU-bound activity, as a
real-world application would likely have; and it doesn't have anything
to do with giving the later threads a chance to be instantiated before
the earlier ones finish.
50 tasks isn't a lot to instantiate. It's definitely quicker on most
systems than 20,000 string concatenations. If this doesn't seem
intuitive to you, try it yourself. I did. I copied the code from the
article, dropped the sleep down to 1 millisecond, and threw in some
more print statements to show the instantiation of tasks. The 50th
task was instantiated before the first result came back. (This was
run on a 4-core PC.)
My point about removing sleep() from the first test (and this is just my
extrapolation) is that the test would likely complete in about 15 seconds
(.278 times 50) plus some wait time, and would consume something less than
100% of one CPU, perhaps say 60%.
My results were similar to the article. Each of my cores is faster,
but the guy in the article has more cores. In SerialTest, my loops
ran in the .17 second range, for a total time of about 59 seconds (for
the 1-second sleep per task), and very low CPU utilization. The heavy
CPU simulation with 1 ms sleep reduced the run time to about 8.6
seconds, as expected. Total system CPU utilization hovered around
25%, with almost all the activity hitting one core. My guess is he'd
get about 12.5% system CPU use, with one taxed core.
You can compare that with later tests which "submit" the threads, using a
Java interface which consumed 100% of 8 cores for 11 seconds. The JVM is
evidently handling the multitasking at a huge CPU overhead cost, rather
than letting the OS handle the multitasking. Nobody in their right mind
would do that with a real workload.
There are actually several levels of threading, especially these days.
You can think of them as varying levels of weight or courseness.
Jobs, like what are submitted by SBMJOB, are pretty heavy. There are
"native" threads which are provided by the OS, and several of these
can run in a single job or process. Many languages, including Java,
provide an interface to these. So the OS is still managing that level
of threading. There are "green" threads which are provided by a VM,
and so may have different performance characteristics than native
threads (for example, on some systems green threads could be quicker
to activate and synchronize but might be slower at I/O and context
switching), and may be the only option if the OS doesn't provide
native threads.
I can assure you that Java is not particularly bad at threading. It's
probably not the best in existence, but it's actually competent. Much
more relevant to whether multithreading is going to be a successful
strategy are the nature of the workload (some are better suited to
threading than others), the OS, and the underlying hardware.
John Y.
midrange.com
