Performance matters, but for whom?

Alexander A. Stepanov (inventor of C++ STL):
Computers that were able to deal just with numbers evolved into computers with byte-addressable memory, flat address spaces, and pointers. This was a natural evolution reflecting the growing set of problems that people were solving. C, reflecting the genius of Dennis Ritchie, provided a minimal model of the computer that had evolved over 30 years. C was not a quick hack. As computers evolved to handle all kinds of problems, C, being the minimal model of such a computer, became a very powerful language to solve all kinds of problems in different domains very effectively. This is the secret of C's portability: it is the best representation of an abstract computer that we have. Of course, the abstraction is done over the set of real computers, not some imaginary computational devices. Moreover, people could understand the machine model behind C. It is much easier for an average engineer to understand the machine model behind C than the machine model behind Ada or even Scheme. C succeeded because it was doing the right thing, not because of AT&T promoting it or Unix being written with it.

Yukihiro Matsumoto (inventor of Ruby):

In my point of view, efficiency and productivity are the same thing, because we focus on programming efficiency, not runtime efficiency. I don't care about runtime efficiency. The computer goes faster and faster every year, so I don't really care about performance. Actually, I care about performance when I'm implementing the Ruby interpreter, but not when I'm designing Ruby. The implementer should care about performance, but the designer shouldn't. If you care about performance, you will focus on machines in design instead of on humans. So you shouldn't focus on performance in design.

Stepanov definitely influenced me at the time (early/mid nineties) and I got plenty of mileage out of STL (in spite of c++ compiler limitations) and I found (and still find) STL amazing. I actually never used Java professionally until 2000, tbh - like Stepanov I felt it was unusably slow for my purposes (and it was). However, by 2000 Hotspot had achieved a very impressive level of performance.

Although I can't say the same for Matz and Ruby, I think it's interesting to juxtapose their points of view.

Although I've never actually written a Ruby program, the processing requirements for such must be quite low - since Ruby's runtime performance is unconscionably poor by Stepanov's standards. I guess I can imagine a web server application which is supported by mostly static cached documents and dominated by the file system synchronization of a transactional database could be such a low-performance use case, and that is where Ruby seems to have found a niche.

Programming language compilers are "translators", which we require to translate from human expression to that of the machine.

In my opinion, designing a programming language is always a "mediation" between the needs of the human programmer and those of the machine - contrary to Matz.

Now, given the fact that runtime performance is a factor to the end user (i.e the customer - and the customer always comes first), it cannot simply be sacrificed when required to make the programmer's job easier.

OTOH, if the programmer's burden is too high, runtime performance may never come into question, since you'll fail to even deliver a product.

The design of F3 (now JavaFX script) was largely based on the concept that many perceived programmer ease-of-use features are not primarily related to the typical implementation techniques of so-called scripting languages, but rather to their purely linguistic characteristics - i.e. their correspondence to the language of the mind, rather than that of the machine - and that such features could be provided thanks to the Java platform without severely compromising runtime performance.

Object-orientation is one such feature - it corresponds to the way we conceptualize the world around us and allows us to navigate such concepts in a way that is natural to us.

Interestingly, Stepanov completely rejects this, focusing instead completely on the "generic" processing that applies across collections of objects at very high levels of abstraction.

Admirably in my opinion, Stepanov steadfastly refused to sacrifice the needs of the machine, yet nevertheless produced with STL a level of programming expression which was quite lovely to the human programmer (given that former constraint and those of the C++ language).

The beauty of the Java platform in my opinion has been that it does the best job of mediating these needs, overall, and that largely explains its success.

Java has many detractors on both sides - the C/C++ world thinks it's too slow, the Ruby-and-various-other-scripting-languages world that it's too hard to use. And everybody knows it's long been too big and monolithic.

Now, no one language or platform can be all things to all people. However, it's my belief that the Java platform - in spite of its wide use - is actually still under-utilized for many important use-cases - given current available alternatives.

Obviously, it's clear that I think one of those is the world of high-performance graphics and multimedia, which is currently still dominated by C and C++.

