Meaningless Drivel is fun!*
The moose likes Performance and the fly likes Does jdk 5.0 API utilize multicore processing ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Does jdk 5.0 API utilize multicore processing ?" Watch "Does jdk 5.0 API utilize multicore processing ?" New topic
Author

Does jdk 5.0 API utilize multicore processing ?

Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
One of the articles in javaworld said that client side applications are not suing the full feature of dual core processor machines.It cited an example of Array sorting and how using java.util.concurrent package(available form jdk 5.0 onwards) can be used to leverage the feature
http://www.javaworld.com/javaworld/jw-09-2007/jw-09-multicoreprocessing.html?page=1

I went through Sun's site and they nowhere mention that this java.util.concurrent pacakge can use the processing power of your machines.
http://java.sun.com/developer/technicalArticles/J2SE/concurrency/index.html

I am not sure if java.util.concurrent help us in improving performance of multi processor machines or is it left for JVM to utilize the power of machines ?


Technical quiz and interview questions   SCJP 6 mock practice test
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

In essentially all modern JVM implementations, each Java "Thread" object corresponds to a separate scheduling primitive at the operating system level. If the operating system knows how to schedule threads on multiple cores, then that JVM implementation will automatically take advantage of the multiple cores when running multithreaded code. This is not just a Java 5 or 6 thing; it's been true since before consumer multicore processors existed. It's true on multiprocessor motherboards, too.

Now, for a given Java program to really take advantage of multiple cores, the program has to explicitly distribute the work it does across multiple threads. If you sort a big array on one thread, then that won't take advantage of multiple cores. What that article says, basically, is that if you divide up the work of sorting across two threads, then you can nearly double the speed of the sort. Of course, there are other things to consider besides raw speed, like GUI responsiveness, and hogging both the cores won't help with that!

Although his implementation may use APIs that are new to JDK 1.6, you could have done the exact same thing using just the APIs in JDK 1.1, and get the same speedup. I say 1.1 only because 1.0 JVMs didn't generally let the OS schedule the threads.


[Jess in Action][AskingGoodQuestions]
Vinay Singh
Ranch Hand

Joined: Dec 15, 2004
Posts: 174
Ernest you say that JVM implementation will automatically take advantage of the multiple cores.
so if my application is running 10 threads, it is responsibility of JVM.That is what basically happens when you are running a server which can support 25 users. You double the processing power and it might support 50 users within the same time.
Agreed.
But then the article says if you divide up the work of sorting across two threads, then you can nearly double the speed of the sort.
When I divide the work, how do I know both the threads are using same processor or different.
The author agrees that underlying JVM would do that.
So the point is has java.util.concurrent got to do anything with this ? It is JVM which is doing all the work behind the scenes.
This API might help in using thread more affectively than java.util.Thread or Runnable.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

You are overthinking things here.

The java.util.Collections.sort() and java.util.Arrays.sort() methods each sort your data synchronously, in a single thread.

All the article is saying is that you can write your own sort method which creates two threads, sorts half of the data on each thread, and then merges the halves back together; on a multicore/multiprocessor machine, this will generally be faster.

He uses java.util.concurrent to write his two-thread sort, but you can write the same thing without java.util.concurrent. Although the code might be longer and/or messier, it will be just as fast.

java.util.concurrent does nothing magic regarding utilizing multiple cores. All it does is make it easier for you to write multithreaded programs. Since if you want your code to take advantage of multiple cores, then you need to write multithreaded programs, java.util.concurrent is useful -- but for the most part it just hides the same old code inside the API, rather than making you write it yourself.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18529
    
  40

He uses java.util.concurrent to write his two-thread sort, but you can write the same thing without java.util.concurrent. Although the code might be longer and/or messier, it will be just as fast.


It may be just as fast, but quite frankly, unlikely. There are just too many PhDs with too much time to work out some of the stuff in the concurrent library.

For example, the ConcurrentHashMap is segmented to allow multiple simultaneous writes. Each segment is protected by a RW lock to allow multiple simultaneous reads in each segment. The RW lock, which is also in the concurrent library, is written optimistically, without the use of synchronization. And of course, the hashmap algorithm itself...


But to answer the question, EFH is absolutely correct. All modern JVMs dispatch threads to the underlying OS. And all modern OSes, will dispatch threads on all the cores/processors of the machine.

Henry
[ October 05, 2007: Message edited by: Henry Wong ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Henry Wong:


It may be just as fast, but quite frankly, unlikely. There are just too many PhDs with too much time to work out some of the stuff in the concurrent library.


Oh, indeed, but did you look at the article? All he uses from java.util.concurrent is an ExecutorService to fire off two Runnables. I don't doubt that the ConcurrentHashMap has got some serious mojo, but the code in this article doesn't touch anything beyond ExecutorService (it does call Runtime.getNumberOfProcessors(), though). You don't need anything fancy to do what this article describes.
 
 
subject: Does jdk 5.0 API utilize multicore processing ?
 
Similar Threads
JSP Coding Guidelines(Do's & Donts)
Thread
primary key class.
Nice article ...
JSP Spec and Java EE 5