14. July 2013 · Categories: Software

Drew Crawford wrote an interesting analysis about the speed of mobile web apps. Basically the JITs are roughly 5 times slower and the use of garbage collection means that effectively available memory is 4 times lower because otherwise performance becomes way too slow.

The performance impact of javascript is actually worse for data/image manipulation, since 1) you always have range checks for every access and 2) you cannot access that great parallel coprocessor, the GPU, and it is by design. As for memory performance, the only way out would be to move the large objects over to manual allocation to reduce GC overhead. This means using small handle objects under GC pointing to a large native buffer with explicit dealloc.

The big question raised is: when will web apps become good enough? Hardware wise performance per watt for single threaded tasks improves roughly linearly with process size reduction, while parallel performance would ideally raise by the cubic of the reduction. This means that single thread performance should rise enough within the next 4 years. But we now have reached a plateau with regard to raw speed, and the feature width has come down to only 100 silicon atoms. This means that we will see an end to Moore’s Law in the not to distant future. On the one hand, we are nearing the size where quantum effects and simple thermal degradation will become too much; on the other hand the PC crisis shows that many people see performance as being good enough, and this, together with the cloud now available as a backup for the odd difficult job, will reduce demand and so the capital available to fund fast progress. I’d guess that 25 atoms (5.5nm) would pose a limit, meaning only a 16 fold increase in transistor count and 4 fold increase in speed would still be available, so that we will have to rely on software improvements as well to achieve sufficient performance.

There is a limit to how fast we can make JavaScript without impacting safety: We need to guarantee that even a malicious program cannot cause problems, especially that it cannot access memory it does not own. Combine this with a very dynamic language model that makes inlining a pain, and we will need to see some progress in automatic proof techniques to reduce the performance gap to native code. And with the reliance on software, we need to keep in mind that every platform vendor has an incentive to maintain a performance gap to native apps: They want easy access to the web and simple web front ends, but the real work apps should stay native.