On 8/29/06, René Dudfield <[EMAIL PROTECTED]> wrote:
Now Apple are using x86, and x86 is getting more common in the embedded world too.
Where I work we've been using x86 "embedded" since the first Intel 386s (:
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.
It really doesn't. There have been attempts to remove/enhance python's bytecode loop (the innermost loop that goes over each bytecode) and the fact is it just doesn't change actual performance. The reason is that each bytecode performs huge amounts of processing which far dwarfs the amount of work done to fetch a bytecode, decode them and dispatch to their corresponding functionality. (Really a pointer increment and a jump through a switch table).
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 program 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.
Where are these numbers coming from? They seem completely arbitrary. Memory is cheap. Processing speed is cheap. Disk space is cheap. The return on investment for speed will be found mating extremely high level languages with intelligent simple parallelization libraries.
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.
The problem with processes isn't the amount of code. The problem is locking, concurrency semantics, heavyweight nature of threads, OS interactions, etc. An OS will allocate at a minimum hundreds of kilobytes for the thread.
