Kunle Olukotun‘s presentation on the work of the Stanford Pervasive Parallelism lab included a diagram where they showed a range of domain-specific languages (DSL) being compiled to a universal implementation language. That language is currently Scala, and in the end all applications end up being compiled into Scala byte codes, which are then optimized and dynamically reoptimized and executed on a particular hardware system based on the properties of that system. Fundamentally, the problem of creating and compiling a DSL, and combining program segments written in different DSLs, is solved by interposing a layer of indirection.

But this idea got me thinking about what the best such intermediary might be for large-scale general deployment.

And my conclusion is that the Java Virtual Machine might be the best candidate. Not the JVM as it is today, though. Here is my idea:

• The Sun Java JDK and its optimized HotSpot VM is now open-source, thanks to the OpenJDK. This opens the door to new innovation based on solid technology.
• The HotSpot is a pretty good VM, and therefore other languages are starting to use it as a potential backend. For example, Python can be compiled to the JVM, as can Ada, and I expect many other language environments to follow suit. The reason is that developing and optimizing a VM is hard work, and if there already is a good one in existence, targeting that is easier than doing you own.
• I think that long-term, this might well replace C as the universal language that you target when you do special-purpose code generators from custom languages… which are really DSLs.
• Thanks to this foreseen ubiquity of the OpenJDK JVM as a universal byte-code execution machine, it will provide a single point of leverage across a large range of applications in a multitude of programming languages.
• As demonstrated by the work of the PPL and the approach taken by RapidMind, the idea of using an abstract byte code for software delivery makes very much sense in a heterogeneous and networked environment. It also provides a good infrastructure for analysis and optimization. It simply is very sensible.

However, the JVM as it stands today is not really suitable for this. It will need some extensions, which I am not the man to invent. With an open-source common JVM, such innovation will be easier to do. Thanks to Sun for opening up Java! For example:

• Support for dynamic languages like Ruby and Python: not the same dependence on Java-type static typing and Java types. They work well for Java, but less so for other languages. It would be nice with lists for real as well, and not just as a library container.
• Support for threads. Not OS threads, but the typical very light-weight threads used in environments like Erlang and OZ. Or even lighter, like the serial units of computations in the kernels of RapidMind and CUDA and similar GPGPU efforts.
• Support for SIMD operations, to express data-level parallelism which is often pretty easy to find on a source-code level.
• Support for data blocking, locality, tiling of some kind, to control data locality. Maybe this already exists in X10 (which I heard about at last year’s Multicore Day).
• Support for communication using messages, and I assume that the best model for expressing the threads is through local data, share-nothing, message passing. With a special case for sharing large data blocks.
• Some kind of data sharing mechanism that is more structured and understandable for a runtime system than pure locks & shared data.
• And a system that takes such an advanced byte code and makes it run well on any particular machine, be it a Tilera Tile, an 8-core P4080, a 128000-core BlueGene, a GPGPU, or a plain middle-of-the-road UltraSparc T2.

So there is some work to be done. But I really think this idea has some merit… if only I had research funding and some good students. Or a crazy VC.

The themes are:

• The way there is to provide programming environments that express algorithms in a way that is clear in terms on intent but that does not constrain the implementation too much. It should hide parallelism to the user, and make that a property of the compiler and implementation, not the program. But to make this work, you need higher-level expressivity. For example, Kunle says that you want to say “do a matrix multiply” rather than “here is a pile of loops and expressioins implementing a matrix multiply”. Very sensible.
• The proper way to do parallel programming this is to be domain-specific. Create domain-specific languages that map to how domain experts think about a problem, and then have a compiler and runtime take care of how to implement it for a particular machine. Rather than provide a low-level language that lets you express parallelism explicitly, like CUDA, Brook, threading libraries, etc, you should be using MatLab if you are doing science (which is something that National Instruments have been doing with their LabView tools).
• Future hardware will be heterogeneous, with a mix of control-oriented simple cores (Niagara-style), data-processing-oriented cores (DSPs, security accelerators, etc.), and the occasional heavy-weight ILP-oriented core (Intel Core 2-style) for the occasional program that just needs maximal single-thread performance.
• Operating systems today were created in an era where processors were precious resources that had to be efficiently shared. This is no longer really the case, it makes sense to dedicate single cores to single tasks for extended periods of time, as this maximizes efficiency. There are cores to spare, no problem on that accord. Nice to hear this from a general-purpose proponent, and not just embedded people.

I fully agree with all of these, and I find the use of domain-specific languages and frameworks especially important. Software people in all ages have become more efficient by designing better languages, more suited for a particular task than a very general language. A language is a just a tool, after all, not a religion (even if some people seem to view it that way), and should be changed depending on the task at hand.

Final note for us embedded folks: when Kunle talks about how he realized around 1995 that lots of simple processors on a chip becoming feasible thanks to Moore’s law, the first real multicore chips were already shipping. Motorola had the QUICC 68000+CPM heterogeneous network processors on the market by then, and Texas Instruments had the C80 four-simple-DSPs-plus-a-simple-RISC multicore chip for digital video also out. But the ISCA crowd really did not notice this development at all, at the time.

Obscure note two: Virtutech Simics was actually used by Afara to help in the design work of the Niagara, since Simics had very good support for 64-bit SPARC architectures thanks to the early work done with Sun.