x86 the VM.

It's been really interesting to see VMs over the last couple of years.

Now there are emulators, and virtualisers which are capable of running x86 really quickly. The processors themselves don't run x86 natively anymore, it's a VM.

Now Apple are using x86, and x86 is getting more common in the embedded world too.

So now, rather than creating a VM like python does it seems to make sense to use the standard VM, and that is x86. Of course x86 is really complex, and still fairly slow to emulate on slow hardware. So using a simpler VM still has its advantages.

However writing directly to the most common VM has its advantages too. You can make software which is 400 bytes big which can do almost the same as a 8000 byte program. That's a 10x saving in program size. The same program will run in 12KiB of memory, instead of 1.7MiB of memory. That's a 141x memory usage saving. Because the code size, and memory size is so much smaller you can get a lot more done with the same amount of memory. You can run an entire OS and programs in less memory than a python process uses on debian linux. You can also use a lot more of these tiny processes. eg. for a single purpose webserver you can handle 40,000 connections using fork and separate processes in around 640MiB of ram with a duron 850. Or 100
connections using 1.6MiB, which is less than a single apache process.

I find it very interesting, and think that assumptions about processors and architectures that I learned 10 years ago are perhaps changing. The standard thinking is that fork is slow, and that you should use event driven async for high speed. Well it's not slow if your processes are only 800 bytes worth of code. Just enough code to do the exact task at hand.

Communication between processes has become really quick now. With system calls on linux like slice, tee, and vmsplice you can get two sockets transfering data directly without having to read data into user space. So you can take the output of a mpeg encoder and send it directly to a file on the HD not even copying the data, at the same time send it out on a socket through the network card. All without going into user space. How about compressing a stream of data, and sending it to a socket and also saving it in a file cache.

Processes and VMs can be transported between machines. Mosix can move processes amongst machines. With emulators you can store the whole state of the system in a file. You can store your x86 system image in a file, and move it to a different machine.

Then there's all this GPU general purpose computing stuff. You can run batch processes at 100x the speed of a cpu on these things. There's still a lot of science being done to find good ways to reimplement algorithms that work well, but lots has already been learnt. With the internet I think they have progressed much more quickly than in the 50s-70s. Chips like those found in the GP2X have multiple cpus, DSPs, and all their IO devices all on the same chip.

- tiny programs. http://asm.sourceforge.net/asmutils.html
- emulators and virtualisers http://fabrice.bellard.free.fr/qemu/
http://www.thefreecountry.com/emulators/pc.shtml
- mosix, distributing processes. http://www.mosix.org/
- general purpose computing use of GPUs http://www.gpgpu.org/
- tee, splice, and vmsplice in linux 2.6.17 http://kerneltrap.org/node/6505

There's lots to be excited about with the new ways people are approaching VMs and computing.

Comments

Popular posts from this blog

Draft 3 of, ^Let's write a unit test!^

Is PostgreSQL good enough?

post modern C tooling - draft 6