Thursday, February 5th, 2009

Opera comes out with new JavaScript engine in Carakan, new hardware API in Vega

Category: JavaScript, Opera, Performance

<p>Opera isn’t sitting on their heels as the other browser vendors get snappy (even if other claim so!)

Today they announced Carakan a new register based JavaScript VM that is currently 2.5 times faster than their existing one (based on SunSpider). It does native code generation including at specializing for Regex (interestingly since irregex for Chrome was just announced too). Here is their words:

We have focused our efforts to improve upon our previous engine in three main areas:

Register-based bytecode

The last couple of generations of Opera’s ECMAScript engine have used a stack-based bytecode instruction set. This type of instruction set is based around a stack of values, where most instructions “pop” input operands from the value stack, process them, and “push” the result back onto the value stack. Some instructions simply push values onto the value stack, and others rearrange the values on the stack. This gives compact bytecode programs and is easy to generate bytecode for.

In the new engine, we’ve instead opted for a register-based bytecode instruction set. In a register-based machine, instead of a dynamically sized stack of values, there’s a fixed size block of them, called “registers”. Instead of only looking at the values at the top of the stack, each instruction can access any register. Since there is no need to copy values to and from the top of the stack to work on them, fewer instructions need to be executed, and less data needs to be copied.

Native code generation

Although our new engine’s bytecode instruction set permits the implementation of a significantly faster bytecode execution engine, there is still significant overhead involved in executing simple ECMAScript code, such as loops performing integer arithmetics, in a bytecode interpreter. To get rid of this overhead we are implementing compilation of whole or parts of ECMAScript programs and functions into native code.

This native code compilation is based on static type analysis (with an internal type system that is richer than ECMAScript’s ordinary one) to eliminte unnecessary type-checks, speculative specialization (with regards to statically indeterminate types) where appropriate, and a relatively ambitious register allocator that allows generation of compact native code with as few unnecessary inter-register moves and memory accesses as possible.

Automatic object classification

Another area of major improvement over our current engine is in the representation of ECMAScript objects. In the new engine, each object is assigned a class that collects various information about the object, such as its prototype and the order and names of some or all of its properties. Class assignment is naturally very dynamic, since ECMAScript is a very dynamic language, but it is organized such that objects with the same prototype and the same set of properties are assigned the same class.

Nice to see, and interesting that the browsers aren’t (or aren’t able too?) share their VM work. Each browser has a new VM implementation going. Wouldn’t it be nice if they could share effort?

Then we have Vega a vector graphics library that Opera uses to power SVG, Canvas, and more.

Vega was created shortly after we started working on SVG support.
When we added SVG support in Opera we needed a vector graphics
library. We looked into what what available to use and met our
requirements (fast, low memory usage and works on platforms
ranging from phones to TVs and desktop computers). We did not
find and good match for our needs, so we decided to write our
own.

Shortly after we created Vega we added <canvas> support, which
also uses Vega.

The most recent addition to Vega is the ability to use a
hardware accelerated back-end. The back-ends we are using at the
moment are OpenGL and Direct3D.

A busy day for Opera!

Related Content:

  • IT Channel News Briefs, Aug. 15
    Carl Icahn gets his men on Yahoo's board, and SAP rolls out its TechEd 2008...
  • MapReduce Part II
    MapReduce is a distributed programming model intended for parallel processing of massive amounts of data. This article describes a MapReduce...
  • MapReduce Part II
    MapReduce is a distributed programming model intended for parallel processing of massive amounts of data, as discussed in the previous article of this...

Posted by Dion Almaer at 12:01 am
10 Comments

++++-
4.5 rating from 35 votes

10 Comments »

Comments feed TrackBack URI

SunSpider is a JavaScript benchmark. SpiderMonkey is a Gecko’s JavaScript engine.

Comment by lowik — February 5, 2009

I think everyone here knows that.
.
What Dion meant is that “Carakan VM [...] is currently 2.5 times faster than their existing one (-according to- SunSpider)

Comment by ywg — February 5, 2009

Ok. My mistake sorry.

Comment by lowik — February 5, 2009

Shame we won’t get Carakan and Vega with Opera 10.

Comment by BartekG — February 5, 2009

I don’t understand, they invest all this time an energy in engineering better Javascript and graphics, but they won’t spent the relatively tiny amount of effort to address the user interface problems that have dogged their product for years. Their sheer bloody-minded refusal to produce a more attractive or flexible UI is baffling, as it surely puts off far more users than the lack of a register based VM.

Comment by Amtiskaw — February 5, 2009

What do you reproaches to Opera UI (except their ugly dark skin) ?
.
It seems pretty good for me. If you look a few years back (firefox 1.5) you’ll see that Opera UI stayed pretty much the same while Firefox took a lot to Opera.

Comment by ywg — February 5, 2009

Wouldn’t it be nice if they could share effort?
I think competition is better medicine in this case. Its still soon to tell which browser’s engine approach will be the fastest. Though from what I understand from Andreas Gal’s paper and writings, I think Mozilla+Adobe has a very realistic chance with their approach. Guess we’ll have to wait and see, and keep checking those benchmarks

Comment by TNO — February 5, 2009

@ywg
The dark, ugly skin. The equally ugly windows native skin. The ugly tabs, that don’t mesh with the content below. The ugly, inconsistent, blurry icons. The horrible toolbar system: I can’t move the tab bar below the address bar, so to get the tabs on the bottom I have to clone the address bar into the main bar and disable the address bar. Dragging an icon clones it rather than moving it. I can’t move/disable the file menu bar (I have a 26″ wide monitor, so I’m wasting a huge horizontal strip). Just the general cheap and thrown-together feeling of the whole interface.

Comment by Amtiskaw — February 5, 2009

@Amtiskaw
I hate the default setup of Opera (lots of buttons, dark theme, etc.) but when it comes to change things according to your own preferences Opera’s UI is actually the most flexible out there (not counting coding your own add-ons for Firefox).

First thing: there’s no other browser with a theme as good as Tango CL IMHO. And the big thing is that you don’t have to visit any page and/or restart the browser to install the new skin.
Tabs bar? Well, I prefere tabs above address bar but it is possible to move them below. As you’ve said you can clone the address field, and another way is described there: http://my.opera.com/Tamil/blog/tab-bar-below-address-bar
I admit that being forced to utilize such tricks is annoying (especially when you reinstall the browser often) – but it’s still easier than playing with tabs in other browsers, where they are almost untouchable.
As for disabling the file menu bar: this one is pretty much straightforward http://my.opera.com/Tamil/blog/toggle-remove-menu-bar

Comment by BartekG — February 5, 2009

If they share the VM engines, there’s no competition, and less incentive to push for better and faster implementations. This way they keep trying to outdo each other – and that’s good.

Comment by iliad — February 5, 2009

Leave a comment

You must be logged in to post a comment.