Trying out Chrome - how do they make it so fast?

[VectraMan]

For JavaScript, Google created their own scripting engine called V8 which uses a load of clever techniques to optimise execution. It also compiles to native code, rather than an interpreted bytecode, so JS applications can run at pretty much the speed of native code. This has led to a speed war amongst the browser makers: Firefox's TraceMonkey beats V8 on some benchmarks, Safari's Squirrelfish Extreme (which also compiles to native code) claims a 36% improvement over V8, Opera's Carackan (native code compilation again) hasn't quite caught up with WebKit and Chrome yet (though they're working on it), and the IE Team claim that the latest preview of IE9 has overtaken Firefox.

Point of order: just because something converts to native code doesn't make it as fast as native code. It's quite easy to convert interpreted bytecode to native code: you just make the native code do the things the interpreter would do. Doesn't make it the same as native code from a language like C++.

Seems to me JavaScript has a fundamental problem: it's still dynamically typed. If they'd get organised and adopt something similar to the ActionScript 2 style class system (as was in the now defunct ECMAScript v4 spec IIRC), a) it would become a much more realistic language for the larger scale applications webists want us to write and win over the real programmers, and b) strong types would help enormously with optimisation and in many cases could rival C++ for performance.

It's a shame with all this newfangled attention on JavaScript, nobody's bothered to improve the language.

Quite impressive IE9 animation demos on that link above. Is using the GPU unique to IE9, or are Firefox and Chrome et al going to catch up?

[d000hg]

Um, dynamic typing is a deliberate feature of the language. If they wanted it to be C they'd have used C. Higher level languages let you write code faster do do more complex stuff, the job is then to minimise the performance impact that results.

[NickFitz]

Point of order: just because something converts to native code doesn't make it as fast as native code. It's quite easy to convert interpreted bytecode to native code: you just make the native code do the things the interpreter would do. Doesn't make it the same as native code from a language like C++.

That depends on how you generate the code. V8 isn't a simple bit of kit doing trivial conversion from bytecode to native code by some proces akin to stringing a bunch of macros together: it creates a highly-optimised internal representation of the code, using a variety of techniques.

Seems to me JavaScript has a fundamental problem: it's still dynamically typed. If they'd get organised and adopt something similar to the ActionScript 2 style class system (as was in the now defunct ECMAScript v4 spec IIRC), a) it would become a much more realistic language for the larger scale applications webists want us to write and win over the real programmers, and b) strong types would help enormously with optimisation and in many cases could rival C++ for performance.

The language is dynamically typed, but that doesn't mean that the runtime has to lose performance by doing dynamic property lookup. V8 internally converts dynamic JS objects to hidden classes. For the vast majority of cases, the code runs with the same advantages as statically-compiled code.

Many of the details are available at the V8 project site (and of course it's open source, so you can read the code to see exactly what's going on if you wish).

It's a shame with all this newfangled attention on JavaScript, nobody's bothered to improve the language.

I think ECMAScript 5 adds much that is of value (particularly strict mode), and ECMAScript Harmony will move things on even further.

Quite impressive IE9 animation demos on that link above. Is using the GPU unique to IE9, or are Firefox and Chrome et al going to catch up?

I believe FF3.7 is scheduled to have it, and doubtless everybody else will follow suit sooner rather than later

[Shimano105]

Chrome doesn't support NoScript plugin, so for that reason I'm out.

[NickFitz]

Chrome doesn't support NoScript plugin, so for that reason I'm out.

NoScript isn't a plugin, it's a Firefox extension, so it's hardly likely that a different bit of software will support it.

If you want NoScript for things like blocking JavaScript, blocking images from advertising sites, or disabling plugins like Flash, then you can do all that in Chrome's preferences with no extension needed: go to the "Under the Hood" tab and click "Content settings...". Note that you have the option, for each of the content types shown there, of either blacklisting all sites and then adding acceptable sites to a whitelist, or whitelisting all sites and blacklisting unacceptable sites.

[VectraMan]

The language is dynamically typed, but that doesn't mean that the runtime has to lose performance by doing dynamic property lookup. V8 internally converts dynamic JS objects to hidden classes. For the vast majority of cases, the code runs with the same advantages as statically-compiled code.

That's very clever, but obviously relies on the programmer using Javascript's pesudo-class implementation (i.e. using a constructor function). If the programmer just uses new object() and adds properties to it willy nilly, then it can't possibly do the same as it has no way of knowing what the properties will be. May as well have classes; it's less confusing than messing about with prototypes.

I was more referring to the low level lack of type problems. For example, in C++, if you have a + b and the compiler knows a and b are ints, then it just inserts the code to add two ints In Javascript, it doesn't know what the types are, so you end up with this sort of thing:

typeA = GetType(a)
typeB = GetType(b)

if(typeA == int AND typeB==int)
{
   integerAdd (a,b)
}
else if (typeA == string AND typeB == string)
{
  stringAdd(a,b)
}
else if(typeA == string AND typeB == int)
{
  AddIntToString(a,b)
}
else ....

You get the idea. I've worked on a Javascript interpreter (one that produces a stack based bytecode and interprets it), and that's the sort of thing it has to do all the time and not suprisingly slows everything up (it also does the property name lookups by string compares!). Unfortunately I can't really justify rewriting it.

