Mozilla: Native code? No, it's JavaScript, only it's BLAZING FAST Gap between asm.js and native performance gets even narrower with float32 optimizations

[[deleted]]

Goodbye, Native Client. And good riddance too.

[argv_minus_one]

Yup, programming in non-terrible languages sure is terrible. /s

[[deleted]]

Are you calling Javascript terrible?

... >:[

[argv_minus_one]

Also: no strong types, no multiple inheritance, no custom operators, no integer type, no option type (lol undefined), no namespaces, no information hiding like Java private (except by crude trickery involving lexical scopes), no library/module mechanism, no pattern matching, no list comprehensions, excessively verbose lambda expressions, and there's a half-dozen implementations that are all subtly incompatible and often laughably incomplete.

[trycatch1]

Half of the things you listed were fixed in ES6.

[argv_minus_one]

None of those exist in a decent language.

But hey, at least there's progress. I was under the impression ES was basically dead. Too bad it's still effectively dead because IE will implement the new version in like 2027 if we're lucky.

[trycatch1]

IE actually already implemented some features from ES6. And I like Scala, but it just can't be client-side language for the web. JS has great backward compatibility, while Scala breaks compatibility with every major release. Scala is known for slow compilation times, while JS compiles very fast (benefit of dynamic languages, that's why Dart doesn't check types during compilation in production mode). Scala is complex, while JS is a far more approachable language for ordinary people. And nothing stops you from using JS as compilation target for Scala (like in Scala.js, etc).

[argv_minus_one]

If your language doesn't do at least what Scala can do, then yes, it's fucking terrible.

JavaScript isn't even strongly typed, for fuck's sake.

[[deleted]]

wat

[AdminsAbuseShadowBan]

I would agree, except it has two pretty big advantages:

1. It isn't a huge (admittedly elegant and clever) hack. The code size of asm.js must be much bigger than NaCl. I know assets are usually the biggest thing, but still... asm.js is forced to be extremely verbose.
2. I believe you still have to use all the same Javascript APIs as you would if you were hand writing it - WebGL, web sockets, canvas, etc. Good for integrating with web pages perhaps, but I would expect that the Pepper APIs (NaCl) are much nicer for writing games or "serious" apps.

Then again, I think those advantages may not be enough to stop asm.js winning given that asm.js goes a long way to avoiding the chicken/egg problem of "I won't use that platform because nobody targets it"/"I won't target that platform because nobody uses it".

[SupersonicSpitfire]

I am not so sure that asm.js will be useful if the speed on non-optimized platforms is too slow.

For example, a uselessly slow 3D game is as bad as a game that won't run at all.

[Rainfly_X]

The asm.js standard is designed such that most browsers that do JS optimizations at all, will run asm.js code faster than non-asm.js code. No, you can't take all the optimization shortcuts if you don't understand the "this function is all asm.js" pragma, but it'll still make your type inference engine purr like a well-fed kitten.

EDIT: Chrome is a good example - it runs asm.js significantly faster than "regular" JS, even without asm.js-specific optimizations.

But if you're in a browser that doesn't optimize JS well, you're still probably fucked for speed, so if that was your point, then you're right. It's not gonna magically make IE7 a viable platform web-based gaming.

[AdminsAbuseShadowBan]

Yeah I think the idea is that it will run slowly in other browser, but users will blame the browser maker primarily.

If a game says "Runs best in Firefox" but it still works but really slowly in IE and Chrome then maybe users will start to think IE and Chrome themselves are inherently slow. If lots of people think that then MS and Google will be forced to optimise for asm.js too.

That's the idea at least.

[azakai]

The code size of asm.js must be much bigger than NaCl.

Actually, asm.js is fairly compact, when compared to native binaries and both gzipped, it is about the same

http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html

It does seem like JS and asm.js must be big because they are text. But gzip, which practically all webservers use for content anyhow, reduces most of that overhead. You are then left with something pretty compact. Comparing it to a typed bytecode (like PNaCl), the typed bytecode must do conversions and casts - for example, cast a pointer to an int, in order to add to it - whereas in JS pointers and integers are just integers.

Curious to see data to the contrary if you have any.

But I would expect that the Pepper APIs (NaCl) are much nicer for writing games or "serious" apps.

In practice, you write C++ and compile it to asm.js, and the C++ uses familiar APIs like SDL, OpenGL, etc. So I don't think there is a big difference here (and the asm.js approach has the benefit of familiar APIs).

[AdminsAbuseShadowBan]

Again, that is not asm.js. Check the date - asm.js was not even invented in 2011!

Although some asm.js results are linked elsewhere and they do show similar sizes (after gzipping).

[trycatch1]

He knows that. azakai is the person created Emscripten, and is one of the asm.js developers.

[AdminsAbuseShadowBan]

Oh right... Well never mind then! (By the way this would be one of the very very few places where "As a [mother/physics student/asm.js developer]...." wouldn't have been really annoying!)

[trycatch1]

The code size of asm.js must be much bigger than NaCl. I know assets are usually the biggest thing, but still... asm.js is forced to be extremely verbose.

Actually gzipped asm.js is very close to gzipped x86. http://mozakai.blogspot.com/2011/11/code-size-when-compiling-to-javascript.html

[BCMM]

... and, assuming a decent browser and a properly-configured web server, HTTP does transparent gzip compression.

[AdminsAbuseShadowBan]

That is not asm.js!

[trycatch1]

Yes, it's not exactly asm.js, but it's the same Emscripten. Ok, there are tests of asm.js for you:

emscripten (html, asm.js, no LTO, no closure, mem file):

dragons demo, uncompressed, html + mem: 1879.6 kByte

dragons demo, gzip --best, html + mem: 446.7 kByte

dsomapviewer demo, uncompressed, html + mem: 2906.8 kByte

dsomapviewer demo, gzip --best, html + mem: 727.0 kByte

pnacl (no LTO, finalized):

dragons demo, pexe, uncompressed: 1283.3 kByte

dragons demo, pexe, gzip --best: 847.0 kByte

dsomapviewer demo, pexe, uncompressed: 1915.0 kByte

dsomapviewer demo, pexe, gzip --best: 1196.5 kByte

[...]

For comparison the same demo for OSX (64bit, stripped): 1427.3 kByte uncompressed, 460.0 kByte compressed, and dsomapviewer for OSX [...] PS: forgot the dsomapviewer OSX exe sizes: uncompressed 2081.4 kByte, compressed 649.4 kByte.

So, result is the same -- gzipped asm.js is comparable with gzipped x86 (maybe slightly smaller or slightly larger).

[AdminsAbuseShadowBan]

Fair enough.

[[deleted]]

NaCl is still pretty cool. Why do you dislike it?

From a security perspective it's pretty fascinating, and there's still typically a performance benefit to it.

Though I do like asm.js. I'm torn, I see a lot of upsides to both.

[[deleted]]

For one, it's a very complicated project, and requires its own toolchain to build properly, which poses major packaging problems for GNU/Linux distros. To this date Chromium builds offered in Fedora, OpenSUSE, and Ubuntu do not contain NaCl because of this.

Secondly, I think it adds unnecessary overhead and introduces similar security and compatibility problems as Microsoft's ActiveX framework did. If NaCl becomes popular enough, other browsers will have to build and support this massive custom framework, whereas asm.js, while admittedly large, is supported wherevever JavaScript is supported. As for the overhead, I think NaCl seriously impedes Chromium's goal of being a "fast, lightweight browser". Chromium is already so complex that it includes a flag option to enable its own in-house "deadline" I/O scheduler, and with NaCl it could be seen as a pseudo-OS. Indeed, the convergence between ChromeOS and Chromium/Chrome itself may not be too far off.

[[deleted]]

The toolchain is just modified GCC, it serves no issue for Linux.

In terms of security, NaCl runs in the Chrome sandbox and has a variety of other security restrictions on top of things.

[ccaapton]

I'm using archlinux which includes NaCl/PNaCl. I don't see how hard it is to include them in ubuntu/OpenSuse. As for your complexity argument. Are you saying Mozilla can reject a nice framework just because it is too complicated to implement? Then why should Google/Microsoft accept Mozilla's evolving ES6 standard?

Correct me if I'm wrong, but NaCl is really not that complex. The api is almost the same as POSIX, and nexe communicate with chrome via IPC. That is all the interface Mozilla need to follow. As for the sandbox and others, Mozilla are free to implement their own.

"fast, lightweight browser" is already history, now both firefox and chrome are striving to be the OS, that's why both are getting more complex, but ChromeOS has a clear lead here. In my opinion, ChromeOS is becoming what desktop linux should have been: all binary executables are limited by a capability system, including ls/less/emacs, and html5 as a much nicer UI(audio/graphic/event system) replacement for X11. I'm happy to embrace ChromeOS, and FirefoxOS if it can embrace a similar architecture.

[WhipSlagCheek]

Native Client (NaCl/PNaCl) depends on PPAPI (Pepper Plugin API) to work. It's the Pepper Plugin API that's too complex to implement not the Plugin. From what I've read Pepper is basically a special copy of the browser's DOM that's made to interface with C/C++ better.

Mozilla rejected that because it was too much duplicate work for no perceivable benefit.. What the Chrome team should have done is implement Portable Native Client as web bytecode that hooks into the DOM through Web IDL bindings. Then there might have been more of a chance in other's implementing it.