Friday, March 1, 2013

JavaScript and HTML5 for Physics


Like a number of other physics educators, I’ve invested a fair amount of time and energy over the last decade creating educational software in the form of Java applets.

I love Java for several reasons. It’s a reasonably easy language to learn and use, with logical rules and few exceptions. It gives very good performance, typically within a factor of 2 of native code. And, crucially, for a long time it was installed on nearly everyone’s computers, so most students and others could run my applets immediately, without any huge downloads or configuration hassles.

Unfortunately, that last advantage is now disappearing. For one thing, more and more people are replacing their computers with mobile devices that can’t run Java. Compounding the problem, security concerns have recently prompted many people (and companies) to disable Java on their computers. Some tech pundits have gone so far as to pronounce client-side Java dead.

While it’s likely that Java can be kept on life-support for several more years, its long-term prospects appear grim. So it’s time for us Java applet programmers to abandon this obsolescent technology and find an alternative. But is there one?

Until very recently, I thought the answer was no. Sure, I was aware of the new HTML5 canvas element, which allows drawing directly to the screen via JavaScript, right inside any web page, with no plugins. But this technology has mostly been described as a replacement for Flash, not Java, and I assumed that, like Flash, it would mean sacrificing a lot of performance. I couldn’t imagine that a scripting language could ever approach Java’s speed. Indeed, in an early test of a canvas animation a few years ago, I found the performance to be so poor that computationally intensive physics simulations were unthinkable.

I then avoided thinking about the issue until this winter, when the repeated Java security alerts provided an abrupt wake-up call. Apparently knowledgable geeks all over the internet were telling the public to disable Java, insisting that nobody should ever need to use it again.

So I decided it was time to give JavaScript the HTML5 canvas another try—and I was simply stunned. At least under Chrome, I found that graphics-intensive physics simulations run about half as fast in JavaScript as they do in Java. I can absolutely live with that factor of one-half.

My specific tests were with three simulations that I’ve spent a lot of time with over the years. First I coded a basic Ising model simulation to go with the corresponding section in my Thermal Physics textbook. Then I tried a molecular dynamics simulation, similar to the computational physics project I’ve assigned many times and the applet I wrote a few years ago. Finally, encouraged by these successes, I coded a fluid dynamics simulation using the lattice-Boltzmann algorithm, which I learned with the prodding and help of a student, Cooper Remkes, as he worked on a class project in late 2011.

As the following graphs show, the choice of browser can make a big difference. Each graph shows the relative number of calculation steps per unit time, so higher is better in all cases. I ran the simulations on my new MacBook Pro with a 2.3 GHz i7 processor, and also on one of the Windows 7 desktop PCs in the student computer lab down the hall from my office, with a 2.93 GHz i3 chip. Comparing these two machines to each other wouldn’t be fair at all, and comparisons of the three different simulations wouldn’t be meaningful either, so I’ve normalized each group of results to the highest (fastest) value in the group. The browser versions were Chrome 25, Firefox 19, Safari 6, Opera 12, and Internet Explorer 9; all but the last of these are current, as far as I can tell.  (I tried I.E. 10 on a different Windows machine and found it to be only a little faster than I.E. 9, in comparison to Chrome. I couldn’t easily find a Windows PC with Safari or Opera installed.)



The Ising model benchmark tests a mix of tasks including basic arithmetic, if-else logic, accessing a large two-dimensional array, random number generation, evaluating an exponential function, and drawing to the canvas via context.fillRect. By contrast, the molecular dynamics (MD) and fluid dynamics (FD) simulations heavily emphasize plain old arithmetic. The fluid simulation, however, does more calculation between animation frames, uses much larger arrays, and uses direct pixel manipulation (context.putImageData) to ensure that graphics isn’t a bottleneck. The MD simulation seems to be limited, at least on the fastest platforms, by the targeted animation frame rate.

As you can see, the performance of Opera and I.E. on the MD and FD simulations is a major disappointment. Let’s hope the JavaScript engines in these browsers get some big speed boosts in the near future. Safari and Firefox seem to give acceptable performance in all cases, though neither measures up to Chrome on the demanding FD benchmark. Chrome is the clear all-around winner, although it’s a bit disappointing on the Ising simulation under Windows.

And how does this performance compare to Java? It’s hard to make a comparison that’s completely fair, because of differences in the languages and, especially, the available graphics APIs. But in general, I’ve found that similar simulations in Java run about twice as fast as the best of these JavaScript benchmarks.

The bottom line is that if you choose your browser carefully, JavaScript on a new computer is significantly faster than Java was on the computers we were using during its heyday (a decade ago). And of course, for simulations that don’t require quite as much computational horsepower, JavaScript and canvas can also reach the proliferating swarms of smartphones and tablets. I’m therefore a bit puzzled by the apparent shortage, at least so far, of physics educators who are creating JavaScript/canvas simulations. I’m sure this shortage won’t last much longer.

