Slashdot Mirror
Chrome 10 Beta Boosts JavaScript Speed By 64%
CWmike writes "Google released the first beta of Chrome 10 on Thursday, and Computerworld found it to be 64% faster than its predecessor on Google's V8 JavaScript benchmarks. But in another JS benchmark — WebKit's widely-cited SunSpider — Chrome 10 beta was no faster than Chrome 9. Yesterday's Chrome 10 beta release was the first to feature 'Crankshaft,' a new optimization technology. Google engineers have previously explained why SunSpider scores for a Crankshaft-equipped Chrome show little, if any, improvement over other browsers. 'The idea [in Crankshaft] is to heavily optimize code that is frequently executed and not waste time optimizing code that is not,' said the engineers. 'Because of this, benchmarks that finish in just a few milliseconds, such as SunSpider, will show little improvement with Crankshaft. The more work an application does, the bigger the gains will be.' [Chrome 10 beta download here.]"
Will it make the new /. work any faster ... or better ... or anything?
Historically, slashdot(and elsewhere) has seen the battle over performance between the C/C++ classicists, and those who insist that Java or one of its architecturally similar cousins has, with enough work on the JVM, achieved nearly equivalent execution speed.
Does anybody know where we are with Javascript now? Traditionally, its performance has been pathetic, since it wasn't all that heavily used; but of late competition to have a better javascript implementation has been pretty intense. Is there anything fundamentally wrong with the language, that will doom it to eternal slowness, or is it on the trajectory to near-native speeds eventually?
Take that! This Chrome goes to EeeeeLeven....
Google is doing this with Native Client. It allows a browser to run code compiled for x86, ARM, or LLVM bytecode in a sandbox. It's currently in beta in Chrome 10 (you can enable and try it out by going to about:flags), and apparently available for other browsers as well under the BSD license.
"Joy is contagious," he said, peering into the microscope.
Modern JS jits (tracemonkey, crankshaft) seem to be able to get to within about a factor of 10 of well-optimized (gcc -O3) C code on simple numeric stuff. That's about equivalent to C code compiled with -O0 with gcc, and actually for similar reasons if you look at the generated assembly. There's certainly headroom for them to improve more.
For more complicated workloads, the difference from C may be more or less, depending. I don't have any actual data for that sort of thing, unfortunately.
There _are_ things "wrong" with javascript that make it hard to optimize (lack of typing, very dynamic, etc). Things like http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/ (see the valueOf example) make it a bit of a pain to generate really fast code. But projects like https://wiki.mozilla.org/TypeInference are aiming to deal with these issues. We'll see what things look like a year from now!
Java isn't a dynamic language which is the central difference that makes languages like Javascript and Python much slower than C++ and even Java with the compiler technology as it is now and for the forseeable future. A big still relevant problem with Java is the long loading times you end up with starting up large applications. Javascript isn't even compiled to bytecode so that problem would be much worse if big applications were written and run as Javascript. Javascript is getting faster all the time but don't expect anything like C++ or even Java for general purpose programming. Which is fine because that isn't what Javascript is all about.
V8 compiles javascript to native code, so in that sense it is native speed. The limiting factor is interacting with the HTML DOM/CSS.
Do you even lift?
These aren't the 'roids you're looking for.
Given that browsers tend to cache website elements, for better speed when loading objects that haven't changed since last load, and given that, while people want their page now, their computer usually has a fair amount of idle time available, would you expect to see browsers implementing some sort of background optimization mechanism that chews over cached javascript during idle periods in order to reduce the amount of computationally expensive work that needs to be done should the page be reloaded? Or is Javascript not amenable to that level of preemptive processing?
v11.0.672.2 is also a beta.
http://www.filehippo.com/download_google_chrome/
1) Google didn't say it, computer world did.
2) Existing benchmarks like SunSpider are not necessarily good indicators of the performance of all real web pages. For small pages with little JS it makes no difference whether the engine is fast or not - all you care about startup latency. The large AJAX pages we're seeing these days are hitting different bottlenecks, and so you need different benchmarks to emulate that workload. The apparent achievement of crankshaft is to improve the performance of long-running JS without increasing the startup latency of short-lived pages. Well done to Chrome for looking at real-world performance instead of worrying about who has the fastest SunSpider numbers.
Does anybody know where we are with Javascript now?
There is always the The Computer Language Benchmarks Game. There you will find V8 competitive with Python, Ruby and other such languages, which is to say slower than the usual compiled suspects by about the same degree.
Lurking at the bottom of the gravity well, getting old
Wait, a company says their thingy is 64% faster! Then other people test it and say no it's not... then the company says "You have to test it OUR way!" Is the next step that Google specifically engineers their code just to run the benchmarks themselves faster with no real improvement anywhere else? Sound familiar? (ATI/Nvidia)
You read that backwards. Chrome 10 made no difference over Chrome 9 in benchmarks, but ComputerWorld said it was 64% faster. Google stated that Chrome 10 was more optimized for real code, not benchmarks. Geez man, I didn't even RTFA. I got all that from the summary. Have we gotten so lazy we're not even reading summaries?
This is for security. There's a command line flag for disabling this, I'm pretty sure.
Try --allow-file-access-from-files
If that doesn't work, you could go to http://codesearch.google.com/codesearch/p?vert=chromium#OAMlx_jo-ck/src/chrome/common/chrome_switches.cc and look for one that does what you want.
We tend to shoot for clever or snarky instead of meaningful;)
The US government have made it clear that we have no inalienable rights; any we do not defend vigorously will be taken.
These are all minor versions. They just omit the 1 dot.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Have we gotten so lazy we're not even reading summaries?
I gave up about halfway through there but I can tell you without a doubt that we have not gotten so lazy we're not evenly weighing the pros and cons of our decisions.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
There are indeed a few fundamental issues with Javascript that make it both useful for coding and at the same itime hopeless toreplace something like C.
In javascript, accessing the property of an object requires a lookup, and some checking to make sure things exist. Compared to accessing a field in a C struct, that's a lot of overhead (AFAIK, google does do heave optimazation in this area). The reason for doing that is for safety and being dynamic.
In a large application, ultimately performance comes from memory management. The best way is using memory and resource pooling, fine tuned by the programmer. I doubt javascript can be efficiently used this way. I don't think javascript can be used to code Word or a browser (I mean the browser itself) any time soon.
Multithreading is also an issue. There is not really anything wrong with the language. It's more of an implementation issue.
Most of these newfangled JavaScript engines are simply JIT compilers, so yes, the compilation time takes some time which usually means the page loads slower. All those "OnLoad" statements have to be parsed and compiled before they can run faster than they could before.
Ideally you don't notice it cause your awesome new CPU is fast enough to make it a non issue. If you didn't upgrade your PC (or mobile) last week but last decade, you might have a problem tho.
I'm very sure, yes.
> I don't recall gcc -O3 and -O0 having a factor of 10
> difference for most tasks.
They don't. My comment was quite specific: the cited numbers are simple number-crunching code. The fact that -O0 stores to the stack after every numerical operation while -O3 keeps it all in registers is the source of the large performance difference as long as you don't run out of registers and such. The stack stores are also the gating factor in the code generated by Tracemonkey, at least.
> And Javascript definitely isn't close to C
> performance, even unoptimized.
For simple number-crunching code, Tracemonkey as shipping in Firefox 4 runs at the same speed as C compiled with GCC -O0, in my measurements. I'd be happy to point you to some testcases if you really want. Or do you have your own measurements that you've made that are the basis for your claim and that you'd care to share?
Note that we're talking very simple code here. Once you start getting more complicated the gap gets somewhat bigger.
As an example of the latter, see https://github.com/chadaustin/Web-Benchmarks which has multiple implementations of the same thing, in C++ (with and without SIMD intrinsics) and JS with and without typed arrays. This is not a tiny test, but not particularly large either.
On my hardware the no-SIMD C++ compiled with -O0 gives me about 19 million vertices per second. The typed-array JS version is about 9 million vertices per second in a current Firefox 4 nightly.
For comparison, the same no-SIMD C++ at -O2 is at about 68 million vertices per second. -O3 gives about the same result as -O2 here; -O1 is closer to 66 million.
> Besides, gcc -O3 can actually be somewhat
> slower than -O2
Yes, it can, depending on cache effects, etc. For the sort of code we're talking about here it's not (and in fact typically -O2 and -O3 generate identical assembly for such testcases. See the numbers above.
One other note about JS performance today: it's heavily dependent on the browser and the exact code and what the jit does or doesn't optimize. In particular, for the testcase above V8 is about 30% faster than Spidermonkey on the regular array version but 5 times slower on the typed array version (possibly because they don't have fast paths in Crankshaft yet for typed arrays, whereas Spidermonkey has made optimizing those a priority).
Again, I suspect that things will look somewhat different here in a year. We'll see whether I'm right.
One problem is that usually websites contain Javascript from ad sites which can't be cached because they want to track every hit. Additionally, since scripts are allowed to do stuff like mess with the prototypes for built-in objects which will affect any code loaded after it, if any of the files are changed you probably have to throw away any precompiled code.
One the page is loaded, most Javascript engines will try to optimize code that gets run frequently, which is good when you're running a rich Javascript application. It won't necessarily help initial page load times though.
There _are_ things "wrong" with javascript that make it hard to optimize (lack of typing, very dynamic, etc).
To get a notion of where it is possible to get with a similarly dynamic language, take a look at how the LuaJIT benchmarks compare with optimized C++ and other dynamic languages. Notice it is not far behind a state-of-the-art Java VM.
Another pretty interesting aspect is this code size versus speed comparison.
You'll want fast JavaScript when HTML5 matures and applications that use Canvas become popular. If browsers don't work on making JavaScript fast now, those applications won't materialize later.
What a fool believes, he sees, no wise man has the power to reason away.