Overview
Parallel JavaScript gently extends the JavaScript language so the web programmer can access the ever increasing parallelism found in modern hardware including multi-core, vector, and GPUs. The API consists of about 10 methods of which six define parallel methods. While the surface area of the API is small and easy to articulate and understand it is safe, secure, and very powerful, both in terms of what can be expressed using the API but also in terms of the optimizations that are enabled. For a discussion of various problems we are trying to solve you can view an interview where I talk about River Trail.
What I hope to do here is describe a bit of the history of the project, how it became what it is today and its current status. I’ll start with a quote from probably the most important essays on software engineering ever written.
_“The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.” _ ― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
The River Trail prototype is that pilot. Like most research projects it started out as a one person for one quarter project, so the API size was naturally limited since the resources were anything but mythical. We added a couple of very capable recent graduates after that quarter to rework the prototype so others could use it. The prototype was placed on GitHub in 2011 and has been an effective vehicle for understanding both the implementation and the API. We have kept the prototype stable so that applications could be developed and to allow us to understand our users and what they want. Our papers discussing the prototype have been presented at peer review conferences such HotPar, SigGraph, and Splash. 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 implementation of Parallel JavaScript for Firefox. They have written several [interesting blogs] (http://smallcultfollowing.com/babysteps/blog/2012/10/10/rivertrail/), [and] (http://smallcultfollowing.com/babysteps/blog/2013/05/29/integrating-binary-data-and-pjs/ ) about the effort and we talk with them regularly. 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 others were encountering. These included the need for multi-dimensional arrays, arrays of structures addressed by binary data, multiple valued returns (addressed by assignment destructuring), and better syntax for anonymous functions addressed by fat array syntax, and much more. We found common ground and adjusted the API to adopt upcoming ES6 semantics and syntax. This was not without some pain in meeting overly optimistic road maps since cooperation, achieving consensus, and building on ES6 features means takes a lot of time. The alternative of going off on our own would have made for better monthly progress reports but ultimately would have left the programmer with a poorly integrated and non-orthogonal API.
The result of all of this listening is the recently revised proposal. It is this proposal that we hope to have implemented in the various JavaScript engines and standardized in ES7 in the future.
- Richard L. Hudson July 12, 2013