Massive: The asm.js Benchmark • Hacker News Board

Re: Massive: The asm.js Benchmark

#71

Post by klibertp » Mon, Nov 03, 2014, 10:48 PM UTC

TazeTSchnitzel wrote: post #47

klibertp wrote: post #42

Earlier quoted context omitted.

> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists? asm.js is a compiler target, true. Is it really that much C specific? Isn't it possible to compile parts of JavaScript to asm.js? For example the parts which deal with drawing - computing points of - complex things on a canvas? That would be a good reason for JS devs to use asm.js - of course via a compiler, but if that's…

> asm.js is a compiler target, true. Is it really that much C specific? No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java. > Isn't it possible to compile parts of JavaScript to asm.js? Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however. More seriously, no, not re…

> Yes... asm.js, which is a subset of JS, can be compiled to asm.js. You can compile any language to itself. There's no real point in doing so, however.

Tell this to Google Closure Compiler folks :)

> More seriously, no, not really. JS is a dynamic language. It can't be compiled ahead-of-time.

I don't think that's true. For a counter-example consider Dylan: it's AOT compiled to binary, yet it's rather dynamic. There are many AOT compiled Scheme implementations, and Scheme is rather dynamic, too. I think you can AOT compile everything, it's just a matter of how huge a runtime you'll need to provide. There's probably a point where it's more trouble than it's worth, but in principle you should be able to compile anything. Asm itself is very dynamic language, with dynamic code generation, code rewriting or dynamic evaluation all over the place, so I really don't think there's anything preventing you from doing so. Besides how impractical that would be, of course :)

But I wasn't actually thinking of JS as a whole, but of some specific, computation-related subset of it.

For example, let's assume that I'm writing a function and I promise to only use integers in certain range and arrays with elements of same type and with fixed, immutable length. I promise never to divide by 0, and never trigger overflow, and never access an array out of bonds. It seems very restricted, but actually that's rather common in some domains. Knowing these restrictions I'd probably be able to compile my function to asm.js and have it AOT compiled, bypassing JIT, avoiding some overhead and - most importantly - knowing exactly what optimizations were used (because it was optimized by my "crippled.js" -> "asm.js" compiler).

I think I saw this idea being implemented in a couple of languages, but I don't remember exactly when it was.

Oh, and I have nothing against manual memory manipulation. I rather enjoyed working with asm on some platforms and I'm very fond of Forth. But that's me, I don't expect others to like it too.

Re: Massive: The asm.js Benchmark

#72

Post by beagle3 » Mon, Nov 03, 2014, 11:04 PM UTC

saosebastiao wrote: post #34

TazeTSchnitzel wrote: post #9

Earlier quoted context omitted.

I agree. asm.js has several strengths over NaCl and even PNaCl: * It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today * It doesn't require a new runtime or API, merely using the existing web APIs * It is simple for other browser vendors to implement, and isn't reliant on a sin…

> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough f…

You seem to have your concepts mixed.

asm.js is a compiler that produces portable standard JavaScript output, like CoffeeScript or Elm or ClojureScript, except that its source language is C or C++. The output works on any browser supporting JavaScript, including Chrome and IE. It works very well on Chrome and Mozilla (haven't tried IE recently - old IEs would be slow due to missing TypedArrays and friends, but it would still work).

Yes, the created JavaScript is annotated in a way that Mozilla uses to improve speed (and other browsers can, though they do not yet as far as I know) - but those annotations are still perfectly standard JavaScript that even the oldest IE is not confused by.

The main use that I'm familiar with for asm.js is to make use of an existing C/C++ codebase. See e.g. all of https://github.com/kripken/emscripten/wiki/Porting-Examples-... and especially the utilities section. Rewriting Poppler, GnuPlot, eSpeak or SQLite in JavaScript is no small undertaking - and asm.js makes this rewrite unneeded.

> Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem.

While using the asm.js toolchain may not be trivial (or it may be - I last tried it a long, long time ago), it is only the outputs that are meaningful for end users, and those outputs are already compatible with every other browser. The assertion about a Mozilla only ecosystem makes absolutely no sense.

> and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript.

Those who ignore history are doomed to repeat it. This idea has been aired in some way or another since the early 60s. And yet, every single implementation has failed to deliver on the goals of a "one true VM" (yes, including the CLR, JVM, UCSD p-Code, and tens of other that did gain some traction). The best "true VM" we have today is, surprisingly, x86 and AMD64 bytecode. It has a hardware implementation, which makes it wicked fast compared to all the others - and it is also significantly lower level than any "true VM" proposed to date.

Luckily, Mozilla is learning from history and not ignoring it.

Re: Massive: The asm.js Benchmark

#73

Post by sunfish » Tue, Nov 04, 2014, 3:14 AM UTC

amelius wrote: post #26

sunfish wrote: post #24

Earlier quoted context omitted.

asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1]. [0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

What I'm wondering is what a pointer-dereference would look like. Is every pointer dereference in asm.js implemented by TWO dereferences (one to find the heap, and then one to find the index within the heap)? And are there mutexes (or other synchronization directives) used per dereference in a typical implementation?

It's still being designed, but we're unlikely to do anything that would require a double dereference or synchronization on each access -- that would be a lot og overhead. We'll likely seek a way to keep accesses fast by doing more work at heap resizing time, since heap resizing ought to be infrequent.

Re: Massive: The asm.js Benchmark

#74

Post by rictic » Fri, Nov 07, 2014, 3:40 PM UTC

TazeTSchnitzel wrote: post #39

rictic wrote: post #32

Earlier quoted context omitted.

I don't think it's fair to characterize Traceur or TypeScript as plays to put Javascript under their author's control. Both have been useful for developing ES6, which Firefox has also been a leading implementer of. From my perspective almost all of the browser makers doing lots of cool stuff to push forward javascript and the web.

You're assuming StevePerkins was referring to Tracuer or TypeScript, I don't think they were. I assume they meant things like NaCl and Dart.

A bit of an assumption yes, here's my reasoning though. Traceur and Typescript (and perhaps Flow and AtScript) are similar efforts made by different players that require transpilation and are potential visions for a direction javascript could go in. This combined with the author's quote "All of the other players..." made me think that's the family of solutions they were referring to.

NaCl and Dart are both by a single player and there's nothing else like them that I know about but Mozilla's asm.js, which the author is praising here, so they didn't seem like likely candidates.