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...
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 …
-
-
-
Friday 20th December 2013 12:18 GMT 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).
-
Friday 20th December 2013 13:18 GMT 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.
-
Friday 20th December 2013 22:13 GMT 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.
-
Saturday 21st December 2013 01:44 GMT Anonymous Coward
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).
-
Saturday 21st December 2013 07:51 GMT Infernoz
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.
-
Sunday 22nd December 2013 15:49 GMT 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.
-
-
-
-
-
-
-
Monday 23rd December 2013 09:25 GMT 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.
-
-
-
-
-
-
-
Friday 20th December 2013 20:15 GMT 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.
-
-
-
-
Friday 20th December 2013 09:22 GMT 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.
-
Friday 20th December 2013 10:26 GMT 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. :-)
-
-
-
This post has been deleted by its author
-
-
-
Friday 20th December 2013 13:30 GMT 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.
-
Friday 20th December 2013 19:32 GMT 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?
-
Saturday 21st December 2013 10:04 GMT 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.
-
-
Sunday 22nd December 2013 20:31 GMT Ken Hagan
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.
-
Sunday 22nd December 2013 20:45 GMT 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?
-
-
-
-
-
Saturday 21st December 2013 23:53 GMT 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.
-
-
Friday 20th December 2013 09:48 GMT RyokuMas
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.
-
-
-
Friday 20th December 2013 13:30 GMT 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...
-
-
-
Friday 20th December 2013 12:19 GMT Milen
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.
-
Friday 20th December 2013 13:55 GMT phil dude
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.
-
Friday 20th December 2013 15:07 GMT 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.
-
Friday 20th December 2013 15:18 GMT phil dude
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.
-
-
Friday 20th December 2013 17:01 GMT 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.
-
Friday 20th December 2013 19:43 GMT Kevin McMurtrie
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.
-
Friday 20th December 2013 22:50 GMT 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?
-
-
Monday 23rd December 2013 10:10 GMT 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.
-