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.
Update, December 2017: In the four years since I wrote this article, JavaScript execution speed under all browsers has continued to improve. Some typical values that I obtained recently (on the same 2012-vintage MacBook Pro) were 787 steps per second in Chrome, 875 in Firefox, 770 in Opera, and 399 in Safari. The performance isn’t very consistent from one run to the next, and I’m not sure why. I’m also perplexed by Safari’s poor performance, because it does about as well as the other browsers on other computationally intensive physics simulations. The other three browsers are fast enough that it makes sense to increase the number of calculation steps per animation frame from the default 20 up to 30 or even 40. Then Opera typically runs at about 900 steps per second and Chrome and Firefox are a little faster still, rivaling the performance of Java.
Aargh! My Chrome apparently just updated itself from version 27 to 28, and now it's no faster than Firefox.
ReplyDeleteFollow-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.
ReplyDeleteWhy 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.
ReplyDeleteWhile 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.
DeleteBy 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.
Delete