If you know me very well (or at all), you probably know that I’m not a bit of a framework hater. And the Enterprise Java community is one of the worst offenders in the ridiculously-complex framework department.

So it might surprise you to know how much I love Java, as a programming language. Despite its tendency toward frameworkiness, and despite a few recent warts in the language (autoboxing and generics are both great ideas, but both were implemented incorrectly, adding lots of unfortunate weirdness to the language), I think Java offers a very compelling value-proposition as a development platform.

So I’d like to give a little sumpthin’ back to the community, as my way of saying “Thank You”.

One of the persistent deficiencies of the Java platform is that it fails to take advantage of the advanced hardware optimizations available in the underlying platform.

Since the days of the Pentium III, processor architectures have been capable of parallelizing certain integer and floating-point operations. Using a single opcode, the processor can perform an operation on four different operands, effectively quadrupling the computational throughput for certain types of problems.

With each new processor architecture, more and more of these “Single Instruction Multiple Data” operations become available. These days, it’s nearly impossible to buy a new CPU that doesn’t support some family of SIMD operations. And yet, the Java platform is still unable to take advantage of the SIMD technology.

I’d like to change that.

This is one case where I think it would be a mistake to change the HotSpot compiler. With some processors, there’s a heavy overhead involved with switching from ordinary operations to SIMD operations (and back again) and HotSpot would have to refrain from using SIMD instructions unless the number of operands exceeded some threshold. Moreover, efficient use of SIMD code relies on all of the operands residing within a contiguous block of memory, starting on a word boundary. The way that the JVM allocates memory on the heap, it would be difficult to accommodate the processor’s SIMD prerequisites without overly complicating the JVM.

Instead of monkeying with HotSpot, I think the right answer is to add a new library, with an API for accessing these advanced intrinsic CPU features.

If you’ve ever taken a look at the java.lang.Math implementation, you’ll know what I’m talking about. All of the trig functions in java.lang.Math are actually just references (using a “public static native” declaration) to native functions from the java.lang.StrictMath class, written in C.

I think I could write a similar class (perhaps java.lang.SimdMath) that would delegate all of its functionality to a native C implementation. Arrays of integers and floats would be allocated on word boundaries (using allocation methods similar to those in the NIO classes), and the native implementation would be responsible for handling processor-specific details (like which registers, and which mov instructions need to be used for each different SIMD instruction).

To whatever extent possible, the Java API would unify the functionality of the distinct processors, providing a single set of methods for performing multi-operand math. On processor architectures lacking the necessary opcodes, the API would simulate the functionality using ordinary single-operand instructions.

Not a Product

“But Benji,” I can hear you saying, right about now, “That’s a great idea. And it would be very benevolent of you to do such a thing. But it’s not a product.”

And you’re right.

It’s not a product.

But a library like this would have a huge impact on my professional life. Over the last few years, I’ve developed several probabilistic classification engines. In each case, the classification algorithm performed hundreds of millions of floating-point operations within a tight inner-loop. Having an API of SIMD functions would have given me the ability to significantly speed up some of the critical number-crunching in my applications.

So, although this is not a product idea, per se, its implementation would immediately enable me to put together a number of specialized SIMD libraries that I could sell to other application developers. First on my list would be an API of statistical functions tuned to operate over large data sets in real time.

Pros:

• Development would be pretty straightforward. I’ve done some research into the SIMD architectures on AMD and Intel chips, and although the opcodes are different, there are enough similarities to construct a least-common-denominator API from them.
• Over the last few years, it has become increasingly common for members of the Java community to contribute to the development of core Java features. Through the JCP, I think I could submit a SIMD library and receive a great deal of support from the community.

Cons:

• First and foremost, this is not a product idea. It’s a technology idea. It would certainly open up a few new doors in Java development, and it would certainly provide me with some decent publicity (assuming the JCP submission was accepted), but it wouldn’t directly result in any revenue.
• It’s been several years since I did any C/C++ programming. Back in college, I did a little bit of x86 programming, but it was pretty simple, and I can’t claim to be an expert. Though, to be honest, I’ve read a few SIMD technical documents, and it really doesn’t seem to be that complicated.

…

This is the tenth of 30 business ideas that I’ll be writing about over the course of 30 days. Some of them are legitimate ideas for businesses and product. Some of them are just daydreams about technologies that strike me as cool or handy. One of them will become a product over the next six months, and the foundation of my new software business.

This entry was posted on Saturday, July 1st, 2006 at 10:39 pm and is filed under biz. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.