• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does jdk 5.0 API utilize multicore processing ?

 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Vinay Singh
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ernest Friedman-Hill
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic