Push The Button, Max!

I'm preparing for the rollout of Minx 1.2, which has a whole bunch of improvements over 1.1...  Speed, on the whole, not being one of them.*  I never add anything without optimising it to within an inch of its life, but constantly adding features doesn't come without some cost.

Fortunately Minx is plenty fast for most cases.  It can even produce a full page of Ace of Spades with many hundreds of inline comments at a reasonable speed.  But I don't like to see those milliseconds slipping away from me.

I've implemented a microcaching system****, and tried it out on the comment sanitiser, which is probably the slowest deterministic function in the system.  The results were disappointing, providing only a 10-15% improvement overall.  I had thought that the comment sanitiser would have dominated the page generation time, but it turns out not to be the case: If I turn off santisation completely, it's not measurably faster than the cached version.

I need to do another round of profiling, I guess.

In the old days, this could have been resolved simply by swapping the servers for newer and faster ones.  Now, though, the fastest servers offered by Softlayer - in terms of single-threaded performance - are only 25% better than what we already have.  (And between 50% and 150% more expensive, which is why we have what we have.)  I can get 16 cores no problem, but I can't get 4GHz at any price.*****

Intel is coming out with a new CPU architecture this year, codenamed Nehalem.  While plenty is known about Nehalem's interconnect architecture (Intel is finally catching up to AMD), not much has been said about the CPU core itself, and even less about its performance.

A presentation recently leaked by Sun (oops) showed Nehalem servers delivering 2.8x the SPECint_rate2006 performance of a 3.0GHz Core2 server.  But SPECint_rate2006 is a multi-threaded benchmark, and the details showed that this compares an 8-core dual-threaded system against a 4-core single threaded one, so the single-threaded performance gains could be as little as, well, zero.  Rumours since then have put it at between 10% and 25% clock-for-clock.  Unless Nehalem also brings a significant clock boost, that's not a lot.

The throughput situation is a lot brighter, but throughput for medium-scale web apps is a solved problem anyway.  Multiple cores, multiple CPUs, multiple servers and lots and lots of RAM.

Curse you, laws of physics.

* Except for a few instances like recent comment listings, which were a hack in earlier versions and have been rewritten to use a new folder->post mapping table which provides O(n) performance instead of the previous O(n² log(n)).**

** Or... Not.  Okay, now it takes 2.5 minutes.  Back to the query analyser for you, buster!***

*** Ah, there we go.  70 milliseconds worst case.  Much better.  The whole point of the mapping table was to eliminate the need to sort large sets, so sorting on a field dependent on a join didn't really help.

****  Python provides a remarkably simple and fairly elegant way to do this, using "decorators".  Simply by adding the line @qikcache(10000) before a function definition (where qikcache is a caching function I've defined), I change the function to perform a lookup in an LRU cache before carrying out its normal calculations - and to automatically calculate and write the result to the cache if it's not there already.

***** Except from IBM, and the Power6 is a speed-demon design that doesn't deliver signficantly better performance on integer loads anyway.  In our case it would be worse, because the Psyco JIT compiler Minx uses only works on x86.

Posted by: Pixy Misa at 01:25 AM | Comments (6) | Add Comment | Trackbacks (Suck)
Post contains 606 words, total size 4 kb.