Multicore+java? Plz help..Thank You !

Question

Hi Friends,
I have my first project review before the end of this month.I have problem in choosing the topic for my project.I am mostly interested in java,but my guide wants me to do the project in multicore.
i need guidance on this.Please tell me some AIEE,ACE paper or other Research papers,which have to do with both java and multicore---I mean doing something in multicore with java.I Really need help.I tried myself to find such papers in AIEE and ACM but couldn't able to find one.so please help me.
Thank You!

Answer 1

First I'd like to apologize for being pissy earlier. I find it discouraging when I see people embarking on projects that have very little to not merit. Also this discussion has been had before and I dunno... Mostly though I had just come from a bad meeting and was in a bad mood and that really didn't help.
Now on to the constructive bits.
The two newish processor advances that people like to talk about are hyperthreading and multicore. As discussed previously these two are not related (although in marketing materials they often are which leads to some confusion). I do think though that some understanding of both can clear up some of other doubts people have regarding how "good" Java will be with these technologies.
Hyperthreading
Personally I think this one is very cool. The best way I can think to describe it is that it is like a hotspot optimizing compiler for the processor.
What happens with hyperthreading is that the processor has more stuff on the go. The basic idea is this. In a normal processor you might have (simplified greatly here) the following steps to execute an instruction)
1 Bits come in -> 2 bits are put into proper places -> 3 execution (the magic step -> 4 bits are put into proper places to go -> 5 bits go out
Again simplfied but to get the idea. Each step takes a cycle of processor time to do it. In a non hyperthreading model each execution therefore takes 5 cycles. In hyperthreading it loads things up so that different instructions are at different life cycles in the processor at the same time. So maybe you have instructions at steps 1,3 and 5 all at the same time.
This means that in theory things can go much faster. It's also interesting to note though that hyperthreading falls apart with code that has been prematurely optimized for a processor that didn't support hyperthreading. For example if the code tries to force things into processor registers.
Multicore
As mentioned multicore is just putting two or more core processing units on one die. This means actual parallel execution can happen.
This is pretty simple. So what do you need in Java to take advantage of this? Well for starters you need multithreaded code. If your program has only one thread then it won't matter one bit.
Beyond that? It's a combination of the VM and OS yes. There are already computers that have multiple processors of course so there is already existing VM's and OS's that can take advantage of this. There are a number of configuration options for Sun VM's to fiddle with how code should work on such systems.
Perhaps surprisingly, or perhaps not, programs with multiple threads are often better off on one processor than multiple. Depends on load of course but you have to think of steps like synchronization. There is more complexity synchronizing across multiple processors than there is multiple threads on one processor. (Note not more complexity in your code but more complexity in how it is implemented by the VM and/or OS)
Summary
Both of these processor advancements mean good things for Java IMO. Hyperthreading in particular lends itself well to development in a language where runtime optimizations are performed. Why? Because in Java it is prefferred to gain performance by good design rather than resorting to hackery to squeeze performance from the processor directly.
As systems grow more complex it is less and less likely that a specfic program can best judge how to tune it's own environment. Better to let a VM and/or OS and/or hardware to handle the optimization at runtime because it has the full picture of what is going on.
It's like the same reason you really shouldn't call gc in your Java program. The VM knows at runtime far better than you at pre-compile time when it is a good idea to run a garbage collection.
For multicore the same basic rules apply. Write good and well designed Java code and use existing and well established frameworks and it will work well on a multicore system. Write single threaded GUI apps or threading programs that have a tendency to deadlock and the outcome of multicore will be no better performance and possibly bugs that display themseleves with greater frequency.
Further Resources
http://blogs.sun.com/jag/entry/mpi_meets_multicore
http://en.wikipedia.org/wiki/Hyper-threading
http://en.wikipedia.org/wiki/Dual-core