4 posts • joined 2 Dec 2012
Re: So far the model code is reaching the limits of what can be done...
Yup, Java's definitely holding us back right now on this version (I'm the Terrence Stewart quoted in the article). We've been focused so much on the research aspect (how can you connect up realistic neurons to perform the tasks we think different parts of the brain are supposed to do) that we haven't spent much time on the pure computer science question of "how fast can we make it go". I tossed together a quick Theano version of the core inner loop (Python compiled to C optimized for matrix operations) a few weekends ago and got a 100x speedup on a simplified model without much problem. And we've got some work on a CUDA implementation, and a student working on an FPGA version. Oh, and we've been in close contact with Steve Furber at Manchester, so we can make use of his SpiNNaker project (a giant supercomputer made of one million custom ARM processors). So I think there's tons of easy to do things to speed this up, now that we've demonstrated that it can work.
The Java JIT definitely helps a lot in our model, since the vast majority of the processing time is a simple core inner loop.
The nice thing is, though, that the core inner loop is something that's pretty straightforward to do a custom re-write in whatever language we feel like, so we can do that sort of special-case optimization to run on particular hardware if we want to. But, we still like having our main software in Java, for two reasons.
First, it's incredibly easy for anyone to download and use. We run tutorials at various conferences on it (and there's online tutorials at http://nengo.ca ), and there's a big advantage to having it just work on everyone's machine. The second reason is that it's a research tool where we tend to want to try out new algorithms and different neuron models, and for that sort of work it's more important to have a clear API than for it to run quickly.
But, now that we know it works, we can turn to speeding it up, and there's tons of good ways to do so. There's lots of other projects out there focusing on how to simulate neurons really quickly. What we're doing that's new is showing what the connections should be between neurons in order to do different tasks. So we can take that and apply it to lots of other people's hardware (for example, we've been working with Steve Furber's group, getting our models to run on their SpiNNaker hardware http://www.theregister.co.uk/2011/07/07/arm_project_spinnaker_super/ )
Re: As had been said... WTF Java?
I definitely agree (I'm one of the main developers on the project). But there's already tons of people working on how to do high-speed simulations of neurons, and we'll just make use of whatever they come up with. What we're doing that's new is saying how to connect neurons to do particular tasks. That's a much less well-studied problem, especially with questions like "how do you selectively route information between brain areas"? We're using Java for our default simulator just to let us focus on the problem of figuring out what the connections between the neurons should be, as it lets us flexibly try different things.
Re: Java or not...
Hi, this is Terrence Stewart, one of the researchers on the project.
The parallelism point is exactly why we've been working with a group at Manchester building a system to deal with exactly this problem: http://www.theregister.co.uk/2011/07/07/arm_project_spinnaker_super/
Once we use our software to determine the connectivity between neurons that is needed to perform a particular task, we can download that connectivity into SpiNNaker (or any other high-speed neural simulator) and run it there. That's a big part of why we haven't worried about simulation speed all that much so far.
One way to think of what we're doing is that we have a neural compiler. You specify the algorithm, and it figures out the optimal way to organize neurons to compute that function. The compiler (and tutorials) is all available here: http://nengo.ca