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

61–70 of 74 posts

Re: Massive: The asm.js Benchmark

#61

Post by azakai »

TazeTSchnitzel wrote: post #60
azakai wrote: post #55

Earlier quoted context omitted.

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

Yes, I think it's a subset, some of the more dynamic things are probably not supported.

Re: Massive: The asm.js Benchmark

#62

Post by cromwellian »

TazeTSchnitzel wrote: post #59
cromwellian wrote: post #54

Earlier quoted context omitted.

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

NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will. You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.

Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.

Re: Massive: The asm.js Benchmark

#63

Post by lmkg »

cromwellian wrote: post #44
StevePerkins wrote: post #25

I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript. All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely wor…

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

I think by a "transpiling solution," he means something that is transpiled from (like coffeescript or dart), as opposed to something that is transpiled to, which is asm.js.

The problem with transpiled languages is that each transpiled solution is just one language. Many of them are nice, and almost all of them are improvements on JavaScript, but they're still just languages. Asm.js basically lets you use anything you want, which is an entirely different category of solution. In particular, it lets you use languages that already exist, for which you have experience and tools and libraries and standards and whatnot.

Re: Massive: The asm.js Benchmark

#64

Post by TazeTSchnitzel »

cromwellian wrote: post #62
TazeTSchnitzel wrote: post #59

Earlier quoted context omitted.

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

NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will. You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs. Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you…

> NaCL isn't creating the expectation that it will run on IE, by saying "it's just JS, it'll run everywhere", you're creating a false expectation that it will.

It's not a false expectation that asm.js code runs on IE, because it does. It doesn't run as fast as in Firefox, but it runs. It runs in Chrome too.

> You're appealing to this to justify why it's better than NaCL without considering the fact that it's not relevant to whether or not it's usable wherever JS runs.

At least going by benchmarks, asm.js is very much usable in non-Firefox browsers, such as Chrome and IE11. For many applications, 100% of native performance isn't needed... if it's 3x slower in IE, then it's not a problem, at least it works. For games, sure, won't run your blockbuster titles, but neither will NaCl just now. It will, however, run plenty of smaller games. The Humble Mozilla Bundle is a good demonstration of this: it works in Firefox, and it works in Chrome

> Game developers already have enough problems with CPU, RAM, and GPU fragmentation, and do this, you want to add another variable, which is they don't even get to control how their code is compiled before it runs. It's a recipe for a customer support headache.

I wasn't talking about games, I'm talking more generally. I don't like (P)NaCl because it reminds me of ActiveX: it is harmful to the open web. But if we are talking about games: I don't see why NaCl is really any less of a headache.

Re: Massive: The asm.js Benchmark

#65

Post by leoc »

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…

> In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.

Doesn't it also has to be valid JS with the same semantics? That has to be a pretty significant constraint surely. It's not like being free to define a runtime and then sending the bytecode as JSON or something. Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".

Re: Massive: The asm.js Benchmark

#66

Post by TazeTSchnitzel »

leoc wrote: post #65
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…

> In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all. Doesn't it also has to be valid JS with the same semantics? That has to be a pretty significant constraint surely. It's not like being free to define a runtime and then sending the bytecode as JSON or something. Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all tha…

> Doesn't it also has to be valid JS with the same semantics?

That's correct, yes.

> That has to be a pretty significant constraint surely.

I don't think it's a terribly problematic constraint. Anything that can be done in C can be done in JS.

> Even leaving that aside, there's the added constraint that asm.js has to be architecture-independent, so it can't map all that closely to the native code for any particular processor. That would put it on about the same level as PNaCL, which is (or at least was) supposed to be the slower fall-back version of NaCl, rather than "native Native Client".

This is true. It's not quite native code or assembly, but it's very close. I suppose asm.js is better compared to C than it is to assembly.

Re: Massive: The asm.js Benchmark

#67

Post by azakai »

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?

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

This was always an issue on the web. Browsers have always had speed differences on that scale - either due to browser optimizations, or running on much weaker hardware (a phone vs. a powerful desktop). We've never had consistency the way consoles do, which is why AAA games run best there.

Re: Massive: The asm.js Benchmark

#68

Post by _random_ »

lmm wrote: post #33
StevePerkins wrote: post #25

I'm often dismissive of Mozilla, for being so all-over-the-map and unfocused sometimes. However, I'm grateful for them being the only browser player that really does seem interested in progressing JavaScript. All of the other players seem more focused on transpiling solutions, which are really about replacing JavaScript with something else under their control. Mozilla is pretty much the only player that genuinely wor…

To me it's just the opposite. Other browser players seem willing to support a diverse ecosystem of browser languages. Mozilla is the one that wants to limit everyone to Javascript (and while you can argue how much they "control" it, it's a language that was invented for the project that's now Mozilla and has many of the same people involved).

> "Mozilla is the one that wants to limit everyone to Javascript..."

True, and they dare to call this "Open Web".

Re: Massive: The asm.js Benchmark

#69

Post by _random_ »

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.

NaCl was basically trying to open web to any language.

Re: Massive: The asm.js Benchmark

#70

Post by TazeTSchnitzel »

_random_ wrote: post #69
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.

NaCl was basically trying to open web to any language.

So is asm.js.
Post reply on HN