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.]"
64% ought to be enough for anyone.
Will it make the new /. work any faster ... or better ... or anything?
Mozilla, Apple, Opera and Google need to cut it with all of this JavaScript bullshit, and instead just need to agree to embed LLVM in the browser. Then we can target a real platform using not just JavaScript, but a whole host of other languages. Unlike JavaScript, LLVM has been properly designed from the ground up just for such uses! It's highly optimized, and it's getting better every day.
They all need to agree to do this, however, in order to have enough market share to force Microsoft into adopting similar technology. Right now Firefox and Chrome alone hold 40% to 50% of the browser market. LLVM embedded within them could truly help encourage their adoption, to bump them up into the 75% to 80% market share range.
Chrome is very fast, but can't run ajax with local files. That is a new problem for developers.
Okay, how daft do you have to be to encourage tons of people to download and install a beta quality item? Yes, some people will want it, but many people will blindly download this just to toy with it and then fail to understand why some things aren't fully functional yet.
You aren't actually helping developers if you are putting the betas in the hands of people unqualified to give meaningful feedback on them.
Sincerely, Chrome "Canary" User
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....
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?
Weren't we just on Chrome 1.0 like . . . 18 months ago?
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)
v11.0.672.2 is also a beta.
http://www.filehippo.com/download_google_chrome/
Funny how if this was microsoft claiming a speed boost on their own benchmarks, we'd have a troll-fest here...
gcc compiles C to native code, but there's a noticeable speed difference between compiling with -O0 and -O2 for most C code.
There are plenty of things people are doing in JS nowadays where the DOM is only a limiting factor because JS implementations are 10x faster than they were 4 years ago...
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
Yes, I am aware that it is not Java. I stand by my statement.
That is all.
Gone!
Chrome was already way faster than anything else (particularly upon first chrome release, it was like 10x faster than IE i thought?).
Surely some time soon we're going to stop seeing double-digit percentage improvements in performance, or were the original javascript implementations really THAT BAD?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Are you sure about this?
I don't recall gcc -O3 and -O0 having a factor of 10 difference for most tasks. And Javascript definitely isn't close to C performance, even unoptimized.
Besides, gcc -O3 can actually be somewhat slower than -O2, which is why almost nobody uses -O3 except for the Gentoo zealots.
Don't quote me on this.
Does all this JS optimization happen on loading a page?
I've noticed pages freezing up longer now, and this is my only guess as to why.
If this is the case, do these benchmarks take account of this?
Fast execution is great, but not at the price of waiting for it.
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.
Did you just suggest locally "precompiling" javascript with idle client cpu cycles? (not sarcasm. I think it's a great idea if that is the case). Can you event "precompile" Javascript currently, and if not, why not? /disclaimer: I have a very light understanding of Javascript, more of a infrastructure/networking guy. Go easy.
I find using --funroll-loops gives me the best performance when compiling.
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.
It really just depends on your code and on your compiler.... and on your hardware.
My personal experience is that the same code was fastest with -Os on hardware as of 7 years ago and when compiling with GCC 4.0 (due to i-cache effects, as near as anyone could tell) but fastest with -O3 on hardware as of a year ago and when compiling with GCC 4.5....
I was asking if that were practical, since I don't know much about the guts of this stuff. TFA's mention of optimizing code that runs frequently, and not optimizing rarely used code, gave me the impression that there is some sort of technique, presumably a species of JIT compilation, that is quite computationally expensive; but makes the code subjected to it run faster thereafter. NoSig's comment about load times suggested a similar tradeoff.
This struck me(on naive first inspection) as being something that would nicely complement the browser cache: if you have the javascript, and idle cycles, and the user isn't sitting and waiting for the page to display, you might as well apply the most aggressive optimization(some nuances would, of course, have to be adopted for battery-powered or thermally constrained devices, where idle cycles are a comparatively costly resource...)
I don't know enough about the subject to know if there is some reason why this idea is stupid; but if my inference from TFA, that you can trade a one-time, computationally expensive, operation for a speedup on every subsequent run of the code, is correct, it seems as though having a background cache-optimizer would be a comparatively simple extension of the work being done anyway, and would improve user experience for repeatedly loaded sites and/or libraries...
Assuming such a thing is practical, it would also be interesting to see how it would work built into a caching proxy. I imagine that such an arrangement would open an exciting new scope for bugs and subtle evil; but it would also allow resource-constrained clients to have some of their work done for them by much more capable devices.
IMHE(xperience), Chrome loads pages slower than Firefox with NoScript. Here's why. FF can load partial pages better. By this, I mean FF can load pages with missing or incomplete elements better. While FF will, for example, happily show me a page that is badly formatted because the style sheet hasn't been fully loaded, all that Chrome will show me is a big blank page until it can place the elements correctly on the page. To be sure, FF will dynamically reformat the badly formatted page as the page requisites are loaded, but I can always click the "X" icon to force it to stop loading the page.
Chrome is also slow to load pages that reference elements from addresses that cannot be accessed. It would take Chrome longer to load a page containing picture X from domain xxx.xxx if I've configured my router to block all access for xxx.xxx.
This is an absolutely fantastic idea.... We all tend to visit the same sites frequency. By identifying the common pieces and idle time cache compile them down and down with TypeInference and like optimizations, I think would could easily approach native speeds. Possibly using gpu hardware acceleration to assist in the parallel compiling. How bout maybe in 2-3 years, yes? Ok time to put the pipe down!
Certainly some kind of caching of JIT output should be helpful in some way. There are numerous issues that limit how helpful it can be. For one, it hasn't solved the Java issue and Java is much more amenable to this kind of thing than Javascript is. For one thing Javascript often makes heavy use of document.write which is that Javascript will dynamically write more Javascript to be run later. So the code being run can change from one page load to another even if the code is initially the same, defeating caching of compiled code.
Yeah, you would need a plugin, like flash, silverlight, webfx, or their like.
Interesting. I didn't know they got Javascript to run that fast...
Admittedly I haven't been following the bleeding edge stuff on the Javascript performance front...
Don't quote me on this.
There is no way that Javascript in the browser has anywhere the speed of even unoptimized C for anything more than the simplest 10 line programs. I just can't see how a dynamic language that's interpreted by a browser can even hold a candle to native code. Even the simplest expression in Javascript can be considered equivalent to a library call at least, as it is all being done in software. That's a kind of awkward way to put it, but the best way I can put it is Javascript is so much further from the metal than any language that compiles to native code, that there is no way C like performance could be expected from the language. That's not to say that the language can't achieve satisfactory speeds for some pretty demanding tasks. As computers become more and more powerful, levels of abstraction matter less and less. In other words, it's all relative. :/
"cached javascript"? What, just random javascript snippets from the cache? Most javascript delays occur either on page load, or after an ajax call; once your idle all the page load stuff has finished. Pre-emptively executing the onClick()s of all the links on the page and caching the result seems like a sensible optimization, until you realise it's going to play havoc with any ajax-based site. Prefetching linked-to pages in the background is a valid optimization and could include doing those page's onload javascript although, again, you have to worry about what that's going to do to more dynamic sites.
I am trolling
Gah. Once you're idle. Must be tired.
I am trolling
Javascript programmers can be 64% lazier and still get the same performance.
Javascript executed faster == you get attacked faster.
I just have a hard time accepting dynamic languages as a foundation for any significant software project. I'm not saying it's not possible, it's just a nightmare. I much prefer static languages which can be checked by the compiler before run time; plus refactoring is so much easier. All this javascript / dynamic language stuff eventually turns into a big mess, in my opinion.
How fast will Chrome 10 block an ISO H.264 video as it tries to get from HTML to my video playback hardware? I heard they are working on getting that up to instantaneously.
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.
Your comparison to gcc optimization levels is apples and oranges, it's a bit misleading and I'd be interested in hearing where you got your information. As a relative comparison I do understand it, and by rough guessing I'd say you sound close to accurate in terms of numbering for single threaded code. Thank you for pointing out how lack of typing and maintaining dynamic nature (dynamic "this" context!? F* you ECMA that's terrible!) enhances the crap factor and makes it much harder to deal with making optimizations of the language. The thing is I don't agree that just making better JIT and optimization engines will fix the problem though - it's like adding more and better lubrication to a brick: slides easier and faster but still a painful and crude brick. Getting wider spread support of different types of scripts more universally accepted and adding proper DOM handling libraries and runtime isolation to them sounds like a good solution to me. If you have Ruby installed for example you can already do scripts with type "text/ruby" (may require some setup in your browser) - it's totally insecure and interacting with elements on the page is non-trivial... but you can do it and I'd take Ruby over JS if it was made to work with the DOM and had isolation from the system.
If by competitive you mean faster by an order of magnitude.
but when will we see user friendly features like "delete my pr0n (history/cache) when I close Chrome" or "do not fail miserably at importing my firefox profile data" or "do not block any ports, i know what i am doing"...
Mod parent up, good reasoning here.
Dear /. taggers: Google doesn't care about version number at all. It is just an arbitrary number signifying their major releases (which happens every six weeks or so). Want to know how little Google cares about version number? Go to google.com/chrome . Try to find a version number. Go to Google's Chrome blog ( http://chrome.blogspot.com/ ). Try to find a version number. Google's NEVER promoted a new release of Chrome with the version number. The only people to do so are other sites who are seemingly compelled to attach a number to the new release. The number is there but only for development purposes.
Another fun fact about Chrome versioning: Versions between Developer, Beta, and Release never share the same version number. If it changes development channel, the number is increased. You'll never see a version 11.0.331.31 Beta turn into a 11.0.331.31 Release.
well-optimized (gcc -O3) C code
Thinking that gcc produces well-optimized code is a nice sunny view to have, but does not align with reality in my experience. I, too, used to think that gcc was the best compiler out there, mostly because I had not done any head-to-head comparisons, and was echoing what everyone else said.
Then, I had to write some high-performance C code. I tried everything I could get my hands on. I used every source code transformation and technique I knew. For this application, the more performance I could wring out of the application, the better. Microsoft's C compiler won hands-down on producing the fastest code and without my needing to use crazy constructs to hand-optimize the source. I spent about a week trying to use tricks to produce better-performing code than straight simple, easy-to-understand C did, and ultimately failed. The folks in their compiler group are very, very good. The speed advantage compared to other compilers was about a factor of 2x, if I recall.
Now my experience is for one very specific application that had a lot of number crunching and a lot of memory accesses, and one application does not prove very much. But gcc is, in my experience, only OK.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
js is catching up to python, java, quickbasic, perl etc. never to c++.
but c++ is still faster, of course, or even normal bytecode java. it's just that google has a marketing department for v8, this is already the n:th pretty much identical article about how they've made js faster, yet fail to provide ANY NEW USE CASE BECAUSE OF THE ADDED SPEED, just empty quotes that "it's faster trust us".
like, why don't they run some box2d js demo on it, would be pretty easy enough to use such to show that hey, you can have 1000 boxes with the old one and 1600 now.
This sounds like a really hot idea! So hot actually, I wouldn't be surprised were it spotted in another compiler.
That's one of the features of IE9 javascript engine, it uses a second CPU core to compile the javascript
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.
So even if some of the code is only used on rare occasions, how is it smart to only optimize some of the code instead of all of it? And if the argument is "it takes longer to optimize the code than it does to run it" then one would have to wonder if it takes longer to decide what to optimize than it does to run it.
results vary widely. Try using gcc on SPARC sometimes and prepare to be really unimpressed, at least as compares to acc.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Well, this is historically true, but projects have started to crop up that take Javascript outside of the browser for various reasons. The projects are generally largely influenced by CommonJS as a standard. RingoJS adheres to the standard and is built ontop of the JVM and Narhwal. Node.js is built ontop of v8 and takes a different approach focusing on the common idea of Javascript as an evented programming environment. While these may not have the libraries that exist for Java/C++ as of yet, they do show promise and the growth of Javascript as a programming language available for various tasks. In fact, when dealing with Windows maintainance/automation already I prefer JScript over VB which has been around for quite some time through wscript and cscript.
Meanwhile the bytecode comment is a bit wrong. Yes, most modern Javascript engines don't compile down to bytecode, they do however compile down to machine code to be run on bare metal (API extensions/host objects generally need caging however). As for load times, I know that v8 implements snapshots that are compiled down bytecode for the express purpose of it being faster to load up than reparsing.
Anywho~ Just some research for ya.
Will Web Workers mitigate the multithreading issue?
I don't know the latest benchmarks, but most programs arn't app. code bound anyway - they depend more on graphics, I/O (disk, network), external servers (web), etc.
Where pure CPU speed is an issue a language like C/C++ that was designed to map 1:1 to hardware always has a potential edge at least in allowing a human to cleverly code something, but optimizers are getting better all the time and a JIT compiler has the potential benefit of run-time information which a pre-compiled binary doesn't (not that a pre-compiled binary couldn't be instrumented by the compiler to gather run-time into to be feed back into the optimizer for the next compilation - I believe such compilers already exist).
Modern CPUs are also crazy fast, so for many apps, even if CPU is the limiting factor, the real-world difference is not important (who cares if your list gets sorted in 0.0001 or 0.0002 seconds)..
Having said all that, there will always be a few applications that are CPU bound, and where run-times are long enough that the difference in efficiency really does make a difference, and you're never going to see languages that trade efficiency for ease-of-use being widely used in those situations. Java is certainly such a language.
Yeah, lots of very smart people working on making javascript much faster.
Too bad perl, python, ruby aren't getting faster as fast.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=pypy
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python3
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=python
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=tracemonkey&lang2=gpp
I suspect the pi digits algorithm used by the javascript bench is not as good as the one used in python.
http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=pypy&id=5
http://shootout.alioth.debian.org/u32/program.php?test=pidigits&lang=tracemonkey&id=1
> Your comparison to gcc optimization levels is apples
>. and oranges,
Well... any inter-level comparison is, to some extent.
> it's a bit misleading
How so?
> I'd be interested in hearing where you got your
> information.
Which information? The performance numbers? I wrote some code, and then timed how long it takes to run: the usual way. ;)
> Getting wider spread support of different types of
> scripts more universally accepted and adding
> proper DOM handling libraries and runtime
> isolation to them sounds like a good solution
> to me.
It also greatly expands the complexity of the VM: for example now you have to deal with GC across multiple language runtimes. Even just GC across the two languages in modern browsers (JS and C++) is a huge pain...
For what it's worth for a while there Gecko supported python for extension authors. No one used it; the support has now been removed as a result (since it made the code more complex and slowed down things people _did_ use). It'll be a hard sell to convince us to put the functionality back given that experience.
There's always a more helpful, more specific URL.
Oh, I don't think gcc is the best compiler by any means, especially since I have good data to the contrary. As you say, MSVC has much better code generation.
But on simple numeric benchmarks, GCC does produce pretty good code, as does any other sane compiler. The point being that these benchmarks are _simple_ and hence easy to optimize.
I would think so but I wonder if there are benchmarks to show how much improvment they can bring about.
> Well... any inter-level comparison is, to some extent.
I meant inter-language.
It's not just Javascript. We've been living with abysmally sub-optimal implementations of dynamic languages for about two decades.
There are lots of techniques for implementing dynamic languages efficiently. Lisp implementations from the 80s, in particular, used tons of techniques to give really good performance. However, all of that has been lost from the collective consciousness of programmers. The leading dynamic languages are Javascript, Python, Ruby and Perl, and their leading implementations have always sucked.
But basically, as much as Javascript sucks, since it's the web standard and the web is seriously important (read mega-$$$$), there is serious effort to make it go as fast as possible, so techniques are being rediscovered or found.
Are you adequate?
Yeah, lots of very smart people working on making javascript much faster.
Too bad perl, python, ruby aren't getting faster as fast.
Luckily, Lua is. :D
Though I do prefer Python, I've got to hand it to the moonies, they're fricken fast!
The wise follow a damned path, for to know is to be forsaken.
Even Gentoo warns against using -O3 on the entire system.
The most fundamental problem with Javascript is the fact that modern browsers encounter JS code, compile it into machine code, and run that.
JS was initially interpreted and therefore the code could be limited in function. Machine code is not limited in function...
What if C had been chosen instead of JS? I wouldn't want my browser compiling to machine code and running any C code that any website (or 3rd party plugin for that website) delivered to my browser... Why do we allow JS Engines to do this? For Speed!?
It only takes one error in the JS engine and then we're running machine binary code coming from unknown sources.
Compare this to an interpreted language where no data (including scripts downloaded from remote sources) except the engine is flagged as executable. There is a much smaller attack surface when you don't just compile and flag executable any code you find littering the Internet (as modern browsers do).
IMHO, there is no fundamental design issue -- Interpreted Dynamic Typed languages are expected to be slower than Static Typed languages. To increase speed we must trade security, code complexity (and possibly memory). The security trade off for speed approach that modern JS Engines employ is the real appalling fundamental problem to me.
Both Java and C/C++ are strongly typed languages, which give a lot of information to the compiler and (in the case of Java) runtime. The question here is how much optimization people can do on a loosely typed language like JavaScript... Apparently they can do quite a bit because JS today is screaming faster than a few years ago.
You would expect that, all things being equal, the languages with a runtime (including JavaScript) should beat out those without because they can do things that you can't do statically. People who religiously believe that Java couldn't beat C/C++ simply failed to understand what is going on... Both languages have about the same amount of info, both have a compiler, but one has a runtime that is also a compiler that can go on analyzing and optimizing as the program runs... Which one wins in the long run? Duh.
So the question then is whether JS having a runtime can allow it to work around the lack of type information in the code. Runtimes can do things like observe the type usage and "optomistic inlining" that in some cases may compensate for the loose types. But there may always be cases where there is a penalty for loose types.
Here's an idea, why don't browsers allow developers to embed direct C code. each browser includes some standard static libraries for the calls the code can make, which would provide the sandboxed environment. When the page loads, the browser can fire up gcc to do the compiling prior to running. Everything would then be native, No more effort spent on trying to optimize a language what wasn't meant to be fast in the first place. it would be much more power efficient to run on mobile devices too as you don't have to have the overhead these dynamic languages impose like garbage collection, and tracing/optimzation.
Why do we care about javascript in webpages. Its irritating and takes forever to load. I find it nearly as bad flash. The only time time i run into using it is when I log into skillport. I am by no means a programmer or a web page designer so I am curious why we care about it. I hardly run into anything that needs it and when I do its usually irritating as hell to deal with. Also, sorry for my ignorance, is there anything in html 5 that could take to place of JAVA like with it is doing with flash.
There are several probalems with that idea. First, C allows you to do arbitrary things to the point where it's very much not amenable to sandboxing. And I'm not talking about the standard library. Most simply, you can fill memory with binary code and then jump to it directly. Now we can talk about ways to restrict the C code you can write so as to mitigate things like this, restrict which pages are writable and which are executable, etc, etc, but it won't be quite C anymore, and the exact language subset it will actually be needs to be defined. And all of this will just convert execution of arbitrary code into a SIGSEGV, which is not great for a "sandbox" either.
Second, compiling C is not necessarily all that fast. Compile time does matter for the web. I would welcome data about relative compile speeds of C and JS, though; I don't have hard data on this.
Third, how do you propose dealing with memory leaks? Given what most web JS looks like, I would NOT be trusting these people to not leak in their C code. You see GC as an overhead; I see it as a required part of the sandbox.
Fourth, the browser would have to ship a C compiler, linker, etc, since most end-user systems don't have one. Doable, obviously, but C compilers are not small things.
Fifth, the cost of downloading C source code that does the equivalent of what a major web app does today in JS could be prohibitive: JS is a much higher language than C and tends to be a lot more concise, even when authored in brain-dead ways.
Sixth, writing actual portable C is not all that easy, especially because a lot of tutorials recommend doing various non-portable stuff. I very much doubt, again based on the quality of the JS I see on the web, that this would happen. If you're lucky, this would just mean that the site in question would not work right on 64-bit (or 32-bit, or big-endian, or little-endian, or whatever) hardware. If you're not lucky, it will crash.
What you propose is perhaps worth it, but C is the wrong language. Then you have to ask yourself what the right language is, and whether it's easier to create it or to evolve JS in the direction of being that right language under opt-ins of various sorts: ES5 strict mode, which disallows some hard-to-optimize stuff, the various Harmony proposals, and so forth.
> JS is a much higher language than C
Higher _level_ language. I have got to stop commenting on /. at 2am....
While I've used Lua (for some MMO customizations :) ) and don't really do much javascript, I wonder if one day we might start seeing lots of scripts with "#!/usr/bin/tracemonkey" or similar... :)
An old rule of thumb was, if an assembler version runs at 1, a C version runs at 10, a threaded interpreter (e.g. Forth) at 100, and BASIC at 1000.
From a language side, much of the problems you mentioned can be solved via the provided sdk. Like the old CS saying, all computer programming problems can be fixed with adding another layer of indirection. e.g. Memory leaks can be controlled through malloc by just discarding the block after the user leaves the page.
Difference between this and javascript would be that there's little waste features like a GC that runs in the background. Overall getting C/C++ to compile has much more research and accumulated experience then Javascript. This would close the 10x gap between current native JS vs C app.
>compiling C is not necessarily all that fast. Compile time does matter for the web. I would welcome data about relative compile speeds of C and JS, though; I don't have hard data on this.
JS is now both interpreted and compiled. It is first run in interpreted mode, when the optimizer figures out which code/function should be optimized, it would compile that block, and point the execution pointer of that call to the new native code instead of running the interpreted branch. Thus compilation runs on a backend thread and time is somewhat irrelevant. Same could be done for C.
This actually brings an interesting point, why compile from source each time, huge amount of processing power is wasted from analyzing the syntax and performing the first few passes on the code. This would suck the power from a mobile device quicky. A better solution is to include an intermediary bytecode directly into the page. It would require very little translation/linking to convert into final native code.
> much of the problems you mentioned can be
> solved via the provided sdk.
How exactly do you solve "jump to arbitrary memory" with an SDK?
> all computer programming problems can be fixed
> with adding another layer of indirection
At the cost of performance, as usual for layers of indirection.
> Memory leaks can be controlled through malloc
> by just discarding the block after the user leaves
> the page.
There are plenty of pages that users never leave nowadays (gmail, facebook, twitter, etc).
> JS is now both interpreted and compiled.
That depends on the implementation.
> It is first run in interpreted mode,
This is not true in V8, say. It has no interpreter (which is why it's not portable to architectures for which it has no jit backend, by the way). I can't speak to what Carakan and IE9's JS implementation do here.
> Thus compilation runs on a backend thread
Spidermonkey does not compile on a background thread. I can't speak to the others with certainty, but I'm pretty sure V8 doesn't either, nor JavaScriptCore. The closed-source implementation I have less infomation on.
Trying to do this is a worthy goal, but it's not happening yet, and there are some difficulties with doing it.
> and time is somewhat irrelevant
Not really, no. See above.
> why compile from source each time
There is talk of caching compiled forms, yes.
> A better solution is to include an intermediary
> bytecode directly into the page.
The choice of the particular bytecode presupposes particular VM implementation strategies, typically. It also makes some optimizations easier while others are harder or impossible.
Witness the fact that the actual "bytecode" used by current browsers that use it (e.g. V8 does not) is different between different implementations.
I think you're assuming a uniformity of implementations strategies for JS that's just not there, not least because as you pointed out this is an area of active research.
Bugger! Now i only have time to make a coffee while a slashdot page loads - i used to be able to make dinner!
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
Javascript V8 (v9 presumably) according to this benchmark is 4x slower than C. Not bad at all, IMO.
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
According to this benchmark V8 is 4x slower than C/C++. From my perspective that's "somewhere close" to C's performance. Compared to the 10x+ bench for most scripting languages including other Javascript implementations, it's pretty darn respectable. And if they just improved it by another 60% for many applications, that's a big deal..
Yeah - and LuaJIT is mindboggling for a scripted language (admittedly JIT'ed like Java).. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php