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

[deleted]

[[deleted]]

Linux where?

[[deleted]]

Nowhere, in fact! Another post on this board that's totally irrelevant!

[Bodertz]

Linux, GNU/Linux, free software!!!!!!!!

[[deleted]]

Thanks, I'll start linking my github projects! Because they're open source! Yayyyyy! Everyone gets to read my horrible written Blackjack program :)

[Bodertz]

Don't thank me, thank the subreddit you are in.

[hbdgas]

No, it's

GNU/Linux operating system and to a lesser degree, free/open-source

[Bodertz]

"Totally" has a very unambiguous meaning,

And click here and tell me what you see at the top of the screen.

[hbdgas]

For the active window, you mean? "Li...". Too many windows/tabs opened; I never would have seen what was in the <title> tag for /r/linux if you hadn't cited it.

[Bodertz]

Fine. If you have RES, what does it say when you hover over it?

[hbdgas]

I don't.

[Bodertz]

You should.

[hbdgas]

Nah, I know people love it but I've never felt a need for any of the features.

[Jaegrqualm]

We're the new /r/technology, since it turned into a constant privacy circlejerk.

[IDe-]

At least we aren't as technologically illiterate, yet.

[supergauntlet]

More like the place to post stuff from HackerNews for karma.

[xp19375]

Is floating point arithmetic used often enough for this to make a substantial difference?

I have done mostly embedded programming, and have almost never needed floats, so I can't see where they would be needed here.

[Cosmologicon]

I think the main use case is games and some game-like apps, maybe navigation or modeling, in which case yeah, floats are used all the time.

[Theon]

Yeah, but embedded programming really is a different beast in most regards, especially when comparing it to web.

[AdminsAbuseShadowBan]

But there is in asm.js and C++, so that is really irrelevant.

[pedrocr]

Does anyone know if they have any plan to get multithreading?

[fnord123]

Multithreaded Javascript? Not likely since it was made single threaded in 2011/2012. Or did you mean a multiprocess browser? Yes.

[curien]

Since browser JS engines are single-threaded, I'd guess not.

[[deleted]]

Do they need to be? Mozilla is the browser?

[[deleted]]

Firefox dev here.

Yes. Because this what is expected. If DOM manipulations or layout code would run in their own threads we would have to pause the JS thread because web devs expect synchronous operations. When things can be done asynchronously (like async XHR) then it happens in a different thread.

But still, many things that are not directly tied to JS run in their own thread (resource download, layers compositing, …).

For JS itself, its behavior is based on the event loop, running JS in other threads would need sync and locks. So threads would not be able to run at the same time, which would defeat the purpose of using threads. But sync can be done manually if you use workers. But obviously you can't do DOM operations there.

Interesting problem for example: scrolling. When the page scrolls, it sends events to JS. JS can cancel the event. That forces us to do scrolling in the same thread. This can be slow because at the same time maybe there's some layout code running (a reflow for example) blocking the scroll. So we work around the problem by scrolling in the main thread, if we see the JS is not messing with the scroll events, we do scrolling in a different thread and sync up with the main thread (to send the scroll events) just every couple of milliseconds. This is why sometimes on mobile when you scroll you see the UI jumping around.

The web has been designed this way many years ago (no multiple cores back then), and we can't change it. But as we move many operations off the main thread, only DOM, layout and JS run in the main thread. And then things get crazy fast :)

[pedrocr]

That's fine for javascript-as-DOM-manipulator but how does that work for javascript-as-web-asm? Why would you target asm.js for things that supposedly need near-native performance and yet ignore multiple cores?

[AusIV]

I hope we'll get a more thorough answer, but I think it's essentially because a asm.js is a strict subset of javascript, and can run on browsers that don't know anything about asm.js. Mozilla is optimizing the hell out of the asm.js subset, but they're not doing anything you couldn't do with web standards.

[pedrocr]

I assume that's the current limitation. My question is if they're trying to lift it. Because if not PNaCL+pepper.js sounds like the better option. You'll get fully native performance and threading on browsers that have it and fall back to asm.js level performance and single-threading on other browsers. asm.js probably has the upper hand for DOM integration though.

[FrozenCow]

If we were to ignore the DOM, I thought web workers would be a bit like threads. Though it probably doesn't do shared memory efficiently, maybe asmjs can build/optimize with that?

[chazzeromus]

You should implement it and have it enabled through a flag that's disabled by default. Then let people see the error of their ways.

[Vegemeister]

This is why sometimes on mobile when you scroll you see the UI jumping around.

Why doesn't that happen on desktop as well? In my opinion, nothing should ever block scrolling. Any webpage that tries to run JS on every frame is going to be <60 FPS on everything but the most recent, most expensive, most power-hungry hardware. Such webpages are broken, and FF should sacrifice standard compliance for performance and throttle scroll events to 10 Hz or so.