[Update: See the comments below for further details on the benchmarks, especially for the Ising model simulation.]

4 comments:

  1. If you'd like to try the simulations yourself, here are those links again: Ising model, molecular dynamics, fluid dynamics.

    Here are my numerical benchmark results, in steps per second, for reference:

    Ising model on i7 Mac: Chrome 911,000, Firefox 1,018,000, Safari 1,200,000, Opera 765,000.

    Molecular dynamics on i7 Mac: Chrome 1989, Firefox 1929, Safari 1603, Opera 782.

    Fluid dynamics on i7 Mac: Chrome 727, Firefox 386, Safari 240, Opera 40.

    Ising model on i3 Windows: Chrome 297,000, Firefox 465,000, I.E. 567,000.

    Molecular dynamics on i3 Windows: Chrome 1921, Firefox 1136, I.E. 464.

    Fluid dynamics on i3 Windows: Chrome 399, Firefox 298, I.E. 41.

    ReplyDelete
  2. Since posting this report, I’ve done some follow-up work with the Ising model simulation and found that the results are somewhat deceptive.

    First, although my code appears to allow the program’s main loop to run as many as 1000 times per second (by calling window.setTimeOut with a delay of only one millisecond), I’ve discovered that every browser (at least on a Mac) introduces additional delays between iterations. Even when the loop executes just a single Monte Carlo step (which is essentially instantaneous), it gets called only 90 to 240 times per second, depending on the browser. This limiting “frame rate” artificially held back the fastest browsers in my earlier tests, because I was attempting to execute only 10,000 Monte Carlo steps per frame. So I increased the number of steps per frame until the frame rate was between 20 and 50 per second (about as fast as the eye can follow), and got the following results for the Mac browsers (in steps per second):

    Chrome 1,406,000, Firefox 1,524,000, Safari 3,462,000, Opera 863,000.

    Safari now wins by more than a factor of 2!

    I then traced Safari’s huge speed advantage to one specific cause: graphics. Safari is much faster than the other browsers at coloring squares via the fillStyle and fillRect functions. But I already knew that there’s a faster alternative: direct pixel manipulation, in which an array of pixel data is blasted to the screen with the putImageData function. (The fluid dynamics simulation uses this technique.) So I added an option to do the graphics that way, and obtained the following results (again adjusting the frame rate to between 20 and 50 per second):

    Chrome 4,169,000, Firefox 1,679,000, Safari 3,664,000, Opera 737,000.

    Chrome now shoots into the lead, while Safari and Firefox speed up only slightly, and Opera actually slows down a bit.

    As a final test, I increased the resolution of the array from 100x100 to 500x500, so each site is represented by just a single screen pixel instead of 25. This speeds up the graphics quite a bit more, yielding the following results:

    Chrome 12.4 million, Firefox 8.3 million, Safari 6.2 million, Opera 1.6 million.

    Now the browsers’ relative speeds are more like those for the molecular dynamics and fluid dynamics simulations, presumably because calculations, not graphics, are taking up most of the computer’s time.

    I’ve uploaded a modified version of the Ising program that provides GUI controls for making all these adjustments. The default settings, however, are still those that I used for collecting the original data described above. I’ll try to post results for the Windows browsers next week, when I again have access to the machine that I used for my earlier tests.

    ReplyDelete
  3. I now have Windows browser data for the better-optimized Ising model benchmarks, and at this point nobody should be surprised that Chrome is the unambiguous winner. The Windows machine was the same as in the main article above: 2.93 GHz i3 running Windows 7, Chrome 25, Firefox 19, and I.E. 9. The three tests were under the same conditions as for the Mac benchmarks described in the previous comment, always adjusting the number of calculation steps per frame to give between 20 and 50 frames per second. Numbers represent calculation steps per second, so higher is better.

    For a 100x100 grid with graphics via fillRect: Chrome 677,000, Firefox 615,000, I.E. 620,000.

    For a 100x100 grid with graphics via putImageData: Chrome 2,898,000, Firefox 1,144,000, I.E. 102,000. (Wow: 4x faster for Chrome and 2x faster for FF, but 6x slower for IE!)

    For a 500x500 grid with graphics via putImageData: Chrome 7.9 million, Firefox 4.3 million, I.E. 1.1 million.

    ReplyDelete
  4. Follow-up on molecular dynamics benchmarks: Using a slightly different version of the simulation that gives control over number of atoms and steps per frame, I set the number of atoms to 500 and left the rest of the settings at their defaults (atom size 10, gravity 0, time step 0.02, steps per frame 25), and got the following results (steps per second) on my 2.3 GHz i7 MacBook Pro:

    Chrome 30: 990
    Firefox 24: 910
    Safari 6.0.5: 606
    Opera 12.16: 270

    In the earlier test reported above, the faster browsers were being limited by the very high attempted frame rate, and this new test solves that problem. Still, it's interesting that there's less difference between browsers on this simulation than there is with the others.

    ReplyDelete

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