IDF - confronting the Java bias in Intel
Posted August 25th, 2008 by steveh
My boss and I attended the Intel Developer Forum last week in SF. There were 6100 attendees, and an amazing array of special Intel hardware initiatives discussed and exhibited, from extending battery life, to embedded systems, to visual computing to 3D movies. The explosion of new hardware development was awesome.
We did not get a lot of traffic to the DataRush booth, but those who did stop and talk to us were more knowledgeable than usual. Our purple pens are very attractive, and our booth and collateral are really excellent. I did not get any questions that I could not respond to, and I did collect a few cards. But IDF is not a software show, obviously.
We went around on Tuesday and asked Intel people why there was an apparent bias against Java. The stock answer on Tuesday was that Intel doesn’t like the JVM sitting between the app and their chips. But on Wednesday morning, Intel announced support for Microsoft’s C & C++ on .Net, which clearly made that answer inoperable.
On Wednesday afternoon, I attended a roundtable where people from Intel Research and UC Berkeley (the program that Intel and MS each funded with $20million to advance the teaching of parallelism in Computer Science) were taking questions. I asked about Java, and was given the JVM answer. I grabbed the microphone back and pointed out that that answer was no longer was valid, and the Intel researcher then asked for help from a person in the audience, who turned out to be James Reinders his-own-self.
Reinders made two points: Intel is resource constrained and so can’t support everything, which made people in the audience laugh, and second, that Java developers did not need their help.
He stated that when they offered support for Java, they got little response, and concluded pretty decisively by stating that Java support was not on their list.
On Thursday, they held a session where the smartest people in Intel, the Intel Fellows, took questions. Once again I staked out the microphone, and once again asked the question. This time, I included the .Net support in my question, and framed it more directly, something like “Given that Java is the most popular language in corporate IT, when will Intel add its support for Java developers seeking to develop multicore apps?”
The Intel Fellow in software said only that he would refer this issue to James Reinders.
So the good news is that we got to the right person, twice. The bad news is that we got the wrong answer from that person. But as we all know, the key to BusDev is to keep asking the question of different people until you get the answer you want, and we will continue to do that. Our challenge is more clear than before, which is a good thing.
Do you think that a Java version of Threading Building Blocks would be helpful? Is Reinders correct, that Java developers don't need Intel's help?
Trackback URL for this post:
http://www.pervasivedatarush.com/trackback/246
I received this anonymous comment in my email:
The Java programmer's equivalent of TBB is basically java.util.concurrent, a package in the standard JDK. Doug Lea is BDFL (Benevolent Dictator for Life) here by popular acclaim.
The task-based parallelism provided by the Executor framework in java.util.concurrent is particularly close to the programming model I've seen advocated in TBB videos. Task-based parallelism in Java will take another long step forward with the Fork/Join framework (also from Doug Lea), available as a free download today, and due for inclusion in java.util.concurrent with Java 7.
The more-heat-than-light Java closures debate is largely motivated by a desperate need for a better syntax for expressing task-based parallelism. C++ doesn't have closures (yet), but it does have pragmas, macros, templates, and operator overloading (all features deliberately cut from C++ when Java was designed). Different ways of exposing TBB to the programmer can take advantage of any or all of these C++ language features. Any "port" of TBB to Java would look a lot like java.util.concurrent by the time you stripped off the language features that helped the C++ programmer.
The Java way is a portable language with portable libraries, and the Intel way is to bind code and its developers to their hardware. This is a fundamental tension. If Intel wants to play by Java rules, they have to work with JVM vendors to help them optimize the implementation of the standard language and standard libraries, so that JVMs on Intel hardware outrace all other JVMs. I gather that they are already doing such work. Does this include close collaboration with JVM vendors to take advantage of TBB inside the implementation of java.util.concurrent?
Steve -
Maybe a third time will help. :-)
If not - don't give up, we're more interested in understanding what we could do to help with Java than you let on. We just haven't figured it out - if that means we are dense - I apologize.
I actually think a Java version of TBB could be very helpful, and persons with an interest should talk with us - and the TBB project - and let's do something together! http://threadingbuildingblocks.org
Technically speaking - our use of templates to create TBB interfaces is a challenge in Java, so a "port" to Java would take some creativity.
Myself, and other Intel developers, have experienced a much more lukewarm response to threading in Java - we THINK this is because Java takes advantage of parallelism very often by methods other than threading (like running many instances). We've had no such challenge finding many C/C++ developers rushing to thread - and, as I mentioned at IDF, I figure it is only a matter of time with Java. I was hoping my comments would cause more Java programmers to find me, and tell me I'm wrong - and help start a movement to port TBB to Java, or point out more things we should look at doing. I think I was not clear enough on this when I answered you - and I was guilty of leaving too quickly after the forum because I had another commitment at IDF immediately afterwards.
As was mentioned also, we have found productive ways to help Java vendors use parallelism in their JVMs. Not the same, but it helps Java.
I intended my comments to encourage people who see things in a different manner - to help me learn, and in turn help Intel learn how we can help.
One final note - Intel Parallel Studio, is squarely aimed at C/C++ developers, not C#. On Windows, that means working in a ".NET" world, but it doesn't imply that we've picked C# over Java. That's a different debate - and one we didn't answer with Intel Parallel Studio.
I'd love to hear more from developers who like Java and want help threading, and esp. any interest in looking to port TBB to Java.
James Reinders, Intel