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

Massive: The asm.js Benchmark

hacks.mozilla.org

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Massive: The asm.js Benchmark

#51

Post by cromwellian »

TazeTSchnitzel wrote: post #27
blibble wrote: post #23

Earlier quoted context omitted.

I don't really understand how asm.js is any different... you've still got applications compiled into binary blob, the difference between NaCl and asm.js being that asm.js just happens to be binary encoded as executable JavaScript.

asm.js isn't a binary blob, it's JavaScript. It's not a threat to a web of open standards.

It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago. It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.

When Dart was introduced years ago, Brendan Eich was all over HN complaining about how Dart2JS doesn't solve the problem, because DartVM would be more performance, and introduce a tendency to optimize JS VMs towards those semantics. Well, here we have a different problem. If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.

Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.

Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.

Imagine I took the Java language, removed "new" and forced all code to allocate DirectBuffers, and then said, all classes must consist of static final methods (no polymorphism), and can't have any fields or constructors.

Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.

Arguably, you can say the same thing about Android 4.4/5.0 "ART" runtime, or GWT which I work on. They use the Java "language", but the runtime behavior is completely different, and at least for GWT, we make no bones about this.

So, this is not an attack on asmjs, but I do think there is a distinction between "reusing the syntax" of a language, and creating expectations of new semantics. Languages carry with them implicit sets of runtime performance characteristics, even bugs, that developers tend to treat holistically.

Not many people care about what the specs say. They care about how it runs in the real world.

Re: Massive: The asm.js Benchmark

#52

Post by cromwellian »

TazeTSchnitzel wrote: post #50
cromwellian wrote: post #44

Earlier quoted context omitted.

asmjs is a transpiling solution. No one is going to rewrite UnityEngine in hand-written asmjs. The vast majority of asmjs code is going to be transpiled, you can literally see it in the name: asm

Yes, it is a transpiling solution, but it's one that's a subset of JavaScript. This means it's compatible with all JS engines and lives in the same ecosystem. It's quite different from, say, NaCl or Dart, which introduce a completely new language with a new set of APIs.

Dart the platform is compatible with all JS engines, Dart2JS.

I could rightly claim that DartVM is just a specialized two-stage compiler that kicks in to give a speed boost.

Compatible != portable. In the real world, performance matters. If I deploy my new triple-A game to the Web, and I'm only going to get 60fps on 25% of the browsers, and 15fps on the rest of them, do I really consider it the same ecosystem?

Re: Massive: The asm.js Benchmark

#53

Post by cromwellian »

TazeTSchnitzel wrote: post #49
cromwellian wrote: post #45

Earlier quoted context omitted.

That seems woefully underspecified compared to multithreading in C. Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model? If you want to do safe, performant, multithreaded programming, these things need careful specification, especially in the context of optimizing compilers.

> That seems woefully underspecified compared to multithreading in C. It's not even multithreading yet, it's just a means that support for it might be added. Also, I don't see why you're complaining about it "compared to multithreading in C". To write for asm.js, you write in C . All this is implementation details for how the C compiler (emscripten, probably) will generate its code. > Where's my test_and_set? How do…

pthreads exist in NaCL/PNaCL today, that's the point. There's not many big games on the market today that don't use multiple cores.

Re: Massive: The asm.js Benchmark

#54

Post by cromwellian »

TazeTSchnitzel wrote: post #36
leoc wrote: post #35

Earlier quoted context omitted.

> It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. > I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some brows…

> Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. Older versions of IE won't run normal JS fast either. I hardly see why this is a problem. > Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and run…

>Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.

It's a problem for Web developers anytime there is a huge performance divergence.

Re: Massive: The asm.js Benchmark

#55

Post by azakai »

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…

> No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java.

asm.js is directly relatable to something like C, yes. But languages like C# are possible as well, if you add another step. For example, Unity compile C# into C++, then C++ into asm.js.

This would be even harder for arbitrary JS, of course, as it's much more dynamic than C#. Still, it would be an interesting experiment.

Re: Massive: The asm.js Benchmark

#56

Post by TazeTSchnitzel »

cromwellian wrote: post #51
TazeTSchnitzel wrote: post #27

Earlier quoted context omitted.

asm.js isn't a binary blob, it's JavaScript. It's not a threat to a web of open standards.

It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago. It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment. When Dart was introduced years ago, Brendan Eich was all over HN complaining about how Dart2JS doesn't solve the problem, because DartVM would be more performance, and introduce a tendency to opt…

> It's a blob transpiled from C, not exactly how people imagined the Web working a few years ago.

It's not readable, nicely-formatted JS, sure, but neither is the optimised, minified JS most sites served. It is, however, valid JavaScript. It uses open standards (ECMAScript, the various web APIs). It's already supported by all browsers.

> It's a non-W3C/TC39 approved set of compiler intrinsics/pragmas that switches on special behavior in one particular environment.

