I work in the research labs and I am working on a project called “RiverTrail” and we are trying to get data parallelism into JavaScript, so that more people can take advantage of our parallel hardware.
I think it starts with the chips at Intel, but if you can’t reach those chips, if you can’t program those chips and take advantage of those chips [then that needs to be addressed.] We’ve done a lot of great work that people are not taking advantage of. We think that the web application programmer, the JavaScript programmer if you will, is underserved. We have great hardware and they are having trouble getting access to it, so RiverTrail is trying to address that. So how do you create a programming model and a programming system that this class of programmers can use and take advantage of? That’s why Intel is interested in it [JavaScript].
I think you’ve hit on the serious pain of programming, which is that we’ve got a generation of programmers who have been programming in sequential ways. They look at something and they think about a FOR loop, and think about stepping through a list. In a parallel world, you really want to think in a different way, you want to think in a parallel world where you have all of these values and you want to change them in parallel, create new values in parallel, and you have to break out of that sequential thought model, if you will. And it’s not only the programmers, we’ve got generations and generations of chips, that were designed around making C - a naturally sequential language and Fortran - run faster, so we also have to think about those types of things. So those are the pain points, it’s just moving from this sort of sequential world into this parallel world.
4. How is JavaScript different in that regard from other languages?
JavaScript was invented in the mid-nineties, and all of the chips of that time and all of the programs were sequential and single threaded and JavaScript was expected to be that as well. So we will have the single threaded programming model, and it was very clever, it worked really well. JavaScript has to evolve like any programming language or anything to be successful has to evolve, and as the hardware has evolved, JavaScript needs to evolve, so it is currently very sequential in nature, and we are trying to adapt it to add some parallelism to it.
5. How did the functional constructs in JavaScript lend themselves to parallel programming?
When I think functional, I think that you a call function, you pass it some arguments, it calculates something possibly using some local variables and some local state, but what it doesn’t do is it doesn’t mutate other state, that is not passed into it or local. Now the problem with parallelism, as we sort of learn with these other languages like Java and C, is if you start mutating shared state, start writing to things that other parallel entities or other threads if you will can see, you get these nasty things called “Race Conditions” and you have to deal with these horrible things called “Locks”. That is not something that the typical JavaScript programmer really wants to have anything to do with.
And that’s fair; these types of approaches have not been wildly successful. Our constructs say: “We are going to say no to that”, we are going to say: “We are going to maintain the same determinism you see in single threaded programming, and we are going to make it parallel”. That has some definite implications when it comes to the value of functional programming. So if you are a functional programmer, you don’t mutate already, we are not going to let you mutate, so you are going naturally became a very good functional programmer when you start working in RiverTrail, because that is the way we do things.
6. What are the differences between RiverTrail and WebGL?
There are a lot of syntactic and technical differences but philosophically there are two approaches here, and I think that is the key-point here. RiverTrail is based upon this principle and this design consideration that the JavaScript programmer wants to program in JavaScript. That he has this body of knowledge that he’s developed over a lot of work, he’s learned JavaScript, he knows it intimately, he wants to add parallelism to it and we say: “Great, we want to leverage every bit of knowledge that you have in JavaScript and we want to gently extend in JavaScript just a little bit to give you this parallel stuff.” You already have ninety percent of the stuff you need and now you can use RiverTrail and you never have to leave JavaScript because all RiverTrail is written in JavaScript and all the code you write is written in JavaScript.” That is one philosophy, one programming model and you stay in it.
WebGL has this other programming model idea that says: “Ok, we’ve got this body of code that is written in this language called GLEs, which is how they write WebGL kernels or graphics things, it’s very efficient, very close to the hardware, you can get complete control of it and that is great, and if you are a GLEs programmer and you want to move all this great GLEs programs, you can then learn a little bit of JavaScript and do it. This doesn’t really help the JavaScript programmer, he has to go and learn a whole new programming model and he ends up with this bifurcated programming model. It’s just a different philosophy, they get more performance, they claim to and they also bring in all of this experience from the GLEs folks. Our philosophy is give him JavaScript, let him stay in JavaScript and then the systems programmer, the compiler writers, we work really hard to give them the performance that they need. So two different philosophies both seem to be very successful, one may dominate in the future, one may not, we’ll see.
We took RiverTrail and we created a document that explains what RiverTrail is, an API if you will. We took it to the EcmaScript body. Ecma is the body that is in charge of standardizing EcmaScript which is just another name for JavaScript, and we took it to TC39 which is the Technical Committee in charge of that. They liked it – it now has something known as “Straw man” Status which is the first step towards getting it eventually accepted. Once you are in Straw man Status the issues are open for discussion and we are having open discussions right now on RiverTrail about how to make it so that everybody is sort of happy with the way it works, to get the best minds in this language field to give us a hand to make sure that we get this right and that we serve the needs of the programmer at the end, and we don’t have any gotchas in there that are going to trip people up to years to come. Ecma is a very open group, they are very nice people and they are very intelligent people and they are really helping us to get that out, and are very receptive to RiverTrail at this point.
HTML5 is fantastic, they’ve basically taken the web to the next level and they said: “Look, you can now have access to all these great new APIs”, and that left an opening for RiverTrail. You have access to this stuff, you need really great computation to take advantage of it. Intel RiverTrail says: “Ok, this is great stuff, we can make it beautiful, we can make it sing because we will give you the computational power that you need to make it work”, and that’s what RiverTrail is. So RiverTrail probably couldn’t have happened without HTML5, because we do all this great work, but without HTML5 we would not be able to show it to anybody.
Without Canvas you can’t really see the results of a 3D simulation. So that’s where is sort of fits and it works in any browser whether it is mobile or [not]. The nice thing about RiverTrail is it says: “What parallel hardware is available? Oh, look I’ve got a nice GPU!” or “Look I’ve got a nice vector instruction” or “Look I’ve got twenty seven cores on my cell phone!” or whatever is going to be in the future. RiverTrail says: “We’ll take advantage of all of it”, because the code that the programmer wrote in RiverTrail is not hardware specific. We’ve completely abstracted all that away and because JavaScript is JIT’ed, we can make all those decisions at the very last moment to take advantage of whatever parallel hardware happens to be right there for us.
9. What is a roadmap look like for River Trail?
It’s very positive, actually we mentioned earlier that we are on the Ecma Committee and Ecma seems to be one of the key steps towards getting this stuff into other browsers, and all that Committee of all the browser vendors, so they all aware of it, and they are encouraging the Ecma Committee going. As we’re moving into the browsers we are working closely with Mozilla to trying see what it would take to get it into the Mozilla Firefox stuff, but there is another roadmap. There are really two roadmaps in these things and a lot of time think there is only one, you have the chip roadmap, but the other roadmap is the application roadmap. We are not going to get this into a browser unless we have compelling applications, if it’s not in the browser we are not going to get compelling applications.
So it’s really more like two tight rope wires instead of two roadmaps. So we also have this other project where we are trying to come to places like QCon to meet programmers and get them excited about RiverTrail and trying to get them to say: “Oh, this is great, look I’ve got this great application that can really take advantage of it and I can make my app that much better if I put a physics engine” or “I can make my app that much better if I do some fancy graphics behind the scene or some image translations behind the scene, and River Trail will really help me out there. I couldn’t do that yesterday because JavaScript couldn’t do parallel stuff.” So those are the two roadmaps and we will see where they lead us, they are just maps, you don’t take journeys by looking at maps, you take journeys by going down a road and find it what you find.
10. How can people start using RiverTrail and providing feedback?
It’s all in GitHub, every demo that you’ve seen, is all the code for, every bit it’s between our toes is available in GitHub, if you go to https://github.com/RiverTrail/RiverTrail/wiki, you can get all the codes, you can look at, you can change it, you give us feedback. We are very interested as working with the application developers or hope to, that will be able to give feedback about what’s good about the API and what’s bad about the API. But all the code’s out there; it’s totally open source, we are trying to be as free in open about this, because we feel that is the way of the web if you want to say, that’s the way that the web works, is this cooperation and we are trying to fit into that as best we can.