Asm.js Gets Faster
mikejuk writes "Asm.js is a subset of standard JavaScript that is simple enough for JavaScript engines to optimize. Now Mozilla claims that with some new improvements it is at worst only 1.5 times slower than native code. How and why? The problem with JavaScript as an assembly language is that it doesn't support the range of datatypes that are needed for optimization. This is good for human programmers because they can simply use a numeric variable and not worry about the difference between int, int32, float, float32 or float64. JavaScript always uses float64 and this provides maximum precision, but not always maximum efficiency. The big single improvement that Mozilla has made to its SpiderMonkey engine is to add a float32 numeric type to asm.js. This allows the translation of float32 arithmetic in a C/C++ program directly into float32 arithmetic in asm.js. This is also backed up by an earlier float32 optimization introduced into Firefox that benefits JavaScript more generally. Benchmarks show that firefox f32 i.e. with the float32 type is still nearly always slower than native code, it is now approaching the typical speed range of native code. Mozilla thinks this isn't the last speed improvement they can squeeze from JavaScript. So who needs native code now?"
Umm, anyone who wants their code to not run substantially slower. Seriously, do you front end programmers really think nobody does numerical simulations or other performance-sensitive work? In my line of work, I'd kill for the opportunity to make my code 1.5 times faster!
The idea of compiling to JavaScript has been done a lot. Microsoft Labs had a project to take CLR codes and compile down to JavaScript. It was abandoned as too slow. I'm sure improvements to the JavaScript engines have made it more feasible. But, as noted the lack of certain native types and immutable data types (i.e. DateTime) forces a ton of static analysis to be done just to figure out that hey, that variable could be an plain integer. And it has to be conservative. Much easier to just have integers and be done with it.
If there is such an insistence on making the web an application platform for everything, then I think at some point you just have to standardize on a VM. Yes, yet another one. So, you can use Dart, JavaScript, Scheme, C#, Java, whatever there's a compiler for. Treat the DOM as core API and enjoy.
Personally, I just hope people realize that operating systems have been doing this well for years, that sandboxing isn't unique to web browsers and that "native" applications are actually a good thing.
The mobile app thing gives me a bit of hope, but it's sad that people seem unwilling to download a installer from the web from a trusted source and install it. I find it a bit strange that people are turning to the web to solve a problem that the web greatly expanded the widespread propagation of viruses and other malware.
And what people are surprised by is a bit baffling as well. A web browser isn't magic. Being impressed that you can run Doom on a modern web browser is missing the forest for a tree. I could run Doom on my computer for ages now. Me having to visit a URL to do so isn't not a major actual change nor improvement, despite the technical accomplishments that went into it.
Anybody who writes performance-sensitive code other than trivial contrived benchmarks.
Update the ecma standard to include a set of features that is meant to be used when compiling a better language (C#, C++, Java, Perl, Python, LISP, Haskell, x86 asm, MUMPS, pig-latin, etc) down to javascript so it will run in any browser. Then I think everyone will be happy.
Fixed that for you ;-)
asm.js is not javascript though, its a specific subset with restricted coding rules that allow the compiler to do its stuff. General js will be just as slow as any of the other script languages.
JavaScript always uses float64 and this provides maximum precision, but not always maximum efficiency.
That doesn't make too much sense to me, I thought that typed arrays have always had 32-bit floats as an option. Why should 32-bit storage (on-heap typed arrays) and 64-bit registers (scalar values) be significantly slower than 32-bit storage and 32-bit registers? I thought the performance discrepancy between singles and doubles in CPU float units disappeared a decade and a half ago? (Or are simply single-to-double loads and double-to-single stores somehow significantly slower?)
Ezekiel 23:20
If LuaJIT 2.x was *ten times* slower than C for you, perhaps you were doing something wrong?
Ezekiel 23:20
The person writing the javascript engine.
Unless it's implemented in asm.js
It's JavaScript engines all the way down, man...
Actually this has nothing to do with javascript.
ASM.js is a java VM like technology which compilies code in C++ and Java to javascript which then uses a JIT compiler.
This could be very usefull for things like Citrix or crappy activeX like functions being made available to mobile devices and browsers. Useful yes, but like java and activeX a big fucking security hole if not done right.
I think ASM.JS is dead out of the water as Google refuses to support it. Google wants you to use Dart and Google Chrome apps that run near native speed and require a Google ecosystem. MS wont support it either as it gets rid of the dependancy for Windows and crappy Metro apps.
I think Google is turning more into the IE of the late 1990s as it is becoming so standard now.
http://saveie6.com/
Not mainframes, more clusters. All the stuff used for reconciliation and position management uses pure integer and fixed point maths. Market makers like pushing floating point numbers around, but that's just for quick profit calculations when doing the trades. At the end of the day, everything's reconciled with precise maths.
Emscriptem is a technology that compiles code in C++ to javascript. Asm.js is a restricted subset of javascript that is much easier for the compiler to handle.
Google wants you to use quite a few different things, probably the 'best' is NaCl (native client) which runs practically native code in a sandboxed runtime.
I get pissed when you hear programmers say "Oh memory is cheap, we don't need to optimize!" Yes you do. In the server world these days we don't run things on physical hardware usually, we run it in a VM. The less resources a given VM uses, the more VMs we can pack on a system. So if you have some crap code that gobbles up tons of memory that is memory that can't go to other things.
It is seriously like some programmers can't think out of the confines of their own system/setup. They have 16GB of RAM on their desktop so they write some sprawling mess that uses 4GB. They don't think this is an issue after all "16GB was super cheap!" Heck, they'll look at a server and see 256GB in it and say "Why are you worried!" I'm worried because your code doesn't get its own 256GB server, it gets to share that with 100, 200, or even more other things. I want to pack in services as efficient as possible.
The less CPU, memory, disk, etc a given program uses, the more a system can do. Conversely, the less powerful a system needs to be. In terms of a single user system, like maybe an end user computer, well it would always be nice is we could make them less powerful because that means less power hungry. If we could make everything run 1.5 times as fast, what that would really mean is we could cut CPU power by that amount and not affect the user experience. That means longer battery life, less heat, less waste, smaller devices, etc, etc.
Asm.js is not JavaScript. It's Mozilla's way of hacking together a very specific optimization for JS-targeting compilers such as Emscripten, because they don't want to adopt the sane route of just implementing PPAPI and Google's Native Client sandbox, both of which don't work well with single-process browsers. From a developer perspective it's fairly trivial to target both Asm.js and PNaCl (Google's Native Client except with LLVM bytecodes), or target one and write a polyfill for the other. In either case, both of these environments are for executing C/C++ native code in the browser with minimal slowdown, they don't touch run of the mill JS anyway.
Let's correct that sentence:
"Now Mozilla claims that with some new improvements it is at worst only 1.5 times slower than single threaded, non-vectorized native code."
In other words, it's only 1.5 times slower than native code that you haven't made any serious effort to optimize. Hey, I think it's great they're improving the performance of Javascript. But this is still nowhere close to what you can do in native code when you actually care about performance.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Websites are no less than distributed applications. If you had been paying attention you would have noticed that website development has gotten a lot more rigorous than in the old days.
http://www.rootstrikers.org/
Let's just open up my handy Javascript console in Chrome...
(0.1 + 0.2) == 0.3
false
It doesn't matter how many bits you use in floating point. It is always an approximation. And in base-2 floating point, the above will never be true.
If they're saying that JavaScript is within 1.5x of native code, they're cherry-picking the results. There's a reason why people who care have a rich set of numeric datatypes.
The "everything must be a web site" mentality has confused the hell out of me for ages as well.
For some time I assumed it was probably for portability, but while writing a game I'm sure no one cares about I found that portability actually isn't all that difficult. The number of #ifdef involved to make it compile for both Windows and Linux (and FreeBSD, though I haven't compiled for it in about a year) amount to a very minor part of the code, and probably wouldn't have been even that much if I were more of a fan of using other people's libraries. (It does use GLFW, which no doubt is taking care of at least 95% of the portability issues for me.) I suspect even a Mac OS version wouldn't be too difficult though I never could figure out how to produce one from Linux. Granted, I don't have a reliable Linux version available due to LGPL issues, but no one cares about Linux anyway. They could certainly achieve portability between the platforms they care about (anything Windows runs on, and Mac OS) easily enough with a compiled C program, and if they really cared they could also set up a server farm of Linux machines so that they have a copy of each distribution available to compile a Linux version too.
So then why is it I go to YouTube and deal with shitty web video that barely plays correctly if it does at all? I've seen the red and blue channels reversed in video, I've seen 30-second seek times (even seeking backwards), and at times it simply doesn't work at all. The same goes for hulu.com or any online radio web site. Even Facebook could benefit from having a custom application. ...and all of these things would run more efficiently as an application than they do as a web site.
Hell, the new flickr.com is probably the best example. In their desire to have a wall of images in the search results, the javascript spends so much time examining possible arrangements of the images that the computer grinds to a halt. The web site is damn-near unusable, and certainly only "usable" if you're desperate. As far as "I'm bored so I'll look for something interesting on Flickr" goes, it's positively worse than being bored. Granted, they should do the intelligent thing and just go back to the web site they had, but as long as they're insistent on styling their image indexes like that, if they were to do it in a custom application, it could figure out the arrangements it wants in the blink of an eye and so the user experience wouldn't be so miserable.
The craziest thing about it for me is that, given the choice between making a web site and making a proper application, I'd rather make a proper application. Communicating with a server over a TCP connection is a piece of cake, so I don't need a web browser for that, nor do I want to structure everything as an HTTP request anyway. I also don't have to worry about cross-testing in every version of every web browser. Granted, you do then have to cross-test to different operating systems, but at least between Windows and Linux, I've found most of the issues that crop up tend to be data access errors that show up in one version but not the other simply due to data being arranged differently in each executable, and I haven't even seen that since compiling with -fstack-protector-all and writing a wrapper for malloc() in an effort to catch any invalid data access. With web sites I always seem to spend at least 20% of my time trying to make things look at least reasonable in every web browser, and I'm not one of those people who even tries to do fancy shit, I just keep running issues into things like one web browser inserting a blank line somewhere where another doesn't and trying to figure out some way to structure everything so that, if they can't all look the same, then at least none of them end up with ass-ugly formatting.
So I can only guess that the "everything must be a web site" is a user-driven demand.
Part of that might be the Windows convention that no matter how trivial