Hacker News new | past | comments | ask | show | jobs | submit login

The conversion from asm.js to native code is much easier than the conversion from JavaScript to native code. The conversion from the real assembly code to native code would be slightly easier than that, but not significantly, making asm.js close to the assembly language (with an infinite number of registers, if that's your concern).

If "ease of converting to native code" is your criterion for "close to assembly language," then Brainf*ck is about the closest to assembly language you can get, because you can write a BF->x86 JIT in about 100 lines of C: http://blog.reverberate.org/2012/12/hello-jit-world-joy-of-s...

So if that's what we're going for, we should forget asm.js and PNaCl and just use BF and expect very close to native speed.

But this won't in fact give native code speed, despite how easy BF is to JIT. Why do you suppose that is?

Huh, I thought it is obvious from the context but I'll restate my words here: It is easier to make native codes from asm.js code than to make native code with the similar performance characteristics from JavaScript code.

It is always easy to get things just work, even while it may mean that printing "Hello, world!" would take minutes. But it is hard to get things work and fast, and there is a certain threshold that it is much harder to optimize once that threshold has been reached. Asm.js have much higher threshold than JavaScript's (and obviously BF's); you can literally replace each line of the already-verified asm.js code with a direct translation with a simple register allocator and it may occasionally (not always, of course) beat optimized JavaScript implementations. Yes, modern JavaScript implementations can optimize the same JavaScript code to that level once it becomes a hotspot! But having a higher threshold changes the problem, for example, time spent to analyze and annotate JavaScript code with hidden types and guards and assumptions can now spent for other optimization passes (e.g. auto-vectorizations).

And you are seriously wrong with BF JIT, you at least have to merge runs of same instructions. (Not to mention other common optimizations, c2bf has only some of them.) Of course it would only matter if you want BF to be fast...

Ah, see, your statements are getting weaker and more qualified, which is what I've been trying to point out.

The original claim in this thread was that asm.js "is native code." This annoyed me in the same way it would annoy an astronomer if you called an asteroid a planet through some chain of tortured logic.

Then OP and others started saying it's "basically the same as native code" because it's "very easy to JIT," but that's clearly not true either thanks to the BF comparison.

So now you're further qualifying by saying ask.js is close to native code because it's easy to JIT "with similar performance." But if I point out corner cases where native code is much faster because of vectorization or use of specialized instructions, you will have to qualify further.

All I am pointing out is that calling asm.js "native code" is inaccurate and misleading. Especially when this is used to imply that asm.js (or PNaCl for that matter) is the be-all end-all answer to giving native code performance. Sure it's a lot closer to native than JS is, but it's still pretty far from actually being native.

> This annoyed me in the same way it would annoy an astronomer if you called an asteroid a planet through some chain of tortured logic.

I think many people just say "stars" while they should say "planets", "asteroids", "stars", "galaxies" etc instead, even when they are well aware that stars are not same as other planetary objects. Well, I think I have made many required qualifications in the second comment as your point becomes clearer. (And I think many others have the similar assumptions, but that's another story.)

> All I am pointing out is that calling asm.js "native code" is inaccurate and misleading.

You are totally right on that. Asm.js is just "a JavaScript subset that can act like a portable assembly language". No performance guarantee here. One can expect the performance boost with the reasonable assumptions but as far as I recall V8 people don't think so. In fact, I'm not that interested in the performance of asm.js but in the potential use of asm.js for non-JS contexts.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact