6 ms·

I don't see this as big. Kbr wouldn't in any way be responsible for adding asm.js support to v8. He's one of the core guys on accelerated graphics, but isn't in

I don't see this as big. Kbr wouldn't in any way be responsible for adding asm.js support to v8. He's one of the core guys on accelerated graphics, but isn't involved in the JS engine. Also, you'd be well served to consider anything Brendan Eich claims in the context of his own motivations. Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, relies extensively on engine quirks, and doesn't yet (ever?) address many hard problems like code caching and threading. I'm not saying asm.js isn't interesting, but it's not a guaranteed win either.

derefr 14y ago
> other JS engine developers aren't necessarily enthused about signing on to support a spec that [company] developed mostly in secret without input from other JS engines, relies extensively on engine quirks, and doesn't yet solve many hard problems Wow, where have I heard that before? ;)
- justinschuh 14y ago
  And I would argue that any spec tagged with these kinds of complaints rarely ever sees broad adoption, regardless who made it. From my perspective, the only thing asm.js has going for it that offsets the downsides is that the code at least runs in other JS engines even if they don't explicitly support it. And that alone might actually be enough.
smosher 14y ago
You forgot to bring up his throne of skulls.
azakai 14y ago
> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on https://github.com/dherman/asm.js https://github.com/dherman/asm.js And worked on it there. asm.js has been discussed on IRC (#emscripten and other places), the emscripten mailing list, etc., as we further improved the spec. About the middle last month, we got some performance numbers, and felt we could say something about speed, so I mentioned asm.js in my talk at mloc.js and other more noticeable places, but it was definitely not a secret far before that. > relies extensively on engine quirks That would be a bad bug in the asm.js spec. Can you please elaborate?
- cromwellian 14y ago
  Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. If someone from the Dart or NaCL team had tweeted "2013 is the year NaCL and Dart destroy Javascript!" imagine the uproar. This is about exploring the solution space for solving technical challenges related to maximizing performance, helping developer productivity, and strengthening the Web, and there are many potential solutions. (I for one don't see the "Web" as Javascript, I see it as HTTP, URL, 'drive-by', indexability, transparency, platform independence and location independence. HTML, CSS, and JS are just particular concrete embodiments of those principles, but 30 years from now, they could be implemented in a radically different way) I think asm.js is great for a slice of game genres, and I fully support it. The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves.
  - haberman 14y ago
    Couldn't agree more. I think asm.js is very cool, and very likely a better approach than PNaCl (which I have been a big fan of for a while). But the "take THAT, Google," sentiment is really off-putting. Native Client was never about "take THAT, Mozilla" (or anyone else), it was about serving an unmet need that no one else was serving.
  - azakai 14y ago
    (reversed order of replies) > I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. [..] The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves. I agree. Also, btw, I think NaCl is wrong for the web, but an amazing technology, designed by super-talented people (I met a few). It solves a very hard problem in an impressive way. It already has other use cases than the web, and I imagine will continue to. For the web, however, as I say I think it is inappropriate, due to portability and standardizability concerns (PNaCl solves some of the portability concerns). > Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think a big part of the PR problem Dart has began with the fact that it was leaked. The leak was an internal document, and it spoke somewhat bluntly - which is fine for an internal document, but it was an unfortunate way for it to be revealed to the world.
pcwalton 14y ago
Code caching is being worked on with "FunctionBlob": https://news.ycombinator.com/item?id=5228935 https://news.ycombinator.com/item?id=5228935
mccr8 14y ago
asm.js is not a redesign of JS from the ground up, it is an evolutionary step in improving support for a certain style of Emscripten/Mandreel generated code that Google is at least somewhat interested in, given its inclusion in the Octane benchmark. Performance improved in Chrome on at least one Emscripten benchmark when generating asm.js code rather than the previous backend, without any further change to Chrome, probably because asm.js does a better job at formalizing the various assumptions that this style of code relies on.
gsnedders 14y ago
> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, relies extensively on engine quirks, and doesn't yet (ever?) address many hard problems like code caching and threading It's a spec for a subset of JS with guaranteed AOT compilation — it's hardly one that needs to go through a thousand committees to get somewhere where all those concerned are happy. If you want to do AOT compilation, everyone basically needs the same subset. Indeed, the most contentious part of asm.js is probably how you isolate it off from the rest of the script. It's simply not a spec that defines very much. And what engine quirks does it "extensively rely on"? If it relies upon anything apart from ES5, it's broken and the spec needs fixing. Similarly, it's out of scope for it to deal with anything like code caching and threading — the former is depending on how you tackle it either implementation detail (see how Carakan and V8 implement it today) or something really quite radical to the platform (but not something that needs to be immediately tackled), and the latter is one solution to a broader problem (parallelism in JS). Neither seem like things asm.js should be rushing to solve. An AOT compiled subset of JS is not in itself novel: this is not the first time it's ever been talked about, but what is novel (to my knowledge) is the idea of making compiler behaviour explicit for it, by having a token in code, along with isolating globals. Enabling AOT compilation is in many ways the "golden-grail", as although one must still be weary of compilation time (see SunSpider — many of the benchmarks complete in under 10ms, so you don't have the time to spend compiling them), the warmup time is currently relatively large.

derefr 14y ago