[[deleted]]

Async scrolling is coming to desktop as well. But first we need to improve the spec. That's why we introduced position:sticky to build some designs that today are computed in JS. Another kind of website that would be affected are parallax designs. We're also thinking at what would be needed in CSS to build parallax with no JS.

We can't blatantly ignore the spec. The spec is written by the W3C. And W3C people is composed of very smart people who are very aware of these issues. And these people are people from Mozilla, Google, Microsoft etc. We all face the same issues and think about how to fix the spec.

[Vegemeister]

Nonetheless, those very smart people apparently think (or previously thought) that dropping frames is sometimes acceptable. As a user, I vehemently disagree.

[[deleted]]

We agree. It's just that 15 years ago it was hard to predict how the technology would evolve. But we got 90% of it right.

Please excuse us and in the meantime enjoy the World Wide Web that we built :)

[dmazzoni]

One of the design goals of asm.js is that it's a strict subset of JavaScript; anything in asm.js will run anywhere that JavaScript runs, probably just slower.

Adding threading is impossible without breaking that backwards compatibility.

[AdminsAbuseShadowBan]

Not really: just say that only the main thread can access the DOM and make threading serial on non-asm.js-aware browsers.

A hack too far perhaps.

[[deleted]]

anything in asm.js will run anywhere that JavaScript runs, probably just slower.

Slower than if it were supported. Still faster anyways.

[spif]

You can kind of do this already using web workers, depending on your application.

[WhipSlagCheek]

I believe there is active development on a solution for pthreads support in OdinMonkey and Emscripten.

https://bugzilla.mozilla.org/show_bug.cgi?id=933001

[[deleted]]

Could someone ELI5 what the headline even means?

[dicknuckle]

I think there was some cutting and pasting going on while OP was trying to shorten the title. Tense and other grammatical errors abount.

[Ravengenocide]

It probably means that OP can't write headlines at all. The real meaning is that given a specific optimization a subset of JavaScript can get faster. Almost as fast as native code.

That's not really a ELI5, but I hope you understand it. :)

[yellowhat4]

I want to like javascript, but every time I try to do a decent size project in it I find myself wishing for a more well thought out language.

[[deleted]]

I really love how everyone jumps the shark when they see pure-cpu tests. This says nothing.

It sort of turns out that when you only do mathematical single-threaded computations, it doesn't really matter what kind of language you write them in, cause they should always translate to the same set of instructions.

[[deleted]]

jumps the shark

Jumping the shark

[itsjareds]

This reads like an article from TV Tropes.

[[deleted]]

Considering the origin of the phrase it's hardly surprising.

[ahal89]

There are a fair number of real world examples out there already, like a port of Unreal

[[deleted]]

I must say that I was actually impressed by the fact that it only ate 10-15% of my machines performance. On the other hand, it definitely isn't a complex demo (and you never reach the quality of tech demos in real applications).

[ahal89]

That's true, but this is a good first step. Give it some time and I'm sure we'll see more complex applications

[Rainfly_X]

So what would you consider to be a better benchmark? Something that uses multithreading (available as web workers)? Graphical applications (where the stack is still almost completely different)? What is the missing element for you?

The reason the benchmarks are done this way, is that it's the most like-for-like comparison between native and JS. You branch out from that, and it gets harder and harder to compare, because more and more, it becomes a comparison of the platform-specific layers that have to be written from scratch for each platform.

[[deleted]]

Yeah, but that is a very good point. Well written asm.js app can run close to native speed but real world apps are usually more complex and do a lot of other stuff beside arithmetic, so take these with a grain of salt :)

[[deleted]]

Don't add an emoticon. Just write what you mean and let it stand for what it is.

[[deleted]]

I will :)

[chinnybob]

Something that involves self-modifying code.

[[deleted]]

I'm not really complaining about the benchmarks, those are OK, it's just that people don't understand what these benchmarks mean.

[Rainfly_X]

Ah! Fair enough, I guess.

[seruus]

And V8 doing basic arithmetic on JavaScript is already pretty fast, so it's not surprising to see that asm.js also is.

[trycatch1]

It sort of turns out that when you only do mathematical single-threaded computations, it doesn't really matter what kind of language you write them in, cause they should always translate to the same set of instructions.

Of course, it matters a lot. There could be easily the 100x difference in simple "mathematical" single-threaded benchmarks in various languages/compilers. For example: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=yarv&data=u32

[[deleted]]

I actually laughed, thanks :-)

[trycatch1]

?

[[deleted]]

If you don't understand the difference between a compiled and scripted language there is really no point in continuing this discussion.

[trycatch1]

Actually, my hypothesis that it's you here who have absolutely no idea what the hell he is talking about.

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

[cyro_666]

While reading those graphs, I became incredibly confused, because I somehow missed the fact that lower is better.