Skip to content
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.
Richard L. Hudson edited this page Jul 19, 2013 · 96 revisions

Background

The goal of Intel Lab’s River Trail project, also known as Parallel JavaScript, is to enable data-parallelism in web applications. In a world where the web browser is the user’s window into computing, browser applications must leverage all available computing resources to provide the best possible user experience. Today web applications do not take full advantage of parallel client hardware due to the lack of appropriate programming models. River Trail puts the parallel compute power of client’s hardware into the hands of the web developer while staying within the safe and secure boundaries of the familiar JavaScript programming paradigm. River Trail gently extends JavaScript with simple deterministic data-parallel constructs that are translated at runtime into a low-level hardware abstraction layer. By leveraging multiple CPU cores and vector instructions, River Trail achieves significant speedup over sequential JavaScript.

Overview

There are several resources available if you want to understand Parallel JavaScript better. For a discussion of various problems we are trying to solve you can view this interview which discusses our approach and objectives. Several papers discussing the prototype have been presented at peer review conferences such as HotPar, SigGraph and the upcoming Splash (Oopsla) conference. We have also presented talks at top line JavaScript and Web developer venues such as Fluent, QCon, Strangeloop, and JSConf.

We’ve spent the last year working with our colleagues at Mozilla on a native Firefox implementation. Mozilla has written several interesting blogs [here] (http://smallcultfollowing.com/babysteps/blog/2012/10/10/rivertrail/), and [here] (http://smallcultfollowing.com/babysteps/blog/2013/05/29/integrating-binary-data-and-pjs/ ) about the effort. In addition to working with veteran programmers we worked with students at Harvey Mudd doing senior projects to understand the requirements and expectations of programmers just entering the field. Finally, and this is important, we listened closely to our skeptics and detractors. From them we learned what parts of the API are likely to work and what aren't. They were quick to point out the sharp corners and foot guns. It turned out that many of these sharp corners and foot guns were not specific to Parallel JavaScript but were much more general problems that other areas of JavaScript were encountering. These included the need for multi-dimensional arrays of structures, addressed by [binary data](http://wiki.ecmascript.org/doku.php?id=harmony:binary_data, multiple valued returns addressed by assignment destructuring, and better syntax for anonymous functions addressed by the fat arrow syntax, and much more. We found common ground and adjusted the API to adopt to upcoming ES6 semantics and syntax. This was not without some pain since cooperation, achieving consensus, and building on shifting ES6 features takes a lot of time. To spare the users of the prototype this pain the API of the GitHub prototype has remained stable and has not been changed.

The result of all of this listening is the recently revised proposal. It is this proposal that we hope to standardize and see in a future version of EcmaScript.

Getting Started with the Prototype

To get a feeling for the programming model and experiment with the API, take a look at our interactive River Trail shell. The shell runs in any current version of Firefox, Chrome and Safari. If you are using Firefox and have installed the River Trail extension (see below on how to), your code will be executed in parallel. If you are using other browsers or have not installed the extension for Firefox, the shell will use a sequential library implementation and you won't see any speedup.

You need to install our Firefox extension to use our prototype compiler that enables execution of River Trail on parallel hardware. You can download a prebuilt version for Firefox 21.x running on Windows and MacOS (older versions for older browsers can be found here). We no longer provide a prebuilt Linux version. However, you can easily build it yourself. We have written a README that explains the process. If you are running Firefox on Windows or Linux, you additionally need to install Intel's OpenCL SDK (Please note the SDK's hardware requirements.).

Note that Firefox has deprecated the Components object in content code. However, we make heavy use of the Components.interfaces hierarchy in the compiler implementation. To still use River Trail, you have to set the dom.omit_components_in_content key in about:config to false. Detailed instructions on changing configuration variables are available in Mozilla's knowledge base.

Once you have the extension installed, take a look at our demos:

Chris Whealy has created a demo that combines Mandelbrot and Julia sets into a fun fractal explorer. He also wrote an experience report about creating the demo.

For a first impression, you can watch this video, as well, or head over to InfoQ for an introductory talk recorded at TheStrangeLoop.

A smaller example that gives a look behind the scenes and serves as an easy comparison of our programming model with WebCL is our

To dive deeper, the API design or the beginnings of our API documentation are a good starting point.

A word of caution: River Trail is a prototype and the extension is not yet meant for use on the public web. Please uninstall or disable the extension when surfing the web and use it only for web pages you trust.

Beyond the Prototype

The API described in the wiki reflects what the prototype implements. Some design choices, like for instance the use of extra arguments, is dictated by limitations of what our implementation approach allows. We have created a draft API specification (ECMA strawman) for Parallel JavaScript that goes beyond the prototype's limitations and describes how we envision a final implementation. It is currently being considered for standardization by the ECMA TC39 committee. Feedback is highly appreciated and should be directed to the es-discuss mailing list.