8 cores, 8 times as slow

We all know that most workloads don't scale linearly as you add more cores. But you know you've really screwed something up when your times go UP as you add more cores!

This is how I managed to achieve this:

In Albion's new renderer, I split the view up into tiles of say 256x256 pixels, and render the tiles on separate threads - regular graphics stuff. When all is going perfectly, the threads don't need to communicate with each other at all, and you get pretty much linear speedup. But one of the times when threads do need to communicate is when they're using shared resources - and fonts are one of those.

It's simplest for me just to have one font cache for the entire process, but obviously you need to synchronize access to this cache. When I originally created this font cache, I wasn't really thinking of synchronization, and when it came time to make it multithreaded, I just added a huge lock around every entry point, and thought I'll make those finer when I need to. Yesterday I definitely needed to.

In the particular scene I was looking at, I was zoomed in close, so the spatial culling was basically making all tiles render the same objects. As it turns out, I had 8 threads doing something approaching 8 times as much work, but unable to run in parallel. I don't think it gets worse than that!

This was really easy to find - you just hit pause on the debugger while it's running, and you see all your threads stalled at the same wait point.

WPF rendering on Vista is ugly and blurry

UPDATE: I discovered the problem. It was the NVidia drivers for my 8600 GT. Previous drivers were 78.13 (7813). New drivers are 82.50 (8250). Running Vista x64 with .NET 3.5 SP1

On my Vista machine, WPF rendering is nasty. I don't know what the engine is doing. My DPI setting is default (96 DPI). Aero is turned on.


On Vista, witness the nastiness:




On XP, the kind of quality we've come to expect:





I can't puzzle it out. Incredibly odd that I can't find any mention of this on the WWW.

VC 2008 needs /Ox

Some of my database test functions picked up that a field read had gone from about 500 clocks to 1700 clocks, when upgrading from VS 2005 to VS 2008. I don't have time to investigate exactly what causes this, but changing the optimization setting from /O2 to /Ox fixes it (and actually makes 2008's code a bit faster than 2005 if I'm not mistaken).

Bottom line: Use /Ox for all release builds. The executable also seems to be smaller. Maybe it's the omission of the frame pointers.. I don't know.

Shameless plug

This is a shameless plug for the GF's artwork. I slapped the website together. Apparently if I say the words Gina Heyer it works better. viva la vida.

A nickel for every for loop

I was reading this short essay by Mike Vanier. At the end he says "if I had a nickel for every time I've written "for (i = 0; i != N; i++)" in C I'd be a millionaire". Hmm.. it looks like some people make a lot more off their for loops. The word 'for' appears 13527 times in the Quake3 source. At one nickel for every for loop, that would earn JC a cool $676.35. woot! He can finally afford that Voodoo 6.

Bug in x64 optimizer in VS 2005, unfixed in VS 2008

I came across a bug in the x64 optimizer yesterday. By the looks of this connect.microsoft.com item, it looks like it's been there since VS 2005, and it has not been fixed in VS 2008.

I don't understand the bug completely, but it seems to involve sign extension (using movsxd) when it should do unsigned extension of 32-bit integers to 64-bit.

In my specific usage case, I was splitting up the 32-bit integers into their upper and lower halves, by adding an offset of 0x80000000 for the upper half. My workaround was simply to use 0x80000000 - 1 instead of 0x80000000 as an offset. The optimizer ends up generating different code, which happens to be correct.

If you have any sway with MSFT, please get them to fix this bug. I don't know if the voting system on that connect.microsoft.com site works, but maybe it's worth a try.

Lighttpd patch for trunk:2001

For what it's worth- a lighttpd 1.5.0 update. This is built on /trunk:2001.

Source Patch (use on /trunk revision 2001):
lighttpd_win32_patch_2001.patch

Binary:
lighttpd_win32_2001.exe