back to article Mozilla: Native code? No, it's JavaScript, only it's BLAZING FAST

The Mozilla Foundation says it has reached an important milestone in the quest to improve JavaScript performance, with some JavaScript benchmarks now running only around 1.5 times slower than when the equivalent algorithms are compiled and executed as native binary code. "That's a big improvement from earlier this year, when …

COMMENTS

This topic is closed for new posts.
  1. Lusty

    Well done Moz. Now if you could just do some work on blocking crappy code or improving the coders so all this work isn't pointless...

  2. Neil Barnes Silver badge

    It's all very well

    but browser scripts will continue to be banned unless necessary.

    1. Anonymous Coward
      Anonymous Coward

      Bah, Luddite!

      I look forward to auto-play ads getting on my tits faster than ever before!

  3. Anonymous Coward
    Anonymous Coward

    Yeah right

    They keep saying this about java too, how it's nearly as fast as native code. And yet somehow applications always run 10 times as slow and take 4 times the memory still.

    1. h4rm0ny

      Re: Yeah right

      Java is pretty fast these days. The slowness you are complaining about is probably the time it takes to start up the VM. Compare performance of two applications once they are actually running and it's good. Compare start-up time and it's often bad.

      1. Tim Parker

        Re: Yeah right

        "Compare performance of two applications once they are actually running and it's good. Compare start-up time and it's often bad."

        I have to agree with the OP - i've still not seen any reasonably computationally intensive code, outside of a few isolated routines or synthetic benchmarks, that run anything like as fast using Java over C/C++ or Fortran. Some GUI apps do a remarkably good job and i'm not knocking it as a useful language, especially due to its run-time nature and cross platform support, but once the heavy lifting starts it's a no-go. From personal experience or second hand feedback numerical simulations, search algorithms, things with deep stacks or lots of branching, anything which has significant string manipulation and creation, anything needing any type of time/response guarantee (think GC).. all perform poorly against (half decent) native code.

        Java's fine, not without its quirks but what language isn't, but all this continual willy-waving about being as fast as X or native this-or-that is un-necessary and rather obscures it's true strengths (IMO).

        1. wikkity

          Re: Yeah right

          I Seriously I do not understand why anyone can claim that java is slow compared to X language. Sure there are going to be particular examples where one is slightly faster due the implementation of the compiler/runtime/operating system or a particular combination. There is one are Java is slow, and that is start up time. Once it is up and running it is comparable with any "native" code, once the runtime has jitted the code the runtime is running _native_ code.

          Assuming you want to write maintainable code in any language and thus use abstractions a above the bare metal the only differences are really developer capabilities and differences between compilers. There are some very clever people working on the various java runtimes so that leaves one real difference, slow program == poor developer || tight deadlines || low budget.

          Don't think it's a high performance language? Why is used as much on the server side where businesses, banks and governments rely on it, sure it great support for pretty much everything you need to do, easily and maintainable but if it ran like a dog no one would consider it.

          Hell, even Apple use it on the server.

          1. Anonymous Coward
            Anonymous Coward

            Re: Yeah right

            JItted code still runs inside the VM, because otherwise all the VM-provided services, sandboxing, GC, etc. would not work. And it still does use for example the VM memory allocator and so on - which in turn has to call OS services to work. While a fully native application does call OS services without going through too many indirections - a C++ application may use its RTL memory manager (which usually wraps the OS one in a simpler and faster way than a VM), or call directly the OS one if it needs so. There are no all the execution checks that should make a VM safer compared to a native application. Etc. etc. Thereby, while a single small algorithm that is run without any calls outside the VM once jitted may be pretty fast, any real application that to work needs eventually to call into the OS is still speed constrained by the very fact it has to run within the boundaries of a controlling layer - the VM - which makes it slower.

            1. Anonymous Coward
              Unhappy

              Re: Yeah right

              A simpler explanation is that for every API layer you have to transit, and God forbid crossing a Ring boundary in x86 (x86-64), your code got a whole hell of a lot slower. Which is of concern here as I make heavy use of virtualisation in the first place, never mind all those layers going up the stack. Direct compilation to clang/gcc using bare or near-bare metal? Not so much crap in the way of getting the job done. Sometimes (sometimes?!!) I convince myself that we do this complexity to justify our existence (job insurance).

            2. Infernoz Bronze badge

              Re: Yeah right

              JVMs GCs are normally very fast, maintain big memory pools, and keep getting faster, so rarely need to call the system memory allocator, can self-tune and be tuned at runtime, and can be told to pre-allocate memory. The use of a GC, references, and bounded references are not a luxury, because they block common bugs and exploits which still plague machine code compiled languages. Native OS calls are generally only for hard resources, which are expensive to allocate and use anyway, unless you are running a retarded 'native' GUI library like SWT, which is only used by a minority of Java applications like Eclipse. The assumption of Java native bridges for some "native" calls and data structures could be an illusion, or swapped out after jiting; JNI is no longer the only native library interface method, libraries like JNA have replaced the need for most JNI C++ code, and other JVM interfaces already exist for safe and unsafe direct memory use.

              The other advantage of Java is, is it really is multi-platform. I've used complex Java applications on both Windows and Linux, so did not have to find, learn and use less capable crude native tools. I've have also noticed that native apps like Firefox and GPG can have quite significant version lag across OS's on Windows, Linux, and FreeBSD, unlike Java apps.

              1. Destroy All Monsters Silver badge
                Windows

                Re: Yeah right

                ITT: People hoping that these newfangled "Virtual Machine" languages just went away so that they can get back to the well-remunerated job of getting some work done in original K&R C.

                Until the nurse rolls them back into their room.

              2. Anonymous Coward
                Anonymous Coward

                Re: Yeah right

                Yes, they maintain big memory pools to avoid to call into the OS to get it, and that's why Java application from an OS point of view are memory hogs compared to applications that don't need to preallocate huge quantities of memory to run. A GC is always slower than direct memory allocation/deallocation, and it nneds more data structures to keep track of memory, and it can lead to contention.

                Native OS calls are required whenever you have to do something outside the VM. Do you need to access a file? You need to call the OS. You need to draw something on the screen? You need to call the OS. You need to access a peripheral? You need to call the OS. You need memory? You need to call the OS. You need to get the date and time? You need to call the OS. You need to read the keyboard and mouse? You need to call the OS. And so on. Profile a JavaScript, Java, or .NET app and you'll see how many OS calls they need even for simple operations. Without calling into the OS, you have no way to perform I/O and access any system resource - hard or soft. You would only be able to run some internal useless operation - because no user will ever see the results.

      2. Hi Wreck
        Facepalm

        Re: Yeah right

        The only relationship between JAVASCRIPT (i.e., browser stuff) and JAVA is they were both developed by coffee=addled C programmers. Browsers run the former in <SCRIPT...>, Browsers should block the latter (and its virtue-less machine).

    2. JDX Gold badge

      applications always run 10 times as slow and take 4 times the memory still

      How is this kind of ignorant statement getting up-votes? One would hope Reg readers weren't that dumb.

      1. Oninoshiko

        Re: applications always run 10 times as slow and take 4 times the memory still

        I'm pretty sure the slowness is the crap developers writing java like the daily WTF was a contest.

        The java where I work haunts my nightmares.

        1. Anonymous Coward
          Anonymous Coward

          Re: applications always run 10 times as slow and take 4 times the memory still

          "The java where I work haunts my nightmares."

          Sadly, the Java where I used to work still gives me nightmares. And I wrote most of it...

          Not being allowed to rewrite code from before 2005 was a lot of the problem, though.

  4. Anonymous Coward
    Anonymous Coward

    Very Nice Mozilla

    Now how about getting your shit together to produce a 64bit windows browser and make Firefox multiprocess ?

    1. Adam 1

      Re: Very Nice Mozilla

      If you think it should be multiprocess, why do you also think it should be 64 bit?

      1. Anonymous Coward
        Anonymous Coward

        Re: Very Nice Mozilla @Adam1

        Well why not just have it 16 bit and single threaded ?

        Sigh

        1. Adam 1

          Re: Very Nice Mozilla @Adam1

          Some functions of Firefox require more than 64KB of addressable memory which rules out a 16 bit address space, but why not try to answer the question?

          64 bit processes can do some ops faster like floating point manipulations but it makes other things slower like copying pointers. The main advantage from a browser's point of view is the ability to make use of 2GB RAM which makes a lot of sense when your 25 open tabs are combined in one address space with the 8 plugins also loaded, but if you have already separated it into a process per tab model then you are probably a long way south of 2GB.

          Or have I just been trolled by an rf -rm handle not noticing the advocation of threading and missing the irony. If so, well played sir.

          1. Anonymous Coward
            Anonymous Coward

            Re: Very Nice Mozilla @Adam1

            @Adam 1 Have a +1 for understanding the real problem. I doubt you were trolled, I think that was a poor attempt at being snarky.

            1. Anonymous Coward
              Anonymous Coward

              Re: Very Nice Mozilla @Adam1

              Adam,

              You knew the answers so were you attempting to troll me ? ;)

              Why not just add to the discussion by saying 64 bit has these advantages and multiprocess these advantages ?

          2. Anonymous Coward
            Pint

            Re: Very Nice Mozilla @Adam1

            Sounds like you have a pretty thorough understanding of what's involved. I know I'm guilty of the two- or three-dozen open tabs nearly one hundred percent of the time.

            Have a beer.

    2. Anonymous Coward
      Anonymous Coward

      Re: Very Nice Mozilla

      Feel free to contribute the necessary code changes.

    3. HighHo

      Re: Very Nice Mozilla

      Although no offical releases yet, you can find 64bit builds here for windows: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

      1. Philip Lewis

        Re: Very Nice Mozilla

        Try this ... http://www.palemoon.org/

        The 64 bit build works a treat

    4. amehaye

      Re: Very Nice Mozilla

      they are working on multi prices. Google for Firefox electrolysis.

  5. Tom 7

    Just think - this could have been VBscript

    and it wouldn’t run on anything other than i86.

    Please stop blaming javascript for marketing twats and shit coders and shitter managers. Alexander Graham Bell is not a wanker because of cold calling and openreach. I've worked in companies where we've got high quality (>2.1) computer scientist graduates who cant run a debugger from an IDE let alone use firebug.

    Javascript is a lot shitter than it could have been if certain companies hadn’t joined in the specification process to try and stop the browser becoming the nigh on defacto interface for everything but you can write some very good things with it and if you take the care to apply proper software development methods and not just let it go to pot like any language does without proper software development methods you can write good stuff.

    A bad workmen blames his tools - and the more powerful it is the more damage it can do which is why it scares people so much.

    1. David Dawson

      Re: Just think - this could have been VBscript

      JavaScript is a hilarious language, and great fun to use. It can certainly be used to produce fairly large applications, certainly.

      It's not yet a language that is particularly coherent or set up for large scale development in the way that it works. I have great hopes for the next version of ecma script, it looks good and fixes these problems.

      The GNOME people used to make great noise about being able to do object oriented programming using C. It's true, they did, but that doesn't mean it's a good idea to do that if better options are available. Javascript is useful for many different problems, but it's missing some important features (a native module system for one) and others are a bit of an issue for large scale dev.

      The culture around javascript is interesting as well. It appears to be tracking about 7-10 years behind the culture around Java (where I spend most of my time at the moment). back then, everything was about increasing them speed of the VM and building of a myriad of support frameworks. Just like JS is now. Now, Java-land is moving much more towards stripping down to the basics, removing frameworks, making things light weight. (eg, in web systems, the move from heavy J2EE container +EJB back then, to tomcat/ jetty + spring, to no container at all)

      The world should be polyglot, many languages doing what is best for them to do.

      I like the idea of asm.js. It's kind of similar to GWT before it, but more standardised at a lower level with the possibility to optimise.

      Some interesting comments on the tinternets about supporting GWT on top of asm.js, something about having to implement a full GC subsystem in asm.js compatible JS. :-)

      1. TheOtherHobbes

        Re: Just think - this could have been VBscript

        "JavaScript is a hilarious language"

        So is C++. It's just the joke isn't actually funny.

        1. c:\boot.ini

          Re: Just think - this could have been VBscript

          "JavaScript is a hilarious language"

          &

          "So is C++. It's just the joke isn't actually funny."

          Go try Groovy, especially XML parsing - now that is funny!

          1. This post has been deleted by its author

      2. Anonymous Coward
        Anonymous Coward

        Re: Just think - this could have been VBscript

        I agree the lack of a native module system on the client is annoying - some frameworks try to make some sense into it with their own conventions and tools, ExtJS and Sencha Touch for example; source files are sorted quite logically into their respective directories and the production version is then "compiled" (that is, the source files are combined into a single minified file), but naturally that requires you follow the conventions of the framework. On the server there's the CommonJS module system, used for example by node.js, that actually works quite well.

        But as for the next version of Ecmascript - I'm waiting for that as well, but it's been coming for years. And even if it'd get finalised at some point, it'll take many years more for it to be widely available.

      3. Javapapa

        Re: Just think - this could have been VBscript

        Now, Java-land is moving much more towards stripping down to the basics, removing frameworks, making things light weight. (eg, in web systems, the move from heavy J2EE container +EJB back then, to tomcat/ jetty + spring, to no container at all)

        Sounds like I saved myself a ton of hassle by never going down the J2EE + EJB road. I was spoiled rotten by 25 years in the cozy, insulated and isolated AS/400 world, which had all the built-in services that J2EE promised, so I never got excited by it. Today, Tomcat + JSP works for me on the backend, JS on the front. But who knows, maybe node.js tomorrow?

        1. David Dawson

          Re: Just think - this could have been VBscript

          Sounds like I saved myself a ton of hassle by never going down the J2EE + EJB road. I was spoiled rotten by 25 years in the cozy, insulated and isolated AS/400 world, which had all the built-in services that J2EE promised, so I never got excited by it. Today, Tomcat + JSP works for me on the backend, JS on the front. But who knows, maybe node.js tomorrow?

          ----

          Try Groovy and friends before JS. It's still JVM, which is far faster than any Javascript VM still.

          If you want the threading model from node (reactor is it's name), try Vert.x. Again, JVM, can use JS if you want, or build it in Groovy or Java.

          JSP is ok-ish, but there's much improved view tech now. Thymeleaf comes to mind as a particularly good one, the offline support is good

          Then try Clojure and it's Ring library. It's really, really nice.

          JSON->Clojure data transform -> MongoDB all in a half dozen lines of lisp awesomeness.

          It's Lisp! on the JVM, what's not to like.... ;-)

          If all that fails, then JS on the server has a place I think, it really depends on your application needs.

      4. Ken Hagan Gold badge

        Re: Just think - this could have been VBscript

        "The world should be polyglot, many languages doing what is best for them to do."

        Crap. What if your program needs to do two of these things. Oh, you just use two ideal languages and get them to invoke each other as necessary. Ah, but I also want to minimise the cost of that communication. Oh, well you just need some kind of standard middleware like <pick your own buzzword here, or say "unix pipes" if you don't know any better>. Ah, but that has semantics limitations that make it not as expressive or rich as either of the languages I'm working with. No problem, just add these extensions to the two ideal languages, or use this even better middleware. And before you know it you find you are actually programming *in* the middleware and that middleware was never actually intended as a language and, worse, now has a hundred proprietary and unsupported extensions that were designed as stand-alone languages but have since been bitchered about a bit.

        The world should be monoglot, but we haven't found the right language yet.

        1. David Dawson

          Re: Just think - this could have been VBscript

          LOL

          No, it really isn't crap. You make the mistake of conflating polyglot with integration, and integration with middleware, and if you take it further, thence to the fable ESB, which is the evil everyone should really fear.

          I'm talking doing some processing in one language, then other processing in a different language. how you shift data between them is certainly a problem, but it is a solved problem.

          The JVM is good at this, so is the CLR. Javascript is well on its way to becoming another system that permits polyglot programming well.

          If yoou have one runtime environment that permits many languages, the problem is solved. If you want to use a language that isn't in that same environment then you require some form of integration. Depending on your needs there are many different forms they can take, middleware is only one of them, and not a particularly nice one at that.

          In a JVM system I could write my DB integration in Groovy, data transformation in Clojure and threading code in Scala, with each language helping me perform that task, and no integration code required.

          So, is this crap? Or were you being a little... rapid in your judgements?

  6. Anonymous Coward
    Anonymous Coward

    ... traditional JavaScript is a syntactically rich, high-level language like C or Python ...

    Python I'll grant you, but C? It's more of a "mid-level" language, only one step above assembly language programming.

    1. Anonymous Coward
      Anonymous Coward

      It's more of a "mid-level" language, only one step above assembly language programming.

      C used to be considered a "high-level" language. One line of C code may translate into several machine instructions. Unlike assembler in which one line of assembly is one machine instruction exactly.

      I think that's where C gets its "high-level" status from. Granted, it's not as high level as today's modern languages, but it was very high level for its time.

      1. Ken Hagan Gold badge

        C' "high level" status

        I beg to differ. C was created as a portable alternative to assembly language and was always considered to be lower level than even Fortran or COBOL, which were pitifully primitive compared to "proper" high-level languages like APL or Simula.

  7. RyokuMas
    FAIL

    It's still bloody javascript...

    "Please stop blaming javascript for... shit coders"

    In the ten or so years I've been in web development, I've yet to see any sizable chunk of code in Javascript that reads in a half-way decent manner.

    Here's the hint: Javascript - very useful for adding snippets of support functionality to a website and negate the need for a few server calls, But this attitude that HTML5, CSS3 and Javascript are the second coming is poisonous to the IT industry as we know it, replacing clean class structures and inheritance with sprawling spaghetti piles of prototypes, functions and variable clashes.

    Put Javascript back onto making snippets of supporting code, and leave application development to proper languages.

    1. Androgynous Cupboard Silver badge

      Re: It's still bloody javascript...

      I have seen a lot of shit cloaked in class hierarchies and inheritance.

      As for HTML & JS, I'm not saying I'd write a kernel in it but when done well it's unparalled for rapid development (and ease of deployment) of UI. Horses for courses.

    2. Simon Brown

      Re: It's still bloody javascript...

      angular? or have I missed the point?

  8. Michael Habel

    Can they code back the old Download Manager?!

    1. John 110

      hop over to...

      www.palemoon.org

      (does 64-bit too)

      1. Michael Habel

        Re: hop over to...

        www.palemoon.org (does 64-bit too)

        Two Things wrong with this line of reasoning...

        One Pale Moon is based on Mozilla 24 (i.e. Firefox 24 ESR?!) So why not just use the real thing. (i.e. FF24 ESR), but, then for how much longer?

        Two this is hardly a long-term solution, as Pale Moon is NOT a fork as such, and will have to merge their Code with Mozilla / Firefox 26+ at some point in the future as well....

        Add to this the fact that Firefox 24 has a nasty Bug in it that eats up the Fonts on some ATI HD 20xx 30xx 40xx Cards (e.g. On my Laptop!) unless I kill off the Hardware acceleration. and that Mozilla are refusing to support this "Fix" in 24ESR. Plus all the other douchebaggery going on. (Like the killing off of the Download Manager), I'm in need to find the next Firefox. 'Cause Firefox isn't cutting it anymore...

  9. Paddy

    PyPy anyone?

    It reads like what they are doing with the RPython subset of Python used by the PyPy project in speeding up Python.

    See http://doc.pypy.org/en/latest/coding-guide.html#id1

  10. Milen
    Facepalm

    Joy to the World

    My dream has come true!

    I've always wanted to write in C or C++ and then hope that my code can properly be parsed into a niche language, and then after some debugging of code that "is so arcane that application developers are advised not to try to write it by hand", it would be able to run in only one web browser, provided that the user is able to update it to its latest version, has updated it within the last few months and has in fact enabled my "optimized" code to run in it.

    Then it might or might not run faster than if I had written it in JS in the first place.

    1. Anonymous Coward
      Anonymous Coward

      Re: Joy to the World

      I up-voted for the general tone of the comment, but would question one bit - asm.js code will run in all JavaScript-capable browsers (as it is, in fact, still JavaScript), though some won't optimise for it specifically.

  11. phil dude
    Thumb Up

    bottom feeders...

    For us bottom feeders who need the easiest way of getting out our scientific code, I actually tried this with one of my bits of code. My co-author was quite surprised it could work....

    I am generally enthused by this, using JS make a gui version easier, and also makes mobile version possible too.

    P.

  12. M Gale

    a syntactically rich, high-level language like C or Python

    Oh come on. High level like C or Python? Just because Assembly language is a mining operation in the Marianas trench, doesn't mean that paddling around in a Python (or Ruby, Perl, VB, even Javascript) playpool is anything like the heliox diving operation that is C.

    1. phil dude
      Pint

      Re: a syntactically rich, high-level language like C or Python

      yes, but having written (writing) assembly language for my science, I am happy to have a tool (emscipten) do it for me!!

      My co-author and I had discussed just making our original C++/C version into JS, but I tried this tool and was frankly, amazed at it. I did this about 9 months ago, so I'm sure it has been polished since then....

      Once we get both versions, we'll write a publication comparing them directly. This may help others decide if it is worth the effort...

      P.

  13. c:\boot.ini
    Joke

    I love those C fanbois ... our language is more complex and harder to maintain than yours, so it is better ...

    ... an initial underscore already conveys strong feelings of magicalness to a C programmer. - Larry Wall

    1. Anonymous Coward
      Anonymous Coward

      I like to use initial underscores in my VB code. It looks awesome. Sometimes I even use two...

      1. Destroy All Monsters Silver badge
        Trollface

        And apparently none of them has even heard of "D"

        It's like a Japanese sergeant, holding out forever on a pacific reef, while the world moves on.

    2. Long John Brass

      C Complex?

      The C language core is very small, very simple.

      But it's the right kind of simple; Simple & powerful

      The Libraries on the other hand are many, varied and ummm wondrous :)

  14. Anonymous Coward
    Anonymous Coward

    Assembler is not "arcane"

    "In fact, much like assembly language, the structure and syntax of Asm.js code is so arcane that application developers are advised not to try to write it by hand".

    Assembler isn't arcane at all. It's exactly the opposite: as simple as you can get. That's why it's hard to use - and even harder to use well. You have to do everything yourself.

    Its syntax is very simple compared to almost any higher-level language; and its structure, of course, is whatever the programmer chooses.

    But brownie points for working in "arcane"; a very good word indeed.

    1. M Gale

      Re: Assembler is not "arcane"

      Oh I dunno. I'd call Brainfuck and its derivatives pretty arcane (and perhaps archaic), even if they are about the simplest type of "virtual machine" you could dream up. Quite far removed from 10 PRINT "BOLLOCKS "; 20 GOTO 10.

  15. Kevin McMurtrie Silver badge
    Happy

    This is cool. You can make Java and C++ run very fast by eliminating design patterns that are wasteful or difficult for the compiler to optimize. (Java's "Enterprise" coding style is the ultimate in slow, unreadable, bloated, crap.) That hasn't been the case with JavaScript. You can try very hard, but JavaScript still has ambiguous meanings in simple code that can't be statically optimized. Targeting Asm.js with a high power optimizer could open up a lot of possibilities.

    1. Destroy All Monsters Silver badge
      Holmes

      Java's "Enterprise" coding style is the ultimate in slow, unreadable, bloated, crap.

      That may be so but what is Java's "Enterprise" coding style?

      Pretend this is a job interview question.

  16. Anonymous Coward
    Anonymous Coward

    Imagine how much effort has been spend trying to improve Javascript performance

    By Mozilla, by Google, by Apple, by Microsoft. Imagine how much other stuff in the browser could have been improved if they'd make the correct decision to ditch Javascript a decade ago and use something that didn't require 50,000 man years of programmer effort to make suck less?

  17. Joerg

    Low-level "arcane" nonsense...

    Arcane in this Asm.js mess of a joke it's just that.. a mess.

    On par with C/C++ and Assembly ? Blazing fast ?

    WHAT ?

    Please...

    It's still just Javascript and nothing new, nothing else, nothing better.

    1. foxyshadis

      Re: Low-level "arcane" nonsense...

      What's new is the assembler backend that converts it back into machine code, without the overhead of a JIT or having to support any of JS's millions of corner cases. Read harder, do some research next time.

      Asm.js is no different from any other intermediate object code prior to being fully linked, except that it's directly executable by any other standard engine as well. Might as well say C's .o files are a mess.

  18. Anonymous Coward
    Coat

    Meh…

    Call us when Mozilla have Firefox ported to asm.js…

This topic is closed for new posts.