Slashdot Mirror


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?"

9 of 289 comments (clear)

  1. "So who needs native code now?" by Anonymous Coward · · Score: 5, Informative

    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!

    1. Re:"So who needs native code now?" by MightyMartian · · Score: 4, Insightful

      What a bizarre statement. Of course it's programming. It may not be very elegant programming, but then again, the bulk of C code I've seen in my years in the business isn't terribly elegant either.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    2. Re:"So who needs native code now?" by phantomfive · · Score: 5, Insightful

      Correct this to any real programmer. I'm tired of web designers being colluded with actual programmers, scripting isn't programming.

      Heh....typing isn't programming. If you aren't connecting patch wires on an accumulator bank, it's not worth doing. You get more efficiency that way too!

      --
      "First they came for the slanderers and i said nothing."
    3. Re:"So who needs native code now?" by dshk · · Score: 4, Informative

      deallocation can (and often is) made O(1) using memory pools in C and C++ programs, something that can't be done in GCd languages

      I believe current Java (not Javascript!) virtual machines do exactly this. They do escape analysis, and free a complete block of objects in a single step. This works out of the box, there is no need for memory pools or any other special constructs.

  2. Javascript as a Virtual Machine Representation by ndykman · · Score: 5, Interesting

    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.

  3. Or anything running in a VM by Sycraft-fu · · Score: 5, Informative

    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.

    1. Re:Or anything running in a VM by zippthorne · · Score: 5, Insightful

      Another question is why we need to duplicate an entire operating system to encapsulate applications. If you have 100 things that need to run on a machine why should you need to also run 100 entire operating systems? Something is wrong with the way we're designing servers.

      --
      Can you be Even More Awesome?!
  4. Maximum precision? by raddan · · Score: 4, Informative

    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.

  5. Re:64-bit computation vs. 64-bit storage by Pinhedd · · Score: 4, Informative

    Take a look at the image at the following link

    http://www.anandtech.com/show/6355/intels-haswell-architecture/8

    That's the backend of the Haswell microarchitecture. Note that 4 of the 8 execution ports have integer ALUs on them, allowing for up to 4 scalar integer operations to begin execution every cycle (including multiplication). Two of these are on the same port as vector integer unit, which can be exploited for an obnoxious amount of integer math to be performed at once. There are only two scalar FP units, one for multiplication on port-0 and one for addition on port-1.

    The same FP hardware is used to perform scalar, vector, and fused FP operations, but taking advantage of this requires a compiler that is smart enough to exploit those instructions in the presence of a Haswell microprocessor only and fast enough to do it quickly. Exploiting multiple identical execution units in a dynamically scheduled machine requires no extra effort on behalf of the compiler.

    Microprocessors used in PCs have always been very integer heavy for practical reasons (they're just not needed for most applications), and mobile devices are even more integer heavy for power consumption reasons.

    Using FP64 for all data types is obnoxiously lazy and it makes me want to strangle front end developers.