
"Optimizations should be added to V8" for the asm.js subset of JavaScript - patrickaljord
https://code.google.com/p/v8/issues/detail?id=2599
======
sirn
Now this is big. Doesn't this means Node.js would benefit from asm.js addition
in V8 as well?

Few months ago by Brendan Eich: "Get your tums out, pal. We're taking PNaCl
down for good this year with <http://asmjs.org/>. Cross-browser."[1] With the
announcement of Unreal Engine and this, seems like he's one step closer to the
goal. Now only JSC and Trident left...

[1]: <https://news.ycombinator.com/item?id=5226967>

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

~~~
azakai
> 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>

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

~~~
fivealive
> Yet when Google spent only a few months developing the first Dart ... the
> same criticism was leveled at Google from Mozilla.

Yeah right. Dart was originally dash. Before that it was planned modifications
to JS, but nobody wanted to turn JS into Java so you threatened JavaScript
"would be replaced".

Dart/dash/google.js is just open-washing. Nobody outside of Google has any say
in it, and that's why they don't take to it.

~~~
cromwellian
Sigh...

No, Dart had nothing to do with planned modifications to JS, and if you think
it was in the oven for a long time, why then have 2 years passed and it still
isn't shipping in the browser, and the language grammar has undergone many
changes? It's spent an enormous amount of time, the vast majority, in public
development. The Dart2JS compiler was rewritten multiple times from scratch
since then.

