making apps, making webs.

Recently I was testing that pygame still works with the python2.5 beta. When I was doing this, I had a chance to play around with python2.5 and all it's new goodness. Amongst the other good python2.5 features is that python is performing better. Almost twice as fast a startup 'cold'. This is because it uses half the number of syscalls as python2.4 does. 755 syscalls in 2.4 and 461 in 2.5. Still not quite as good as perl with 40ish syscalls, but a massive improvement none the less. $ time python2.4 -c "print 'hello'" hello real 0m0.923s user 0m0.041s sys 0m0.025s $ time python2.5 -c "print 'hello'" hello real 0m0.417s user 0m0.043s sys 0m0.021s However compared to perl, python is still syscall heavy. Perl does around 50ish syscalls to start up. Python2.5 also frees up more memory that it isn't using. Python2.4 does not release all that much memory if you use up quite a lot. It holds onto it in it's memory poo...

If you have a non 64bit Debian machine (like a duron, p3 etc) installing libc6-i686 will speed it up. # note that doing this you may need to restart running programs otherwise they might crash. # rebooting might be an idea, if you do not know how to restart all your programs. apt-get install libc6-i686 After I had it installed I got a 7% faster pystone result. I also got a couple of fps quicker in some pygames. This was with an AMD duron 850mhz system, your milage may vary.

It makes sense I guess. The people who make firefox should be able to make a faster binary than a distro. The mozilla firefox build is i686 rather than i386, and probably uses some other methods for extra speed that debian doesn't. Debian stuff is usually made for stability and compatibility first, rather than for speed. However, so far on my machine the mozilla build has been running for a day or so. So it works nicely at least on my machine. It's made my browsing noticably faster on this duron 850mhz machine that I use daily. So I'm quite happy about it. The windows refresh faster, and the javascript heavy sites do their thing quicker. My pretendpaper site loads a whole 1.5 seconds faster using this build. It's probably the most slow, and intense javascript based site I know of. The load time is noticably slower on a slow cpu machine.

Pygame has moved to subversion. Thanks to our wonderful hosting friends at seul.org for setting it up for us. The sdl ctypes has been moving forward. This is a project sponsored by the google summer of code. A couple of SDL example programs are running, and the code is looking good. There is a manual, and a couple of tests. sdl ctypes is being developed in the pygame subversion. http://www.pygame.org/ctypes/ For pygame I have gone through most of the documentation comments on the website. Only 20 remain left to sort through. shreadwheat also added some more documentation enhancements. A request for the scaling functions to be able to accept a destination surface has been made. I've mostly completed this change. It allows for faster scaling when you are repeating the scale operation multiple times onto the same surface. This is because you don't need to allocate memory so often. However the destination surface has to be the correct size, and format. If it isn't ...

Will the arrival of google earth mean that hardware accelerated opengl be more widely spread on linux? It's a free fun toy that requires opengl. Hopefully it will do more for linux opengl than quake3, and xgl have done. I hope so anyway.

The last pygame release was August 16th 2005. So there are a lot of bug fixes and a few features in development that need to get out there into a release. With the new SDL being released last week it seems like a good time to get a new pygame out. Here is the release plan from the last release. We will follow it in the same way again for this new release. At the moment we are in the apply patches, fix bugs, get in any last minute features phase. This weekend I made pygame.image.save be able to save as .png and .jpg files. Since pygame already optionally links against libpng and libjpg to load .jpg, and .png it shouldn't be too much hassle for people, and only a tiny bit of extra code. So if pygame is linked against libpng, and libjpg it should be able to write .jpg and .png images. Saving as jpg/png is an often requested feature for people doing screen shots, caches, and level editors amongst other uses. Hopefully these save functions will eventually make it into SDL. That...

For pygame which uses SDL some parts are written in assembler. These parts detect which cpu they are running on and then use those mmx/sse/3dnow optimized assembly routines if those processor features are available. However much of pygame and SDL is still in C, not ASM. So compiling using processor specific features does give a very nice speed up for the C parts. For some parts a 33% speedup or more can be gained. Just by changing compilation flags. I think this is the best and easiest approach to getting parts of CPython to be sped up. Below are my notes, and thoughts about the topic. Mostly this is based around my experimentation with pygame compilation. This does not take into consideration python compilation itself, or any of its modules. However a similar methodology could be applied to speed up pythons modules too. Note that recompiling python itself to match your processor can give a large speedup too. So, I have started experimenting changing distutils to compile modul...