JavaScript's sweet spot(blog.mrale.ph)
blog.mrale.ph
JavaScript's sweet spot
http://blog.mrale.ph/post/12396216081/the-trap-of-the-performance-sweet-spot
7 comments
The worse is that people expect such language to perform dumb high-load operations rather than use its expressiveness to conduct chunks of lower-level language to do the dirty job, such as with <canvas> over SVG. R is from an another world, but it is a perfect example how this idea can work very well.
awesome article and a good balance between the "possible" speed of js vs the sacrifice you make in code quality to get that speed.
Well I would not recommend writing code like mr. C to anyone. Unless you really-really-really need every last usec you can get :-)
The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolating speed shown by some project into effectiveness of the whole language.
[also I tried to stress the fact that speed is not everything there is to performance. If you have a long lived webapp in your tab you suddenly might become concerned by memory usage. Which is rather difficult to predict partially because of the "hairy" nature of the heap, the fact that VM tries to adapt to your app but doesn't always get it right, and the cost of the VM itself (e.g. generated code and additional data structures)]
The goal was just to show that sometimes JS code generated by some tool sometimes can be faster than handwritten JS code just because it tries to emulate something foreign (like low-level memory semantics) and thus reducing certain overheads. So one should be very careful when extrapolating speed shown by some project into effectiveness of the whole language.
[also I tried to stress the fact that speed is not everything there is to performance. If you have a long lived webapp in your tab you suddenly might become concerned by memory usage. Which is rather difficult to predict partially because of the "hairy" nature of the heap, the fact that VM tries to adapt to your app but doesn't always get it right, and the cost of the VM itself (e.g. generated code and additional data structures)]
but for some very narrow hotspots in your code it can mean a massive difference :)
What kind of performance increases could we see if we simply added type annotations to Javascript? Would this give the VMs a significant boost?
Something like AS3 (Harmony) syntax:
Something like AS3 (Harmony) syntax:
var foo:int = 3;
var bar:string = "A nice string";
var baz:Array = ["a", "polymorphous", 4, "array"];
var v:Array.<int> = [2,3,4];
function f(a:int, b:string):string {
return a + " " + b;
}
It really depends on the semantics of those annotations.
For example: how is v:Array.<int> enforced (and is it enforced at all)?
Type annotations can be a good to seed type inference analysis or adjust collected type feedback. But unless they guarantee stability of objects shapes (e.g. Array.<float> can contain only floating point numbers) they'll give little.
For example: how is v:Array.<int> enforced (and is it enforced at all)?
Type annotations can be a good to seed type inference analysis or adjust collected type feedback. But unless they guarantee stability of objects shapes (e.g. Array.<float> can contain only floating point numbers) they'll give little.
This is an interesting article with regards to helping the V8 compiler optimise JavaScript code. Often, if C like speed is required, it would be easier to just write C rather than try emulate it through esoteric language features, but I wonder if these kind of compiler optimisations could be included via a language that compiles to JavaScript, such as CoffeeScript, at the expense of readability.
emscripten generates very similar code from LLVM bitcode which in turn was generated (optimized) from say C or C++.
It's next to impossible to emit such code from language that is not statically typed.
Also it's not necessarily going to be faster than handwritten "human" JavaScript. There are a lot of factors in play. That's exactly what I am trying to stress in the blog post.
It's next to impossible to emit such code from language that is not statically typed.
Also it's not necessarily going to be faster than handwritten "human" JavaScript. There are a lot of factors in play. That's exactly what I am trying to stress in the blog post.
I think the OP was suggesting that another language could be used for this purpose, similar in function to CoffeeScript in that it compiles down to JavaScript, but statically typed (or even just straight C). That way most of your app could be written in CoffeeScript or JavaScript, but for those few functions who's performance REALLY matters, you could reach for a different tool that makes writing this inhumane but performant flavor of JavaScript easy.
It's an interesting idea, and having little to no knowledge of compilers, I'd be interested in your take on it. Could emscripten already be used for something like this?
It's an interesting idea, and having little to no knowledge of compilers, I'd be interested in your take on it. Could emscripten already be used for something like this?
Good article. I strongly disagree with this though:
> And implementation complexity is the worst kind of complexity in the world: it leads to subtle bugs that occur on 0.000001% of programs, it leads to unpredictable and hard to analyze performance, it leads to volumes of rulebooks that specify how to appease the compiler
Implementation complexity is much better than interface complexity. It does not necessarily break down subtly. Unlike interface complexity, it is localized.
> And implementation complexity is the worst kind of complexity in the world: it leads to subtle bugs that occur on 0.000001% of programs, it leads to unpredictable and hard to analyze performance, it leads to volumes of rulebooks that specify how to appease the compiler
Implementation complexity is much better than interface complexity. It does not necessarily break down subtly. Unlike interface complexity, it is localized.
Android (VM based language) has the following API:
public View getDropDownView (int position, View convertView, ViewGroup parent)
convertView - the old view to reuse, if possible. Note: You should check that this view is non-null and of an appropriate type before using. If it is not possible to convert this view to display the correct data, this method can create a new view.
The presence of the unintuitive 'convertView' object is caused by the underlying VM and the unpredictable GC nature. This demonstrates that implementation complexity can lead to a complex interface.
IMO the design of the interface is an implementation. A language that is complex to implement will lead to complex interfaces.
public View getDropDownView (int position, View convertView, ViewGroup parent)
convertView - the old view to reuse, if possible. Note: You should check that this view is non-null and of an appropriate type before using. If it is not possible to convert this view to display the correct data, this method can create a new view.
The presence of the unintuitive 'convertView' object is caused by the underlying VM and the unpredictable GC nature. This demonstrates that implementation complexity can lead to a complex interface.
IMO the design of the interface is an implementation. A language that is complex to implement will lead to complex interfaces.
>> Suddenly mr. C gets a call from his boss. “We’ve decided
>> to rewrite our apps in JavaScript. It is pretty fast
>> nowdays, ya know.” says the boss and hangs up.
Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
Umm... Instead of proceeding to rewrite the app and author this blog, the author could have realized that JavaScript (or Scala, Java, Python etc.) could realistically be faster than C and should have explained the same to his/her boss.
Well... You are underestimating the power of sweet spot :-) In a tight computation kernel it's actually possible for JavaScript or any other JIT compiled language given a good JIT to match the performance of C.
Also mr. C and his boss came into existence for a very particular purpose and that purpose is not "JavaScript vs. C" but rather "Normal JavaScript vs. inhuman JavaScript" comparison.
Also mr. C and his boss came into existence for a very particular purpose and that purpose is not "JavaScript vs. C" but rather "Normal JavaScript vs. inhuman JavaScript" comparison.
The boss did not say javascript was as fast as C, but that it was "pretty fast". As in "fast enough", with the advantage of simpler distribution.
And I'd tend to agree, a single order of magnitude difference with C out of the box? That's pretty damn good (it helps that the code is highly numerical, JITs are good at that).
And I'd tend to agree, a single order of magnitude difference with C out of the box? That's pretty damn good (it helps that the code is highly numerical, JITs are good at that).
Typo: could realistically not be faster
is the author a C programmer or a C++ programmer? naming a struct 'Point' is suspicious (instead of 'point' or 'POINT')
yeah, I am sorry, I did not follow C naming etiquette to the letter. You are right: these days I am a bit accustomed to starting struct's names with a capital letter because I do a lot of C++ programming.
(I would not call the struct POINT though because it would feel like something from WinAPI :-))
(I would not call the struct POINT though because it would feel like something from WinAPI :-))