Slashdot Mirror
Revamped WebKit JavaScript Engine Doubles In Speed
Shin-LaC writes "In a post on their official blog, WebKit developers introduced the 'next generation' of their JavaScript engine, SquirrelFish Extreme, claimed to be twice as fast as its predecessor. The post lists several changes contributing to the performance improvements, including 'bytecode optimization,' a 'polymorphic inline cache' (which sounds similar to V8's 'hidden class transitions'), and a 'context threaded JIT' compiler which generates native code (currently only for x86 processors), and is also applied to regular expressions. The new JavaScript engine is already available in the latest WebKit nightly builds. According to comparative benchmarks, the new engine is around 35% faster than the V8 engine recently introduced in Google Chrome, and 55% faster than Mozilla's TraceMonkey."
Excuse me, but I think that Tracemonkey is actually faster than V8. Has Tracemonkey really fallen that far behind in two weeks?
Firefox 3.1 (pre-release) uses less memory than Firefox 3, which uses less memory than Firefox 2. Compiled javascript takes a tiny fraction of the total memory used by a web browser. The vast majority is uncompressed bitmaps and string fragments.
Why? Does apple even sell those anymore?
Once you start despising the jerks, you become one.
There are very few popular sites that are too slow, because web developers do not like to make slow sites. If a web developer does make a slow site, it doesn't become popular because users are too impatient and go to faster ones.
That's really the whole point of the recent focus on JavaScript performance. Web developers want to make complex sites to support the features the users want, but they cannot because all those features make the sites too slow. Google especially wants to develop a web-based Office-killer suite. That's why they developed Chrome with a very fast JavaScript engine, minimal chrome to make web apps more like local apps, and put each tab in a separate process so you can kill those memory- and CPU-hungry sites when you need to.
What a fool believes, he sees, no wise man has the power to reason away.
Yeah, except that it's JavaScript, traditionally one of the slower languages because it's objects are basically hashtables. The improvements you see are going to be mostly to fastpathing past those hashtables. This unfortunately means that the improvements you see in JavaScript are unlikely to port to other languages since those improvements are to a feature that isn't used in most other languages. (Lua and Python may be exceptions.)
Mostly correct. Netscape made money selling their horrid web server in corporate environments. They were giving the browser away for free for non-commercial users. If the truth were told, back when Netscape was a relevant browser, most of my coworkers were grabbing the free, non-commercial version and installing it at work. And Netscape didn't really care, as they were giving away their browser in order to drive sales of their server. Netscape's server arm survived for a loooong time, finally becoming the basis for Sun's application server. IIRC, only the newest version of Sun's app server (i.e. 9.x aka GlassFish) doesn't directly trace it's roots to Netscape/iPlanet. And let's not forget Netscape Directory Server. Or, as it's known today, RedHat Directory Server. During the dot-com era, it was one of the better LDAP implementations.
Yep. Sunspider is a pure JS benchmark, no DOM.
By the way, expect Firefox 3.1 to have faster DOM access than Firefox 3. It's being pretty actively worked on.
You should take a look at http://cappuccino.org./ Is really interesting and brings the best of both worlds.
JavaScript isn't single-threaded.
Only one JavaScript thread is used by firefox (and maybe other browsers -- I don't know).
In fact, spidermonkey is thread-safe and you can run multiple JavaScript threads outside the confines of the browser. In fact, I have written a class for spidermonkey which lets you create real OS threads running JavaScript functions.
> It still boggles me that any JavaScript from anywhere, such as from an ad, can crash the language
> and leave you with no JavaScript support at all
Out of curiosity, how many programming languages do you know that will let you keep executing code once a syntax error has been reached, or an exception has been thrown but not caught?
The problem here isn't language design, it's poor programming. And try..catch block will work wonders around other-peoples-crappy-code.
> It's very hard to count on a language when browsers implement is so badly, especially when
> you have no choice but to support really old software that keeps doing bad things that upset
> newer, stricter versions of a scripting language.
Aside from function.arguments and === in JavaScript 1.2, I'm having a hard time thinking of a JavaScript language change which was broke backwards compatibility. That includes IE. Although it would be nice if IE would fix their stupid [1,2,3,].length bug.
Do daemons dream of electric sleep()?
Others have pointed out that Netscape was actually making its money from server software, but you're missing the really big point: the Netscape browser was a piece of shit. I was an early Netscape user but I switched to IE because it was better.
If MS hadn't killed Netscape the internet now would probably be dominated by two crap standards-ignoring browsers - Netscape and IE.
Fuck Netscape, they got what they deserved.
I know nothing of WebKit, so I will not speak of it.
It is currently possible to use SpiderMonkey at the level of ff3 for real work. There's a bit of a learning curve, but it's totally usable. In theory, anything you write for SpiderMonkey-trunk will be usable with the new tracing stuff they've built. That's not in CVS, it's in hg (mercurial), and I'm not sure what state it's in right now. I'm guessing it's probably usable, too. Oh, I think the tracing code also requires a C++ compiler, although I could be wrong.
> I'd like to see a JavaScript engine with pluggable modules (sort of like TCL) and possibly a nice accessible GUI (like TK).
I have been working on something like this, and will get back it to it sooner or later. Probably early november. Unfortunately, great swaths of it is closed (it wraps trade secret libraries), but the basic infrastructure and some of the classes are open. You use it basically like any other UNIX shell interpreter.
When I get back to this project, I plan on more rigorously defining the module loading code to make it easier to extend. Right now, it's pretty easy to compile them in, but there is no good way to load DSOs and so forth. I also want to load JavaScript-language modules more elegantly.
If you want to see my early work -- which is not really all that useful unless you're planning on writing more classes in C to expose whatever it is you want to work with -- go here: http://www.page.ca/~wes/opensource/
As for GUI, I don't really know anything about GUI development, but I'd totally be up for a collaboration if somebody wanted to do simple widgets. I was thinking of ripping apart Dialog for X (nee cdialog) and cloning that functionality someday.
As of right now, I _do_ have a trivial curses interface which can put windows on a terminal, scroll output through them, and so forth. (Not in the link -- insufficient polish). I used it to put together a simple debugging environment where I type JavaScript code and it prints the results in a different window. Basically, like the debug window pair that shipped with QuickBasic 4.5.
Oh -- and the stuff I'm working on is UNIX only. Well, it should run under Cygwin.
I have also played with wsh under Win32. There is a lot of cool stuff you can do, although learning the win32 api appears to be a large and daunting task. I used it to write a simple remote media player for my house, where I could drag a file icon to a JavaScript program on my desktop, which spooled it to a UNIX server in the basement for pickup by a windows box in my living room which in turn would play the content through my home theatre... via another JavaScript program, using the windows media player control.
Do daemons dream of electric sleep()?
I don't know what the current state of the art is, but last I looked Rhino was still the fastest javascript implementation, IF you discounted the JVM start up.
IIRC, Rhino compiles JavaScript into native Java byte code, which then gets the JIT magic sprinkled on it by the JVM pixies.
So the quality of the Java compiler is really not all that relevant, because the code compiled by the compiler only compiles the javascript code once, making the quality of the compiler effectively order(1)... and given sufficiently large N, nobody cares about k.
Now, a javascript->x86 compiler.. that would be interesting. Although javascript->C or javascript->gcc-intermediate would be much nicer, because I don't live in x86-land.
Do daemons dream of electric sleep()?
Cocoa is an implementation of the OpenStep APIs. GNUstep is another implementation and runs on Windows. In Ãtoilé svn we have a theme engine for GNUstep (Camaelon), although there is not yet a native Windows theme. If you're targeting GNUstep, you aren't limited to Objective-C either - I have written a native compiler for Smalltalk which produces equivalent code to Objective-C for operations which are not heavy on arithmetic (currently much slower for arithmetic, but if you're doing a lot of number crunching you can write some methods in ObjC - with inline asm if you really need the speed - and others in Smalltalk in the same class), and we plan on adding JavaScript and Io support in the relatively near future.
Back on topic, polymorphic inline caching is absolutely nothing to do with hidden class transformations. PIC is a technique originally from the Self team (as is HCT - not surprising, since JavaScript is basically an ugly version of Self with some weird corner cases). In a dynamic language, every message send (that's method call toy any Java programmers that wandered in) is two operations; a lookup mapping the selector (method name) to a function, and a call to the function. The Self guys discovered that at most call sites only a small number of different functions were called. In Smalltalk, you would cache a small set of (class, function) pairs, and then you have a quick way of looking up the correct mapping that would work in most cases. In Self (or JavaScript) it's slightly more complicated, because the cache only works for objects which share the same prototype and do not declare a replacement mapping (HTC can make this simpler). In the Ãtoilé dynamic languages runtime I proposed and implemented a simple (and concurrency-safe) means of invalidating these caches in a statically-compiled language. This will be used in Objective-C code compiled with clang and Smalltalk code compiled with the Pragmatic Smalltalk Compiler when I finish adding support for this runtime to both (before Christmas hopefully).
I am TheRaven on Soylent News
i have a page which does some numerical simulation in javascript,
essentially an O(N^2) finding-nearest-neighbors-in-two-dimensions thing,
and here are some trials w/ 2000 points, on an x86 windows machine:
Safari 3.1.2 - ~50 seconds, maybe more
Safari 3.1.2 + Webkit - ~10 seconds
Firefox 3.0.2 - ~22 seconds
Chrome 0.2.149.30 - ~19 seconds