I'm sure the new engines are very clever and can predict a lot to solve these problems, but it can't predict everything. But it could with the relatively simple addition of strong typing.

And Google obviously agree with me about JS not matching true native code because they're pushing ahead with their plans for sandbox'd downloaded native code.

[d000hg]

JS doesn't need to be as fast as C++... few apps are written in C++. If they can get it as fast as Java or Python that's good enough...

[NickFitz]

That's very clever, but obviously relies on the programmer using Javascript's pesudo-class implementation (i.e. using a constructor function). If the programmer just uses new object() and adds properties to it willy nilly, then it can't possibly do the same as it has no way of knowing what the properties will be. May as well have classes; it's less confusing than messing about with prototypes.

No, that's just the way Google chose to present their example. Dynamic adding (and removal) of properties is the case that this technique is designed to address: given that the technique of using pseudo-constructors is just a special case of the general case of adding properties to instances of Object, they solved the problem for the general case, not the special case.

For example, the following code:

var foo = {};
foo.bar = 1;
foo.baz = 2;

var blob = {};
blob.bar = [];
blob.qaz = 'a';

var x = {};
x.bar = foo;

will result in the following activity within Chrome:

// assume hidden class A represents an object with nothing but default properties
foo becomes an instance of existing hidden class A;
foo has property "bar" added: it becomes an instance of new hidden class B, which descends from A;
foo has property "baz" added: it becomes an instance of new hidden class C, which descends from B;

blob becomes an instance of existing hidden class A;
blob has property "bar" added: it becomes an instance of existing hidden class B;
blob has property "qaz" added: it becomes an instance of new hidden class D, which descends from B;

x becomes an instance of existing hidden class A;
x has property "bar" added: it becomes an instance of existing hidden class B;

// so at this point:
//     foo is an instance of C
//     blob is an instance of D
//     x is an instance of B

delete blob.qaz;
// blob can now go back to being an instance of B

There's more to it than that, but that's the basic principle of creating hidden classes; with those classes backing the objects, such things as accessing blob.bar no longer involve accessing a dynamic property lookup (as in traditional implementations), as class B knows the specific offset of that property within the memory allocated to hold that object.

Although Google's examples use the "new" keyword and constructors, all that really does is the same kind of thing as the above, with the addition of setting the "prototype" property of the new object. According to Brendan Eich, this was only added to the language at the behest of Netscape's marketing people, who wanted it to look more like Java. At ClientOrg last year, we outlawed the use of "new" almost completely and didn't miss it.

I was more referring to the low level lack of type problems. For example, in C++, if you have a + b and the compiler knows a and b are ints, then it just inserts the code to add two ints In Javascript, it doesn't know what the types are, so you end up with this sort of thing:

typeA = GetType(a)
typeB = GetType(b)

if(typeA == int AND typeB==int)
{
   integerAdd (a,b)
}
else if (typeA == string AND typeB == string)
{
  stringAdd(a,b)
}
else if(typeA == string AND typeB == int)
{
  AddIntToString(a,b)
}
else ....

You get the idea. I've worked on a Javascript interpreter (one that produces a stack based bytecode and interprets it), and that's the sort of thing it has to do all the time and not suprisingly slows everything up (it also does the property name lookups by string compares!). Unfortunately I can't really justify rewriting it.

Anything involving mutiple if...elseif cases (or switch statements, which are the same thing) is crying out for lookup tables (or a more OO solution). I would have gone with something like (pseudocoded in JS, just for simplicity):

function concatenateStrings(first, second) {
    // allocate new buffer having length first.length + second.length
    // copy first into new buffer
    // copy second into new buffer at offset first.length
    // return new buffer as type string
}

function concatenateStringAndNumber(string, number) {
    return concatenateStrings(string, number.toString(10));
}

function addNumberAndString(number, string) {
    return addStringAndNumber(string, number);
}

function addNumberAndNumber(number1, number2) {
    // return the sum of the two numbers
}

addFunctions = {
    string: {
        string: concatenateStrings,
        number: concatenateStringAndNumber
    },
    number: {
        string: addNumberAndString,
        number: addNumberAndNumber
    }
};

function whatWeDoWhenAdding(value1, value2) {
    addFunctions[typeof value1][typeof value2](value1, value2);
}

Although most implementations use hashed dictionary lookups for properties, Google's hidden classes fix that.

I'm sure the new engines are very clever and can predict a lot to solve these problems, but it can't predict everything. But it could with the relatively simple addition of strong typing.

I tend to be pretty disciplined about passing and returning the correct types in my JS code, but enforcing strong typing would remove too much of the flexibility from the language, and that is one of its major strengths.

And Google obviously agree with me about JS not matching true native code because they're pushing ahead with their plans for sandbox'd downloaded native code.

Google's Native Client is an interesting project, but it isn't intended to supplant JavaScript. Not even Google expects people to start firing up gcc and compiling executables for the sake of sticking a drop-down menu on a web page.

[d000hg]

For the love of God Nick, get a job!

[NickFitz]

For the love of God Nick, get a job!

This IE6 bug on the Private Messages page kept me busy for a while today