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?
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...
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.
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.