Feeds

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 as …

COMMENTS

This topic is closed for new posts.

Page:

Bronze badge

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

4
1
Silver badge

It's all very well

but browser scripts will continue to be banned unless necessary.

11
0
Bronze badge

Bah, Luddite!

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

13
1
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.

20
9
Silver badge

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.

14
6
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.

7
9

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

9
3
Bronze badge

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.

4
6
Silver badge

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.

10
0
LDS
Silver badge

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.

3
2
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
0
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).

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

4
1
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.

3
0
LDS
Silver badge

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.

0
2
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.

1
0

Very Nice Mozilla

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

7
2
Bronze badge

Re: Very Nice Mozilla

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

1
0
Anonymous Coward

Re: Very Nice Mozilla

Feel free to contribute the necessary code changes.

7
1

Re: Very Nice Mozilla @Adam1

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

Sigh

2
2

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/

0
0
Bronze badge

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.

5
1
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.

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

0
0

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 ?

0
3

Re: Very Nice Mozilla

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

0
0
Bronze badge

Re: Very Nice Mozilla

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

The 64 bit build works a treat

0
0
Silver badge

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.

7
1

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. :-)

7
0
Silver badge

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.

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

0
0

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!

2
0

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
0

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.

0
0
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
2

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?

1
0

This post has been deleted by its author

Silver badge

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

15
0
Silver badge

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.

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

0
0
Bronze badge
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.

8
10

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.

3
1

Re: It's still bloody javascript...

angular? or have I missed the point?

2
0
Bronze badge

Can they code back the old Download Manager?!

4
0

hop over to...

www.palemoon.org

(does 64-bit too)

0
0
Bronze badge

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

0
0

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

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

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

2
1
Bronze badge
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.

3
0

Page:

This topic is closed for new posts.