Hacker News Reader

Comment by skywal_l | Hacker News Reader

> It's an example of the truly extraordinary performance of JavaScript. It really does get very close to C/C++ performance

Yes I can attest to that. In my day job I write JS code that processes images in 2D. Processing images, even of a high resolution through simple algorithm is perfectly doable at 60 fps in JS. You just have a to be careful to what you do but that's pretty much true for any language.

Recently, I implemented a bilinear interpolation in JS, C (wasm) and WebGL. The C version was only marginally faster than the JS version even though the whole set of optimization was on. Sure native C would probably be significantly faster but then you wouldn't compare languages but runtimes.

View on HN

But Javascript the language is intrinsically linked to Javascript the runtime. Not sure what you are going for here. I'm not at all the surprised that tuned Javascript can be as performant as pre-compiled Javascript.

To explain further, I'm also not surprised that hand tuned assembler can get the same performance as compiled C.

> I'm not at all the surprised that tuned Javascript can be as performant as pre-compiled Javascript.

Well you must be smarter than I am (which is not saying much).

For my grug brain, an untyped memory-managed interpreted language will be at a significant disadvantage against a typed compiled language whatever the use case. It's a testament to the Chrome dev team's hard work.

It is also possible that the WASM VM has not benefited from as much love as the JS VM.

I have also a bit of a grug [0] brain, but this old brain has become accustomed to the idea that JIT and other optimisation passes can cram out such an insane amount of inference that it will find the fastest code possible. Effectively finding the hand-tuned equivalent. I first got this hunch looking at the JVM. Couldn't hand code JVM instructions which run faster than Java code. But both the hand coded "JVM assembly" and the generated assembly benefited from JIT passes.

What remains then, is compiling to native. This is where C shines and Javascript doesn't. Because of it's data model, Javascript just can't take advantage of what you could do in plain C.

0: This rambling "explanation" is exhibit A

I think parents point is more about that there is nothing making JavaScript (the language nor the runtime) intrinsically slow, but rather the DOM that makes it so the perception of JavaScript is that the language/runtime is slow.

When people bitch about that JS is so bloated and slow, it's usually because of things interacting with the DOM and everything related to it, or just slow network connections. But then people take out their frustrations on the language instead.

Most of my bitching that JavaScript is slow comes from node, which is quite far removed from the DOM. Fast and slow are relative terms, of course, but JavaScript's language features necessitate that it will always be slower than most static, compiled languages. Regardless of runtime. What blows me away is how unsafe the language is on top of being slow, and yet it's basically eaten the world

You're clearly doing something wrong if you seriously think Node is slow. V8 is extremely fast.

I think this is a good point - pure JavaScript code is indeed exceptionally fast. DOM calls do have relatively high overhead, and if the change kicks off CSS recalculation or layout, then that can be even more costly. However that's not representative of the performance of the JavaScript language itself.

> but rather the DOM that makes it so the perception of JavaScript is that the language/runtime is slow.

Not sure what you mean by this. Every time I run something like document.getElementById(), it is very fast.

Is this supposed to be a joke? If not, that's not how you measure performance. Try doing it a million times a second and use actual performance metrics instead of your eyes (which can't tell the difference between 1 nanosecond and 100 milliseconds, so completely useless for determining whether something is slow/fast). Even then just getting the element is clearly not the DOM operations that people are referring to when they say that the DOM is slow.

I'm not sure if the DOM is that slow actually, compared to raw code that can output at any time manipulating the DOM only has produce an update within the next frame for an external observer to perceive it as as fast as possible basically.

Often the problem is probably that people are making too many DOM nodes (no virtualization), talking to the DOM inefficiently via a slow framework (React) and talking to the framework inefficiently (bad code).

Generally I'd say that what you're doing WASM can sometimes be a lot slower than native, but if you're using WebGL to do bilinear interpolation that is something that is entirely on the GPU and is basically free, so it's an odd point of reference?

Looking at the unoptimized code itself, it's getting ~150 MFLOPs which is close to C/C++ in the sense that it's only 10-20x slower than what a single core can do before manually doing any vectorization.

Reply on news.ycombinator.com