May 172011

Benchmark selection for architecture studies is always tricky. The ideal benchmark is the actual workload that will run on the computer being designed. However, workloads to run are often written after the computer has been designed which architects guessing for the right workloads.  Common benchmarks today include C/C++/Java/Fortran workloads (e.g.,  TPCC, Djemm, SPEC CPU) but very few architects investigate JavaScript workloads. I assert the studying Javascript is essential because Javascript is Common, Unique, and increasingly powerful. I will discuss these three properties of JavaScript and discuss how studying JavaScript can impact chip design.
Common: Javascript is the most widely executed language on client machines. Almost every website today uses JavaScript to provide it’s users with a clean, rich, and snappy interface

Unique: Javascript workloads are different from our traditional workloads. Clearly there are some obvious reason, e.g., it is a managed language, it is (usually) interpreted, it is garbage collected, etc. In addition, there is a less obvious argument: javascript code is all about portability thus it written programmers who have little knowledge about the target platform. This increases the likelihood of the program being inefficient, thereby leaving more room for hardware optimizations.

Increasingly general-purpose: Javascript is becoming more and more general-purpose. They have introduced multi-threading in the form for web threads which makes it a complete programming language. Here is an interesting demo of javascript used for scientific and graphics computations (


Is it performance critical?

An important question indeed. I wrote a toy website,, for this experiment. I wrote two versions of this site, one which was heavy on JavaScript and another which was heavy on I/O and required more communication with the server. As expect, the former version was significantly slower on m iPhone vs. my desktop, showing the processor performance can in fact impact the user experience on these interactive Web 2.0 websites. I also played a bit with . I measured the memory usage of the Google Chrome  processes running Gmail and it consumes roughly 50MB of memory (50MB = memory size of chrome window with gmail open – memory size of chrome window with no website open). A workload with a 50MB memory footprint is clearly a good candidate for cache-level and memory-level studies.


Javascript’s impact on architecture

Benchmarking JavaScript can change architecture because the workloads has some unique properties. While through analysis is required to nail down what changes will be needed, I will motivate with a two intuitive examples. First, JavaScript uses function objects very frequently. This implies that the low-level code will likely contain more indirect jumps than a C program. Thus, our future chips will be motivated to spend more resources on indirect jump prediction. Second, JavaScript has a threading model which is different than most traditional threading models. Threads run as asynchronous function calls on different cores. These thread are finer-grain which can imply that architects can no longer ignore the cold-start effects of caches and branch-predictors. Thus, studying JavaScript has the potential to impact architectures in a grave manner.

What workloads are there?

The details are beyond the scope here but try BrowsingBench from EEMBC or the Sun Spider JavaScript Benchmark. In fact, I would just benchmark google search or gmail. You can exploit the fact that JavaScript code of all sites is “publicly available,” thus, there is no need for asking the software industry for good workloads.


In all, I argue that we can no longer continue to ignore javascript as a toy benchmark. It is the single most important workload today for client platforms. Should we start expecting all papers and products to report their performance on Javascript before they can be accepted?

 Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>