Posts from: December '10

Random ramblings

Some miscellany, non-serious stuff around programming that recently occurred to me:

First, I got the impression that working as a law maker (or, more accurately, a law maintainer) is not much different than working as a programmer. Both the programmer and the lawmaker have to be very explicit and unambiguous; they are working on laws (directories), consisting of parts (files), filled with articles (classes), constituting of paragraphs (methods). Everything is in strict order. Changes to these laws come (at least in my country) through a state-issued paperwork (called the State Gazette in my case), which explains that law AAA, Part BBB, Article CCC, paragraph DDD, which formerly stated XXX, should now read YYY. Just a plain diff, that is.

So, in spirit of this comparison, here I demand: when will the Bulgarian lawmakers finally put up a Subversion access to all of the Laws, and stop applying patches through the State Gazette? This is so 20th-century...

Anyways, what else... I was pondering through some Linux kernel sources recently, more precisely within intel.c and amd.c... and got just truly convinced that there is nothing hardware-y in these processors anymore. They are full of bugs! So, did you actually think that your $150 you prepared for the shiny-new quadcore CPU pays for the silicium/hafnium in the crystal, or for the gold in the pins (for those of us who actually got pins; Intel owners are exempt from this)? Think again...

And I did some fun coding for valgrind, out of a necessity at work. I'm really glad when I can purposefully use work time to help open source projects like this. I love my job :p

Posted in category Programming -- 6 Dec 2010, 02:25, 0 comments

AGG 0.2.5

I've released yet another version of my gallery editor/generator AGG. It is mostly a bugfix and optimization release. The major bug that prompted this release is: when you process a huge gallery on a lot of threads (e.g., two 4-core Nehalem-based Xeons, resulting in 16 "cores"), the working memory gets awfully fragmented, and malloc()s start to fail (you get NULLs) - because it can't allocate the large contiguous regions needed to store the pixel data. In 0.2.5, the images are stored using lots of small chunks.
There are some optimizations as well: I'm using libjpeg-turbo for decoding/encoding JPEGs, and also did a rehaul of the resizing algorithms. Another major thing is the 64-bit support (there are 64-bit builds for Windows and Linux). See here for a more detailed change list.

Some performance figures: while the new libjpeg and the resizer optimizations are significant by themselves, the convoluted image storing reorganization (creating a mess in the memory due to data fragmentation) offset the performance win by some margin, so I did some real-life tests to assess how is the new version scores, compared to 0.2.4. So here is it: on a dualcore laptop, a 325-image 8 MPix gallery is produced in 2m 11s (as opposed to 2:28 for 0.2.4), which is a 12% win. On my other (six-core) machine, there is no performance difference between 0.2.4 and 0.2.5 (64-bit), but I think it's the disk throughput that is the bottleneck there ;)

Posted in category Open source -- 2 Dec 2010, 01:40, 0 comments