It's not "special behaviour". It's a performance optimisation. It still behaves exactly like JavaScript.

> If asmjs takes off and everyone starts writing Web apps by transpiling C code, Mozilla will have forced a sea change in the Web, forcing all other vendors into ahead-of-time compilation to compete, and forcing JS VMs to optimize for this particular kind of code.

I don't see why people would write Web apps by transpiling C code, the main advantage is for the existing codebases written in C. And other vendors don't necessarily need to implement asm.js with AOT compilation. asm.js-conformant code works well very with JIT compilers.

> Now, maybe that's not such a bad thing. I'm not arguing it isn't, but I think arguing "it's just JS, the syntax is the same, therefore it's open!" is somewhat disingenuous. ASMJS, if super successful, would create an implicit implementation spec for everyone. It will have in essence, created a language with identical syntax to Javascript, but with completely different expected execution semantics.

No, it has identical execution semantics. It uses a static subset of JS, yes, but it's still JavaScript. If I remove the "use asm" pragma, the code still does exactly the same thing.

> Why? Because developers would come to depend on ahead-of-time compilation, depend on apps that basically use emulated malloc'ed heaps, etc.

Is that bad? Bear in mind that, without asm.js existing, this was the case anyway. asm.js wasn't created so that people could compile native code to run in the browser. It was created because people were already doing so, and by detecting the code patterns commonly used by compilers, they could make it run faster.

> Call this ASMJAVA. I now assert, this is "Just java", hey, it runs in any JVM. Except, I'm shipping a new VM called "SuperExpresso" that does ahead-of-time compilation for my mobile platform based on this, and I'm telling people they don't need to use native SDKs, they can just transpile C code to Java. Did I create a new standard? I think I just did.

Sure, you made a new standard. It's a backwards-compatible one that doesn't rupture the ecosystem, though.

Re: Massive: The asm.js Benchmark

#57

Post by TazeTSchnitzel »

cromwellian wrote: post #52
TazeTSchnitzel wrote: post #50

Earlier quoted context omitted.

Yes, it is a transpiling solution, but it's one that's a subset of JavaScript. This means it's compatible with all JS engines and lives in the same ecosystem. It's quite different from, say, NaCl or Dart, which introduce a completely new language with a new set of APIs.

Dart the platform is compatible with all JS engines, Dart2JS. I could rightly claim that DartVM is just a specialized two-stage compiler that kicks in to give a speed boost. Compatible != portable. In the real world, performance matters. If I deploy my new triple-A game to the Web, and I'm only going to get 60fps on 25% of the browsers, and 15fps on the rest of them, do I really consider it the same ecosystem?

> Dart the platform is compatible with all JS engines, Dart2JS.

Not quite. Most of Dart (though not all) can compile to JS, and you can then use the JS version or the Dart version depending on browser support. That doesn't mean existing JS engines can run Dart code, it's just you can choose to fall back to Dart compiled to JS.

Re: Massive: The asm.js Benchmark

#58

Post by TazeTSchnitzel »

cromwellian wrote: post #53
TazeTSchnitzel wrote: post #49

Earlier quoted context omitted.

> That seems woefully underspecified compared to multithreading in C. It's not even multithreading yet, it's just a means that support for it might be added. Also, I don't see why you're complaining about it "compared to multithreading in C". To write for asm.js, you write in C . All this is implementation details for how the C compiler (emscripten, probably) will generate its code. > Where's my test_and_set? How do…

pthreads exist in NaCL/PNaCL today, that's the point. There's not many big games on the market today that don't use multiple cores.

Yes, NaCl has them today. What's your point? Yes, that means NaCl is somewhat faster for the time being. It doesn't mean it always will be.

Re: Massive: The asm.js Benchmark

#59

Post by TazeTSchnitzel »

cromwellian wrote: post #54
TazeTSchnitzel wrote: post #36

Earlier quoted context omitted.

> Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. Older versions of IE won't run normal JS fast either. I hardly see why this is a problem. > Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and run…

>Older versions of IE won't run normal JS fast either. I hardly see why this is a problem. It's a problem for Web developers anytime there is a huge performance divergence.

Old versions of IE also don't run NaCl. What's your point?

Re: Massive: The asm.js Benchmark

#60

Post by TazeTSchnitzel »

azakai wrote: post #55
TazeTSchnitzel wrote: post #47

Earlier quoted context omitted.

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

> No, but I'd say it's low-level language specific. C, C++, Pascal, Swift, Go, D and the like. Not C# or Java. asm.js is directly relatable to something like C, yes. But languages like C# are possible as well, if you add another step. For example, Unity compile C# into C++, then C++ into asm.js. This would be even harder for arbitrary JS, of course, as it's much more dynamic than C#. Still, it would be an interesting…

I'm not sure you really can compile C# directly to native code. A subset, maybe, but not C# proper.
Post reply on HN