Monday, June 19, 2006

Debian libc6-i686 for faster python.

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.

Wednesday, June 14, 2006

Mozilla firefox binary faster than debian binary.

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 moves to subversion, and more 1.8 updates.

Pygame has moved to subversion. Thanks to our wonderful hosting friends at 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.

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 an exception is raised letting you know.

This brings up a point about a surface pool. That is rather than create new surfaces, ask to get one from the memory pool. If there are any left in the pool give one of those rather than creating another one. Once that surface is not referenced it will go back into the pool. This is a common pattern to increase speed where lots of allocations are made. For some programs using pygame that create lots of same format surfaces repeatedly this should be a good speedup. Especially for larger surfaces (50x50 or bigger).

I'm probably going to give pygame another month before feature freeze because of work commitments. So there should be plenty of time to add anything else to pygame if you want it in there.

Google earth for linux will bring opengl for linux?

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.