Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Asm.js

acko.net

Post reply on HN
Print view View original

181–185 of 185 posts

Re: On Asm.js

#181

Post by jdlshore »

iso-8859-1 wrote: post #138
adamtj wrote: post #83

Earlier quoted context omitted.

Asm.js is not Javascript. It's native code! It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browse…

It's assembly language the same way LLVM bitcode is assembly langauge, which means IT ISN'T. It is also represented in text, which means that it is several times larger than it needs to be. Another problem with Asm.js in practice is that it's used with Emscripten which doesn't define the syscalls you talk about. All the DOM/WebAudio/WebRTC/etc API's have to be redone in Emscripten's headers. GL was easy, because WebG…

> It is also represented in text, which means that it is several times larger than it needs to be.

According to the emscripten FAQ[1], gzipped emscriptem output (which uses asm.js) is about the same size as gzipped native code.

[1] https://github.com/kripken/emscripten/wiki/FAQ

Re: On Asm.js

#182

Post by lifthrasiir »

haberman wrote: post #180
lifthrasiir wrote: post #146

Earlier quoted context omitted.

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 w…

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

Re: On Asm.js

#183

Post by haberman »

lifthrasiir wrote: post #182
haberman wrote: post #180

Earlier quoted context omitted.

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 w…

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 i…

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.

Re: On Asm.js

#184

Post by lifthrasiir »

haberman wrote: post #183
lifthrasiir wrote: post #182

Earlier quoted context omitted.

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 i…

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," b…

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

Re: On Asm.js

#185

Post by goggles99 »

siddboots wrote: post #167
goggles99 wrote: post #164

What would it take to get a standards board to approve a common VM for browsers? I don't see this ever happening. They would in effect be eliminating themselves. They would have to find new jobs or even careers. Once the VM is standardized, what about HTML/JS/CSS. Well who the hell wants to use those slow moving legacy technologies? So the standardization now becomes for python, for C#, for scala and lisp ETC.(and th…

You are overestimating the power that the standards board has over what browser vendors choose to include in their software. What you are asking of them is not really in their power. Besides, if VMs can make the W3C irrelevant, then they will do so regardless of W3C's approval of any particular standard. For what it's worth, we're already very close to the point where "a language creator can sit down and create a new…

You are overestimating the power that the standards board has over what browser vendors choose to include in their software.

Mozilla and Google already want a VM as evidenced by their work. It would not take any convincing to get them there.

if VMs can make the W3C irrelevant, then they will do so regardless of W3C's approval of any particular standard.

Now you're underestimating the power of an established standard. For something to really flourish, enterprise has to adopt it. Without a standard, this will not happen. This is a bit of chicken and the egg scenario.

Post reply on HN