Surprisingly (or maybe not?) a similar tension exists among my colleagues here at Sun with respect to JavaFX script. There are those who actually think they're designing a language to serve (from their point of view) some lesser form of "web scripter" for whom they (incorrectly) perceive performance doesn't matter. Conversely, there are those who are acutely aware of the performance requirements of graphics and multimedia, who are dubious of the necessity and viability of JavaFX script (although they tend not to be forthcoming with any credible alternative, other than "just use Java" - but the fact is that's been done, and the barrier to entry is still too high).

Since I happen to think both points of view are wrong, it's my job to prove that, and to bring us together, and that's what I'm currently working on.

Although its scope is limited, in terms of finding something closer to the right level of "mediation" of performance/programmer-ease-of-use/functionality for this problem domain (and based on the Java platform), a good place to start is here.


It's great to see you highlight Processing (as well as jME). Any reason you left out Pulpcore? I feel it's in the same space as Processing/JavaFXScript except at a much earlier iteration.

I've actually re-discovered Processing again lately with the 1.0 release. They've added a nice audio lib, and everything seems a little more stream-lined. Consider me a enterprise guy by day, media developer by night. It's been a joy to start being creative again.

The goal is really to find the php of media development isn't it? Php scales down so well I'm convinced that was the secret to it's success. Rails and Ruby impose paradigms and structured learning and blah blah blah, the younger dev doesn't care about that crap.

Processing succeeds at being the lowest Java-like barrier to entry- cube(), rect(), transform(), really easy to do very complex things. I think it starts getting hard when you need to coordinate animations sequences and similar timeline oriented ideas.

While I fully intend to get into JavaFX Script, the key thing holding me back has been the language; any good dev will tell you it takes a day to learn the syntax and maybe months to a year to understand how the language really flows. Regardless, I hope to dive into it soon.

That's one reason I really like Pulpcore. From day one, you code in Java, use your fave ide, you already know collections, data formats, serialization, optimization, caching, benchmarking, debugging, no need to wrap external libs in a "plugin" etc etc etc.

Processing would be good to migrate to a Java api- the pre-processor does a little too much to replace the language with a to a simple ant script, but I have hope it will get there.

Posted by Ivan on December 29, 2008 at 01:12 AM PST #


You're right about your colleagues. I really don't know anyone who doesn't perceive performance to be important. I think that was more of a marketing banner people like DHH used to rally developers.

Moreover, your colleagues are confusing high-level goals with a dumbing down of core engineering principles. That may or may not be the case, but trends suggest high-level apis are the way to go. QuartzComposer, Flash, openFrameworks (which draws parallels to Processing as you may know)- all designed for easy access to performance intensive operations such as audio/visual processing, shaders, etc. It's been very late for Java to jump into this and I hope the recent Java media resurgence produces a mainstream set of competitors to these technologies.

Posted by Ivan on December 29, 2008 at 01:35 AM PST #

There are several reasons C/C++ still dominate the graphics and multimedia programming. They all essentially boil down to the JVM (not the language, but the VM) being a poor abstraction of what modern processors can do:

1) Lack of unsigned primitive types. A pixel is almost always some sort of unsigned byte or tuple therefore. Josh Bloch seems to agree that lack of unsigned byte is a serious flaw in Java. If you look through the language performance tests (, almost all of Java's serious losses (factor of 5-10) happen when the code is using byte.

2) Lack of value objects, which leads to incredibly inefficient arrays of small objects. In Java, unlike C, there is no way to allocate an array of a struct that is a single contiguous chunk of memory. A video frame is just that: a big contiguous chunk of memory, usually with pixel values. There is no way in Java to address those pixels as objects and addressing them as byte has its problems (see (1)).

3) Lack of abstraction of types and operations that are important in graphics/multimedia: Single Instructions Multiple Data (SSE). This makes it impossible to write a reasonalbe performing Photoshop in pure Java. It also makes it impossible to write a codec (e.g. H.264) in pure Java. Isn't it sad that JavaFX has to use JNI just to decode video?

It's unlikely this will be heard by the right people or ever change. That makes Java a dead end for multimedia and serious graphics programming.


Posted by Joe on December 30, 2008 at 01:43 AM PST #


Yes, I'm aware of the points you make. However, those are not actually blocking issues in my view.

The intention is to leverage programmable graphics hardware together with underlying/supporting (but minimal) C libraries, not to attempt to reinvent everything in "pure Java".

Unity3d demonstrates a credible (in-browser) game engine built on Mono - and last time I checked the Mono vm was more than 10x slower than Hotspot C2.

Of course in our case this isn't about video games per-se, but rather about multimedia in general - bringing ease-of-use and lowering the barrier to entry for designers and application developers in delivering true, advanced multimedia.

Posted by chris oliver on December 30, 2008 at 02:34 AM PST #

By lowering the barrier of entry, hopefully applications like this below, will become commonplace using JavaFX.

Posted by Mike on January 01, 2009 at 01:46 AM PST #

thank you.very good page.

Posted by çet on May 17, 2009 at 09:20 PM PDT #


Posted by Chat Odaları on May 30, 2009 at 06:03 AM PDT #

Posted by matbaa on June 22, 2009 at 02:58 AM PDT #

Anyone who thinks that faster CPUs will make up for slow code, which is to say poor algorithms, needs to take a course in algorithms.

The overarching lesson they'll learn there is just the opposite- faster computers and more memory will always be dwarfed by the runtime effects of algorithms.

Posted by softwarevisualization on October 25, 2010 at 06:18 AM PDT #

Simple and Nice example !

Posted by شات on December 15, 2010 at 04:03 AM PST #

Editor sicherlich etliche Pluspunkte verd

Posted by beko on January 21, 2011 at 08:22 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed



« August 2016