Wednesday, July 24, 2013

Java vs. JavaScript vs. Python

At last week’s AAPT meeting I presented a poster showing how fun and easy it is to do fluid dynamics simulations using current personal computers and software. These simulations are computationally intensive, so every bit of performance counts. On the other hand, students and hobbyists and other nonexperts like myself rarely have time to write code that will squeeze every last drop of performance out of our machines. Also, it’s hard to share code written in C or Fortran—the languages of professionals—with other nonprofessionals.

So in recent years I’ve been writing all my physics simulations in Java or Python or JavaScript. And for my poster presentation I decided to clock these languages against each other. I had already written two-dimensional lattice-Boltzmann fluid simulations in all three languages (code posted here), so all I had to do was run them with the same lattice dimensions and measure the number of calculation steps per second. Here are the benchmark results:

This algorithm performs about a hundred basic arithmetic calculations per lattice site per time step, so the Java version, at over 1000 steps per second for 16,000 lattice sites, is performing well over a billion calculations per second on my 2.3 GHz i7 MacBook Pro. I suspect that C or Fortran would run about twice as fast.

All three versions of this simulation include animated graphics, but I was careful to do the graphics in ways that didn’t significantly slow down the computation. In Java, the graphics automatically runs in a separate thread, presumably on a separate processor core.

Since my laptop has four processor cores, I could have sped up the Java version about threefold by parallelizing most of the computation. But that would violate the spirit of this test, which is to see what can be done without getting too fancy with the code. Perhaps Python can also be configured to make better use of my hardware, but I have no clue how to do so (I’m simply using the EPD Free Python installation). I did use NumPy to vectorize everything in Python, since Python loops are glacially slow.

The JavaScript results are shown for only the two fastest browsers, Chrome (version 27) and Firefox (version 22). It seems that Chrome has gotten slightly faster since my earlier tests in March, while Firefox has sped up significantly since then but still hasn’t caught up to Chrome. Both, in any case, offer remarkably good performance at more than half the speed of Java. Safari (6.0.5) is no faster than the previous version, coincidentally about the same speed as Python/NumPy. Opera (12.16) is still far too slow to bother with for this kind of simulation.

Of course, these three languages serve rather different purposes. JavaScript is for web deployment, while Python is for tinkering around on one’s own workstation. Java is fading away as a web platform, but I still like it for personal use when speed and/or interactivity is important.


  1. Aargh! My Chrome apparently just updated itself from version 27 to 28, and now it's no faster than Firefox.

  2. Follow-up on previous comment: Chrome 28 is generally capable of running at least as fast as Chrome 27, but running benchmarks with animated graphics is complicated by the animation mechanism. I was using the requestAnimationFrame function, which lets the browser decide the animation rate. In my earlier tests, the fluid dynamics simulation performed slightly better this way than with the simpler setTimeout function. But now, for some reason, with the parameters I was using, Chrome's requestAnimationFrame function is deciding to throttle me back to only 30 frames per second. I'm not sure if this is due to a change to the requestAnimationFrame function in Chrome 28, or due to an unlucky accident in the relation between the actual performance on my machine and Chrome's algorithm for deciding when to throttle back. In any case, I've added a checkbox to the simulation that lets the user opt for the simpler setTimeout function, and now this seems to speed things up under most conditions. I still can't get it back up to the earlier value of 752 steps per second for the default 200x80 lattice at 20 steps per frame, but under a wider range of conditions the performance is still excellent, and still significantly better than that of Firefox.

  3. Why didn't you publish the speed of VB6. You will find it outperforms Javascript and Python and comes very close to Java in some cases and is faster than Java in others.

    1. While I enjoy making these kinds of comparisons, I'm just one person and don't have time to try out all possible computing environments. Actually, if I were going to try one more, it would probably be Matlab, which runs on multiple operating systems and is widely used by scientists and engineers. And if I had the time to invest in platform-specific coding, I would certainly want to compare C (using native graphics APIs). I suppose Visual Basic would be easier to code than C, but it's still proprietary, platform-specific, and not much used by scientists.

    2. By the way, about ten years ago I made some comparisons between Java and RealBasic, a proprietary but cross-platform version of Basic that is good for GUI programming. I found RealBasic to be about 5x slower than Java at numerical computations, and traced the issue to its slow handling of arrays. Their support people were extremely helpful as I tried to improve the performance of my code, but ultimately that was the best we could do. I eventually decided that RealBasic didn't offer enough advantages to suit my needs, and I have no idea whether its performance has improved over the last decade.

  4. This comment has been removed by a blog administrator.


Not registered? Just choose "Name/URL" and enter any name you like; you can ignore the URL field.