Building a Computing Highway for Web Applications

I live online. I store all my email, documents and pictures in the cloud. Except for work, the only application I regularly use on my computer is a web browser. It gives me access to everything I need. Nearly everything: Although those days when web browsers were only designed for light weight tasks are gone, some compute intensive applications, like photo editing, still force me to leave my browser environment and use a native application instead. 

If applications were like road traffic, then web browsers used to be the country roads: Capable of handling some traffic at slow speeds but too underdeveloped to take a heavy load. This no longer is the case. Browser vendors have invested into their browser’s execution engines, increasing the speed limit on their country roads significantly. Still, native applications have a performance advantage.

This advantage is no longer just due to slower execution speeds. If you look at modern processors, they all come with some form of vector extensions that allow the processor to execute multiple operations at the same time. Keeping with the road analogy, native applications run on multi lane highways. Intel’s 2nd generation Core series just introduced AVX, which doubled the number of lanes compared to previous processor generations. Another performance boost available to native applications is the use of multiple roads: Most modern systems feature a multi-core processor.

Web applications so far have lost out in both regards. JavaScript, the language behind the web, does not give applications access to multiple cores, let alone vector instructions. Thus forcing me to use native applications where performance matters although I would prefer staying in the browser. Clearly, it is time for JavaScript to catch up.

This is where Parallel Extensions for JavaScript, code named River Trail, an Intel Labs project I am working on that is currently shown at IDF, comes into the game. River Trail brings the processing power of Intel’s multi-core CPUs and their vector extensions to web applications. With River Trail it will finally be possible to stay in the browser even for more compute intensive applications like photo editing.

What really excites me about the technology behind River Trail is its seamless integration with existing web technologies. River Trail extends JavaScript with a simple, yet powerful data-parallel programming model. Much effort was spent to make this extension feel as natural as possible. Our goal was to make writing web applications with River Trail as easy as writing regular JavaScript. Furthermore, as River Trail is embedded into JavaScript, it combines well with other upcoming HTML5 APIs. We in particular made sure that River Trail plays nicely with WebGL, a recently introduced JavaScript API to OpenGL used for 3D visualization in the browser: One of our demo applications is a physics simulation with more than 4000 bodies, where the computation is done using River Trail and visualization is performed with WebGL.

Bringing new technologies to the web immediately raises the question of their impact on the user’s safety. This is true for River Trail, as well. The web browser, by its nature, is on the front line of attack. JavaScript code, whether extended by River Trail or not, is loaded from remote systems that are outside of the user’s control and is executed on the local machine. Protecting the user from abuse and ensuring the security of River Trail therefore were major concerns in the design. River Trail was designed to inherit the security traits of JavaScript and I am confident to say that our extensions to JavaScript do not add any further attack surface to the browser.

Will River Trail be the end to native applications? Probably not. Will it lead to improved web applications and new kinds of usages for the web browser? Hopefully so! River Trail is available todayas an add-on to the Firefox web browser. You are invited to join us and refine it, make use of it, change the web. We have built a computing high-way for the web browser. Let’s make use of it.

19 Responses to Building a Computing Highway for Web Applications

  1. Stephan Herhut says:

    We have released the full source code into the open source. It is available on GitHub (github.com/rivertrail) and we welcome everyone to join the development and bring River Trail to other browsers.

  2. Dan says:

    @Paul Wujek: you are missing the point. The idea behind nodejs is precisely not to have parallelism and its consequences. Why do you think it is called ‘node’?

  3. Stephan Herhut says:

    Although we never tried it, in principle it should work on Linux. There is a free Intel OpenCL SDK for Linux available at http://www.intel.com/go/opencl. What is missing though is a Makefile to compile the binary part of the extension on Linux. The Mac OS Makefile would be a good starting point.
    Regarding Firefox 7: We have not tried yet. We are waiting for the next version of the Gecko SDK to come out. So far, every new major version of Firefox has required some minor changes to the extension to make it work. If you try, please let us know about your findings.

  4. Stephan Herhut says:

    I believe there is enough difference to justify adding a new parallel construct. A key difference is the level of abstraction: Web Workers are a threading primitive that allows the programmer to explicitly spawn a number of threads. River Trail does not have the concept of threads. Instead, it allows the programmer to encode potential concurrency and the underlying runtime chooses how to exploit it for performance. In fact, the runtime might not use any thread level parallelism but only exploit instruction level vectorisation. The latter is not possible with web workers. Even picking the right number of workers for a particular client configuration cannot be expressed as JavaScript does not expose the required information, like the number of cores, machine load, etc., to the programmer.
    Furthermore, the programming model is different. Web workers follow a distributed programming pattern where threads communicate via asynchronous messages. In particular, there is no shared state between different workers. The data-parallel programming model that River Trail advocates is based on a shared memory view where in principle all data is available within a parallel kernel, although access is restricted to reading. For data-parallel workloads, this restricted sharing enables a very efficent implementation.

  5. OrNot says:

    I can’t agree with Stephan anymore! At least for now, the web worker is not able to clone big chunk of data very smoothly in its distributed programming pattern. The overhead to communicate via asynchronous messages is unacceptable under some circumstance. The River Trail is better than web worker here. The problem is when it will become part of w3c. Only supported in one or two specific browsers doesn’t make much sense.

  6. Mr C says:

    Will this only work with Intel processors? Or will other processors/mobile processors not be able to take advantage of the vector extensions part?

  7. Stephan Herhut says:

    I agree with OrNot. We have made the River Trail prototype available to start a conversation. It is released under a BSD style license, so everyone is welcome to experiment with it. If you believe that River Trail should become a standard, make yourself heard. The web is an open space and standardization is an open process. I certainly would be interested to help any effort in that direction.

  8. Stephan Herhut says:

    Our current implementation relies on Intel’s OpenCL SDK as a hardware abstraction layer. The list of supported hardware can be found at http://software.intel.com/en-us/articles/opencl-release-notes/ . However, nothing in the design of our proposed language extensions nor in the prototype implementation prevents others to use a different abstraction layer. Whether such layer would support the use of vector instructions is another question.

  9. MySchizoBuddy says:

    Is this limited to WebGL only or can it be used for general computations. right now it is CPU only and GPU targeting is up to AMD and Nvidia to implement. correct? Can you install Firefox and river trail on HPC server.

  10. Stephan Herhut says:

    Although River Trail works well with WebGL, its use is not limited to it. In a nutshell, our prototype supports parallel execution of codes that could be implemented using typed arrays in standard sequential JavaScript. We only support execution on the CPU and we have developed River Trail as a client side technology. It should be possible to install Firefox and River Trail on a server machine. However, integrating River Trail into a stand alone JavaScript engine might be a better match for such usage scenarios.