Sun 20 Jan 2008
Evolution in javascript
Posted by jon under Technical, code, javascript
No Comments
I have been playing with javascript a bit lately, testing out techniques that I might use for doing a full web 2.0 business application (if any clients would agree…). The application that I have written is a game along the same sort of lines as RoboCode.
It allows users to implement "animals" in custom written assembly code ("genomes"), which compete for resources and can move around and eat each other. I have currently written two simple genome, a vegetable (it doesn't move) and a predator (it does move). They are both using almost the simplest algorithms for each of these tasks as possible.
The animals run virtual cpu's and also implement virtual threading. The predator animal has a reproductive thread and a movement thread. The vegetable has only a reproductive thread. And as the last real feature, the animals also have a non-zero chance of their mem-copy commands (part of the requirement of reproduction) failing to copy correctly. This introduces mutations and hopefully mutation.
The javascript application is backed on the server by a ruby on rails application that stores successful animals (animals that survive to reproduce).
I have a few problems with the current implementation that limits it's usefulness.
- First, the application is pretty slow. It runs at about 600hz on my computer in firefox 3b2. (This means that it executes 500 virtual cpu instructions per second.) Compare this to my actual machine running at 2 billion instructions per second, and there is a factor of 4 million difference. Some of this can be explained by the fact that each virtual instruction is implemented as a block of javascript code that does stuff to memory in the cpu. Some more is probably explained by me not using javascript to its full potential. The rest must be explained by javascript being s l o w. I have used firebug to do some profiling of the code to find hotspots and have been able to find some issues. To make the evolution part of the application do anything useful it would need to be 10x faster at least. But I think that to make it a factor of 10 faster i would need to radically change the architecture.
- Another issue is that the application occasionally just freezes. I imagine it is doing some sort of garbage collection in the background. I would love to be able to get more control over this, so that I could see what was happening, or at least predict when it might happen.
These are the same issues that I would face implementing a large javascript client in a web 2.0 application, so I am glad to have found them now rather than later.
An early alpha version (where it isn't possible to inject new animals into the application, except by editing the source directly, and the server communication isn't working properly) is available. The source is all on the page in easily read code, if anyone is interested.