> other JS engine developers aren't necessarily enthused about signing on to support a spec that [company] developed mostly in secret without input from other JS engines, relies extensively on engine quirks, and doesn't yet solve many hard problems Wow, where have I heard that before? ;)

justinschuh 14y ago
And I would argue that any spec tagged with these kinds of complaints rarely ever sees broad adoption, regardless who made it. From my perspective, the only thing asm.js has going for it that offsets the downsides is that the code at least runs in other JS engines even if they don't explicitly support it. And that alone might actually be enough.

smosher 14y ago

You forgot to bring up his throne of skulls.

azakai 14y ago

> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, I don't think that's accurate. We started work on asm.js only a few months ago; at the beginning, we had no idea if it would work, so we just threw around some ideas between each other. When we had something we felt could actually work, we immediately put it up on https://github.com/dherman/asm.js https://github.com/dherman/asm.js And worked on it there. asm.js has been discussed on IRC (#emscripten and other places), the emscripten mailing list, etc., as we further improved the spec. About the middle last month, we got some performance numbers, and felt we could say something about speed, so I mentioned asm.js in my talk at mloc.js and other more noticeable places, but it was definitely not a secret far before that. > relies extensively on engine quirks That would be a bad bug in the asm.js spec. Can you please elaborate?

cromwellian 14y ago
Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. If someone from the Dart or NaCL team had tweeted "2013 is the year NaCL and Dart destroy Javascript!" imagine the uproar. This is about exploring the solution space for solving technical challenges related to maximizing performance, helping developer productivity, and strengthening the Web, and there are many potential solutions. (I for one don't see the "Web" as Javascript, I see it as HTTP, URL, 'drive-by', indexability, transparency, platform independence and location independence. HTML, CSS, and JS are just particular concrete embodiments of those principles, but 30 years from now, they could be implemented in a radically different way) I think asm.js is great for a slice of game genres, and I fully support it. The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves.
- haberman 14y ago
  Couldn't agree more. I think asm.js is very cool, and very likely a better approach than PNaCl (which I have been a big fan of for a while). But the "take THAT, Google," sentiment is really off-putting. Native Client was never about "take THAT, Mozilla" (or anyone else), it was about serving an unmet need that no one else was serving.
- azakai 14y ago
  (reversed order of replies) > I think Mozilla would get a lot more benefit if people stop with the juvenile "You're going down!" adversarial mentality. [..] The cheerleading and politics just isn't needed, let the code, benchmarks, and game demos speak for themselves. I agree. Also, btw, I think NaCl is wrong for the web, but an amazing technology, designed by super-talented people (I met a few). It solves a very hard problem in an impressive way. It already has other use cases than the web, and I imagine will continue to. For the web, however, as I say I think it is inappropriate, due to portability and standardizability concerns (PNaCl solves some of the portability concerns). > Yet when Google spent only a few months developing the first Dart, and then released it to the public, and has been iterating on it for 2 years in full public view, and it still isn't even in Chrome nightlies (yet asm.js has already been dumped into Firefox nightlies) the same criticism was leveled at Google from Mozilla. I think a big part of the PR problem Dart has began with the fact that it was leaked. The leak was an internal document, and it spoke somewhat bluntly - which is fine for an internal document, but it was an unfortunate way for it to be revealed to the world.

pcwalton 14y ago

Code caching is being worked on with "FunctionBlob": https://news.ycombinator.com/item?id=5228935 https://news.ycombinator.com/item?id=5228935

mccr8 14y ago

asm.js is not a redesign of JS from the ground up, it is an evolutionary step in improving support for a certain style of Emscripten/Mandreel generated code that Google is at least somewhat interested in, given its inclusion in the Octane benchmark. Performance improved in Chrome on at least one Emscripten benchmark when generating asm.js code rather than the previous backend, without any further change to Chrome, probably because asm.js does a better job at formalizing the various assumptions that this style of code relies on.

gsnedders 14y ago

> Because other JS engine developers aren't necessarily enthused about signing on to support a spec that Mozilla developed mostly in secret without their input, relies extensively on engine quirks, and doesn't yet (ever?) address many hard problems like code caching and threading It's a spec for a subset of JS with guaranteed AOT compilation — it's hardly one that needs to go through a thousand committees to get somewhere where all those concerned are happy. If you want to do AOT compilation, everyone basically needs the same subset. Indeed, the most contentious part of asm.js is probably how you isolate it off from the rest of the script. It's simply not a spec that defines very much. And what engine quirks does it "extensively rely on"? If it relies upon anything apart from ES5, it's broken and the spec needs fixing. Similarly, it's out of scope for it to deal with anything like code caching and threading — the former is depending on how you tackle it either implementation detail (see how Carakan and V8 implement it today) or something really quite radical to the platform (but not something that needs to be immediately tackled), and the latter is one solution to a broader problem (parallelism in JS). Neither seem like things asm.js should be rushing to solve. An AOT compiled subset of JS is not in itself novel: this is not the first time it's ever been talked about, but what is novel (to my knowledge) is the idea of making compiler behaviour explicit for it, by having a token in code, along with isolating globals. Enabling AOT compilation is in many ways the "golden-grail", as although one must still be weary of compilation time (see SunSpider — many of the benchmarks complete in under 10ms, so you don't have the time to spend compiling them), the warmup time is currently relatively large.