[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] pypy?
On 8/29/06, René Dudfield <renesd@xxxxxxxxx> 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.