I work for the GWT team, which was also owns the Google Closure Compiler.
Simultaneously, at the same time, our team was kicking around taking the
Closure type annotations, and making them actual (optional) grammar terminals
instead of boilerplately JsDoc comments, pretty much exactly what TypeScript
or JSX is today, and then propose those changes to TC39 (one difference is, we
didn't have classes, we had Structural Types). A separate team was working on
Traceur, which was prototyping a different set of changes to JS, and they too
were planning to go the TC39 route. Google is a big company and can have
multiple teams prototyping many approaches. This stuff about turning JS into
Java sounds like religious nonsense from people who have an aesthetic
derangement over classes and OO, there are advocates on both sides, not just
Googlers (and in fact, there are Googlers opposed to classes in JS), and ES6
has been fielding Class proposals. We were testing out how various extensions
"felt" and worked with tooling, for example, Structural Typing in the presence
of recursive types has issues.

There's nothing "non-open" about coming up with language extensions, doing a
prototype implementation, and then putting it out for public review and
drawing up a spec. That's exactly how all of the IETF specs get done -- rough
consensus and running code. Talk is cheap, a proposal is better understood if
it comes with an example prototype. Mozilla does their own prototyping of
extensions to JS, it's the only way to really do a sanity check. Compared to
IronMonkey, no one is under any illusions that something like Traceur was
being pushed as some kind of official product for people to adopt and use, it
was very clearly, a test bed for experimentation.

If we take your definition, no one outside of Mozilla had any say over asm.js,
they developed the complete asm.js spec without involving the public, dumped
it fully formed, along with an implementation VM, emscripten integration, and
even an UnrealEngine demo, all before any standardization activity. The draft
spec has no non-Mozilla editors/contributors listed or acknowledged as far as
I can tell.

One of the real shames here, all the focus on Dart/NaCL, while native apps
distributed on mobile OSes are eating our lunch. I want ChromeOS and FirefoxOS
to be a success, but it is more likely to be a success if Mozilla, Google, et
al can work together, and avoid attacks. It pains me to see this because both
sides are doing tremendous work to move the web forward, and pettiness can
harm spirit of cooperation.

~~~
fivealive
> if you think it was in the oven for a long time, why then have 2 years
> passed and it still isn't shipping in the browser, and the language grammar
> has undergone many changes?

As an outside observer I'd say as a company with basically unlimited money
resources for a decade that Google devs probably are slacking off quite a bit,
not really driven in language design to get anything done.

Asm.js is basically just a spec for what emscripten was already doing. There's
not much too it beyond that other than the linking/module bit, so not much to
even discuss with anybody else. Dash/Dart/Pepper is a major piece of
technology that is not a subset of existing tech like asm.js is. It has a much
higher expectation for collaboration.

~~~
spankalee
So rather than believe that Dart wasn't anywhere near done when it was
announced, as evidenced by the massive changes, 20000+ commits since then, and
the time it's taken to get close to version 1.0, you prefer to think that the
engineers are just slacking off.

Right.

Big disclaimer: I work on that slacker team.

------
sjtgraham
More like "Chrome team member begins discussion for adding optimisations for
asm.js to V8"

~~~
paulirish
kbr is one of our WebGL engineers and while he does interact with the V8 folks
often, he's not the decider when it comes to what goes into V8.

Your suggestion is certainly a more accurate summary. (I'm on the Chrome
Developer Relations team)

~~~
macspoofing
At least it's on the radar, but man, if Chrome picks asm.js up, it's a game-
changer in so many ways.

------
raphinou
Seems there's just an issue opened (less than one day ago) to add asm.js
support. I didn't see any indication that a decision was taken...

~~~
moondowner
The issue is opened by a someone who is involved in the development as well
<https://code.google.com/u/kbr@chromium.org/>

It's not from some random dude on the internet.

~~~
8ig8
True, but see Paul Irish's comment on kbr:

<https://news.ycombinator.com/item?id=5453892>

------
eksith
It's not _just_ for the browser experience. I see all this is a preemptive
move to make developing games (and other "rich experience apps") on Firefox OS
more attractive to new developers. Who knows, we may even have some ports of
existing games for it pretty soon.

Very smart move IMO.

Edit: To clarify. To think that the devs here are interested means the Mozilla
folks got the right idea.

~~~
mtgx
Can you port say OpenGL 4+ games to asm.js and the browser, or will you be
able to use only the WebGL/OpenGL ES 2.0 API for it? If so, then we will only
see mobile/indie games on the web for now, at least until WebGL gets more
advanced graphics API's.

~~~
eksith
Don't see OpenGL 4+ making it to asm.js, but if anything has shown me with my
limited experience in gaming, it's that people don't always flood to games
because of the eye-candy alone. Case in point: Angry Birds.

I think WebGL/OpenGL will do nicely to create a game like Ikaruga
(<http://en.wikipedia.org/wiki/Ikaruga>). It's probably one of the hardest,
but most enjoyable games I've ever played and I think mobile/indie game
developers will pull it off. If anything this opens up a new democracy in the
previously restrictive world (if not outright closed as in iOS) game
development for devices and consoles.

~~~
mtgx
I just wasn't sure whether this is bound to WebGL or not. But even if it is,
it's only a matter of time before WebGL gets graphics API's as advanced as the
full OpenGL (5-10 years).

I think we're already going to see OpenGL ES 3.0 being implemented into WebGL
within the next 2 years, and even if WebGL never adopts the full OpenGL (it
has a lot of cruft anyway), keeping up with the OpenGL ES API's should be good
enough (OpenGL ES 3.0, ES 4.0, ES 5.0, etc).

I was thinking the OpenGL ES will be the future most popular graphics API
anyway (on any platform). It's just that Nvidia announcing full OpenGL 4.3
support for Tegra 5 kind've made me re-evaluate that. But if other mobile chip
makers just stick with OpenGL ES, and WebGL does, too, then OpenGL ES should
still become the most popular graphics API in the next few years.

------
daleharvey
Bit of a tangent, but I couldnt help but think of bus factors when I seen the
comment in the linked thread

"Let's wait to land a patch until Jakob is back."

<https://code.google.com/p/v8/issues/detail?id=2424>

~~~
mraleph
There is not much of a bus factor here.

I filed Issue 2424 and so let me explain: my fix was a very hackish local way
(not the way I'd really like to see it fixed) that just demonstrated how much
of the performance can be gained.

A generic implementation is obviously preferred. I would like to do it myself
but I don't work on V8 full time anymore so I can't dedicate my own time to
it.

~~~
daleharvey
Heh yeh I probably should have put a disclaimer in there since I wasnt trying
to imply that there actually was a problem.

It was just the first thing that popped into my head when I read the comment.

------
Raphael_Amiard
Now i'm gonna say that plain and clear : I don't care which wins, between
PNacl and asm.js, i just care that one or them wins, and gets in every browser
with decent performance.

Both approaches have their merits and drawbacks, I personnally prefer asm.js
because of backward compatibilty and portability, but if we could avoid a 5
years fight about which is gonna bring near native perf in the browser, it
would be absolutely awesome.

~~~
itry
I care who wins and I hope its asm.js

For me, its not _that_ important, that every browser supports it. I have a
large base of Business clients who have no problem, using whatever browser
gets the job done best.

------
kayoone
Smart move, Asm.js could basically be the gate opener for Chrome OS. Suddenly
it makes sense if the OS is just a browser, if you imagine you could run
things like Photoshop, Office or your complete development enviroment from any
browser. Emscripten already has examples of QT apps running in the browser,
this enables a whole new world of web development.

~~~
lucian1900
That's already possible with NaCl, and will soon also be possible with PNaCl.

~~~
lucian1900
Confusing downvote, what I said is factually correct. That's how Bastion,
Angry Birds and I believe Netflix as well run on Chrome OS.

------
soolwan
Whether it's asm.js or PNaCL or something else, it seems that we are headed
towards a future where the client part of web applications is crafted with
compiled languages rather than JavaScript. That would be closer to the way
mobile is now, with the exception that applications are discovered through a
browser. It's starting to feel as if the JavaScript renaissance that we are
having is taking us to a place where actually crafting web applications with
JavaScript is factored out. That would certainly change what it means to be a
front-end web developer. Maybe it will be that JavaScript will still have a
place with very simple document-type content, while heavier applications will
be made with compiled langauges. It's going to be interesting to watch this
unfold.

------
snarfy
I'm just glad this development will allow you to use other languages besides
javascript. Emscripten is cool, but not practical without something like this
standardized. If it can render an Unreal level, it should be able to render a
Qt widget sufficiently. Everything I've seen in this regard so far is inferior
to just using html/css. As this tech develops that may not always be true.

------
fourstar
Javascript (full-stack) will be running at least half of the most popular
websites within 5 years.

~~~
iso8859-1
> most popular

are you talking about the top-10 websites? let's take them one by one:

\- Google. I don't think so, it's not even one of their major server-side
languages now.

\- Facebook. Likewise.

\- YouTube. See Google.

\- Yahoo!. I don't know anything about their server-side

\- QQ.com, Taobao.com, Baidu.com. Given that the Chinese do not pioneer web
platforms, I don't see why they'd do this.

\- Windows Live. I know MS "likes" JavaScript, putting it in Windows and all,
but it's not one of their major languages. It's not even their own :P

\- Wikipedia. Would require a switch from MediaWiki or rewrite. While I'd very
much like to see PHP replaced, it's currently doing it's job. I have a feeling
the language does not matter much, MediaWiki itself is not very complicated.

\- Amazon.com. Don't know.

Do you seriously see 5 or more of these turning to server-side JS?

~~~
jrabone
_\- Amazon.com. Don't know._

Very unlikely; Amazon's backend is basically Perl talking to an SoA via an
internal service definition language. A change to server-side JS would require
a re-write of almost everything (which isn't unprecedented; the migration from
a single giant C++ binary to the Perl system 10-odd years ago was such a
rewrite).

~~~
jsolson
While I agree that it's terribly unlikely, one could argue that having the
services backing the frontend fleet written in JavaScript was "powering"
Amazon.com via JS. There's no technical limitation on what you can build those
services in, so it's theoretically possible.

~~~
jrabone
One could indeed, and again there is some precedent for writing services in
"unusual" languages. However, the service ecosystem, tooling and deployment
was/is entirely custom; they'd need to add support for JavaScript to an awful
lot of internal tools to make it work well. The effort to get _Java_ supported
as a first-class development language was pretty substantial, and over the
years there a number of internal teams with clever names sprung up to try and
change the status quo in one way or another (SVN > Perforce! Ruby > Java!)
with varying degrees of success.

So, yeah, no _technical_ limitation, but explaining to Jeff that you've spent
a year retooling the build system to support node.js but not actually shipped
any features yet might lead to limitations of another sort :-)

~~~
jsolson
> So, yeah, no technical limitation, but explaining to Jeff that you've spent
> a year retooling the build system to support node.js but not actually
> shipped any features yet might lead to limitations of another sort :-)

Indeed, and this is why I agree that it's pretty unlikely :).

During my stint at Amazon we barely had time to build the infrastructure we
absolutely needed to launch features on the artificial deadlines imposed from
somewhere in the stratosphere. How anyone had time to work on paying off
technical debt or building new infrastructure is beyond me.

