JetStream performance results

The V8 team has been working hard on improving JavaScript performance recently, where performance means both peak performance (as in throughput of long running computations) as well as user visible latency (as in time wasted not doing useful work towards completing a computation or rendering a website).

It is not always easy to improve both throughput and latency, especially since it usually introduces latency to generate the perfect code for optimal throughput. So there's always a trade-off to consider. Also the existing benchmark suites used to focus on either latency (i.e. the SunSpider 1.0.2 JavaScript Benchmark) or throughput (i.e. our own Octane benchmark), but not both.

Apple tried to address this problem by introducing a new benchmark suite that aims to combine latency and throughput benchmarks with roughly equal weighting, the JetStream benchmark suite. It contains benchmarks from both SunSpider and Octane, but also additional interesting benchmarks, like various Emscripten compiled C/C++ programs.

So JetStream seems to be a good candidate to measure our progress on improving overall performance of Chrome/V8 (considering both throughput and latency). As you can see from the chart below, we have been doing well pretty lately. Chrome 44 (current canary build) beats both Firefox and Safari, and we're working on reducing the latency further for the next release. The numbers were measured on a MacBook Pro (Mid 2012 / 2.3 GHz Intel Core i7 / 16 GB) running OS X 10.9.5.

Published: 2015-04-14 — Comments

Cross-compiling V8 for the Raspberry Pi

The Raspberry Pi is probably the most popular Linux ARM device nowadays (not including the ARM based Android smartphones and tablets) and V8 is the most popular JavaScript engine, so chances are you may want to run (a recent version of) V8 on the Raspberry Pi. Building on the device is an option, but that takes ages. So you will probably want to cross-compile V8 on your powerful Linux workstation instead.

To do this for Raspbian, you'll need to install the cross-compile toolchain first (see this guide for detailed instructions). Assuming that you installed the tools to $HOME/Applications/rpi/tools, run the following command from your V8 checkout:

$ make AR="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-ar" CXX="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" LINK="$HOME/Applications/rpi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++" armv7=false armfloatabi=hard arm

This will build a debug version of the V8 shell in out/arm.debug/d8 and a release version in out/arm.release/d8.

Published: 2013-08-25 — Comments

How to fix the hostname of your Strato V-Server

The Strato Linux V-Servers always reset their hostnames to on boot, no matter what you put in /etc/hostname and there's no way to fix this (it's actually intended behavior). If you happen to have a Strato V-Server running Debian, here's a simple failsafe way to fix the hostname early during boot and have all daemons use your desired hostname.

Assuming that your desired fully qualified hostname is, then create a new file /etc/init.d/ with the following content

#! /bin/sh
# Provides:          strato-hostname-fix
# Required-Start:       
# Required-Stop:        
# Default-Start:     S  
# Default-Stop: 
# X-Start-Before:    hostname
# Short-Description: Fix the Strato overwritten hostname.
# Description:       Fix the hostname in /etc/hostname and /etc/hosts that
#                    was previously overwritten by the Strato V-Server.
. /lib/init/
. /lib/lsb/init-functions
do_start () {
        sed -i \
                -e 's/h[0-9][0-9]*/www/g' \
                -e 's/stratoserver\.net/' \
                /etc/hostname \
        exit $? 

case "$1" in
        echo "Error: argument '$1' not supported" >&2
        exit 3
        # No-op
        echo "Usage: [start|stop]" >&2
        exit 3


and setup the script using the following command:

$ sudo insserv /etc/init.d/

Afterwards just reboot the machine. The above was successfully tested with Debian 6.0.4 (squeeze), and should also work with recent Ubuntu versions.

Published: 2012-04-26 — Comments

arm-linux-gnueabi cross compiler for OS X

I spent some time getting a decent cross compiler toolchain for arm-linux-gnueabi running on Mac OS X, including GNU binutils 2.22, gcc 4.6.2 and OCaml 3.12.1. The cross compiler toolchain targets ARM boards running Debian/armel squeeze or later.

The stuff is available from my local MacPorts repository. To get it working on your Mac, make sure to update to the latest MacPorts first, using:

$ sudo port selfupdate
$ sudo port upgrade outdated

Continue by cloning my MacPorts repository and editing the MacPorts sources.conf file (as superuser):

$ git clone git://
$ cd MacPorts/ports
$ sudo vim /opt/local/etc/macports/sources.conf

Add a new line to the file before the line with the [default] tag

file:///path/to/MacPorts/ports [nosync]

where /path/to/MacPorts is the path to the MacPorts repository clone. Once done, run

$ portindex

in the MacPorts/ports subdirectory to add the ports from my local MacPorts repository to the list of available ports (remember to rerun portindex everytime you pull from my repository). Now you can continue installing the cross compiler ports, using either

$ sudo port install arm-linux-gnueabi-gcc

to install just the binutils, gcc and the basic runtime, or

$ sudo port install arm-linux-gnueabi-ocaml-compiler

to also install the OCaml cross compiler and its runtime. Installing the toolchain will take some time depending on the available bandwidth and the overall speed of your machine.

Once done, your new cross compiler will be ready in /opt/local, with its system root in /opt/local/arm-linux-gnueabi/sysroot and related tools in /opt/local/bin, prefixed with arm-linux-gnueabi-, i.e.

$ arm-linux-gnueabi-as --version
GNU assembler (MacPorts 2011/12/02) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-gnueabi'.

$ arm-linux-gnueabi-gcc --version
arm-linux-gnueabi-gcc (MacPorts 2011/12/02) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO

$ arm-linux-gnueabi-ocamlopt -config
version: 3.12.1
standard_library_default: /opt/local/arm-linux-gnueabi/sysroot/usr/lib/ocaml
standard_library: /opt/local/arm-linux-gnueabi/sysroot/usr/lib/ocaml
standard_runtime: /opt/local/arm-linux-gnueabi/bin/ocamlrun
ccomp_type: cc
bytecomp_c_compiler: arm-linux-gnueabi-gcc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -fPIC
bytecomp_c_libraries: -lm  -ldl -ltermcap -lpthread
native_c_compiler: arm-linux-gnueabi-gcc -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT
native_c_libraries: -lm  -ldl
native_pack_linker: arm-linux-gnueabi-ld -r  -o 
ranlib: arm-linux-gnueabi-ranlib
cc_profile: -pg
architecture: arm
model: default
system: linux
asm: arm-linux-gnueabi-as
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so
os_type: Unix
default_executable_name: a.out
systhread_supported: true

To help with cross compilation of OCaml projects using ocamlfind, the arm-linux-gnueabi-ocaml-compiler port also installs a custom ocamlfind configuration file /opt/local/etc/arm-linux-gnueabi-ocamlfind.conf, which you can use to utilize the cross compiler toolchain by setting the environment variable OCAMLFIND_CONF to point to this file.

Published: 2011-12-04 — Comments

Red-Black Trees for OCaml

I decided that it was about time to get used to OASIS, that new all-in-one build system generator for OCaml projects. So I started by getting it up and running using various local MacPorts. Once everything was up and running, I started to switch my implementation of Red-Black Trees for OCaml to use OASIS instead of my custom Makefile-based approach. That went amazingly well, and so here's my first release, version 0.1.0, of ocaml-rbtrees featuring an OASIS-generated build system.


Git repository:

For those of you using MacPorts on Mac OS X, ocaml-rbtrees 0.1.0 is also available from my local MacPorts Portfile repository as caml-rbtrees.

Published: 2011-10-16 — Comments