Java: Multi-core Ready or Not? By Jim Falgout
Multi-core is everywhere. It’s all over the news, especially with Intel and AMD recently announcing quad-core offerings. You see it in consumer advertisements in your local newspaper. Even my school-age daughter, who is in the market for a laptop, knows that a dual-core processor machine is what she has to have this holiday shopping season. Big deal, right? Haven’t we had multi-processor machines around forever? We’ve had to deal with multi-threaded programming for years. Besides, won’t my application server handle all of that for me? Lunatic fringe, scientific type super-computing is still a niche and better left to the academics and Fortran and C. Yes? Well, yes and no. More is going on here than just adding a few more cores to your enterprise systems for your application server to handle. Take Azul Systems for example (www.azulsystems.com). They have, currently on the market, a machine with hundreds of cores. Their Vega-2 processor has 48-cores, is 64-bit and so can address large amounts of memory. And it runs Java! Take a gander at some of Cliff Click’s presentations from JavaOne in 2006 and 2007. He tells a great story of how hard it can be to get applications that seemed to be multi-threaded to actually run effectively on a machine with hundreds of cores available. Going from a few cores to hundreds is a big leap. Not all applications are ready to make that jump. Part of the challenge is that the cores in a multi-core system are not quite the same as their single-processor predecessors. As more and more cores are added, cache sizes per core will shrink. Also, the caches at some levels are shared. On the up-side, the cores are much more tightly coupled with extremely fast interconnects. This implies core-to-core communications are faster and involve less latency. How does this affect software? Any concurrent algorithms that depend on large processor caches will have to be re-designed to be finer grained. “Tera-scale” computing, as Intel has defined it, requires rethinking of the entire system software stack. That includes the operating system, JVM and your application. There are a few more twists to this story. So far, Intel and AMD multi-core designs have been implemented such that each core supports the full x86 architecture and instruction set. At some point, a limit on how many of these “heavy weight” cores that can be married together on one chip will be reached. We’ll start to see alternative architectures such as the Cell processor become much more common and commodity. The Cell is a heterogeneous system with a PowerPC chip and 8 specialized processing units that can pipeline frequently used calculations at incredible speeds. This processor is at the heart of the Play Station-3 gaming system. The PS-3 system supports Linux and users are now starting to see the platform as being useful beyond gaming. See the article in Wired about how an astrophysicist clusters several of the game consoles together to create a “super-computer” (Wired article). It is fascinating to see such fundamental shifts in computer technology and where it takes us. But it can’t be a spectator sport. This wave is big and overwhelming. So, what is Java doing to support multi-core and tera-scale computing? - We have the java.util.concurrent packages with more to come in Java 7, isn’t that enough?
- There are also packages and frameworks that support scientific type computing in Java and have concurrent constructs built in. What more is needed?
- If you want hard-core performance, write in C or Fortran.
- So don’t touch Java, it is good enough and that’s not what it should be used for.
Problem solved. That is the prevailing sentiment in some parts of the industry. The thing is: I really like Java. Java is productive. It’s portable. It’s fun. The JVM is powerful and has shown outstanding performance improvements with each release. Using high functioning IDE’s such as Eclipse and NetBeans to develop Java is now part of my everyday work experience. And I’m not alone, Java is not only my personal development preference but it is also the language of choice of vast numbers of programmers throughout the world. So where am I going with all this? Here’s the point: high performance computing (HPC) is no longer the exclusive domain of the few and initiated. Businesses today are moving more and more into traditional HPC arenas, establishing what can be called Commercial High Performance Computing (CHPC). Mix very inexpensive tera-scale computing with whopping big data storage (4 terabyte drives) and a huge data processing capability is now available to even small and medium sized businesses (SMB’s). Businesses that previously have had limited or no access to data mining, business intelligence, operations analysis or other business productivity tools now will find that possible. As we’ve seen in the past, the appetite for compute capability always grows to exceed current capacity. This quantum drop in cost and increase in compute power is a huge opportunity for Java, a language known by most of the programmers inhabiting those companies itching for more processing capability from their software. The whole software stack is impacted by tera-scale multi-core. At the bottom of the stack is the operating system. Given that software is already being written on Linux to take advantage of heterogeneous cores, this part of the stack will be the first to adapt. It already has. Next, let’s look at Java. As technologies such as dataflow become integrated with Java, concurrent programming will evolve and become main stream. Will this require language changes to Java? Perhaps. Technologies such as aspect-oriented programming (AOP) and other byte code enhancement techniques may provide useful language extensions. Scripting languages, both new and existing will also provide the needed constructs, fully integrated with Java within the same JVM. What about the JVM? What will threading look like in a heterogeneous processor world? Will Java expose the ability to run code in threads targeted for different processor types? Hopefully it will, as heterogeneous processor cores will soon become the norm. The JVM writers of the world have big challenges ahead. Based on their success in the past, I’m looking forward to the future of Java. Other References:
Best Regards,
Jim Falgout http://www.pervasive.com/ Jim Falgout, Solutions Architect, Pervasive Software (NASDAQ: PVSW)
As Solutions Architect for Pervasive Software, Jim Falgout is responsible for setting innovative design principles that guide Pervasive engineering teams as they develop new releases and products for partners and customers. Jim is responsible for the architectural design of Pervasive DataRush™, a 100% Java framework that allows developers to quickly build highly parallel, data-intensive applications that take full advantage of multicore. The Beta 2 version of DataRush is available at no charge to developers at www.pervasivedatarush.com. |