Took the bike out in the company of 3 cars of which the largest was a Miata. We organized a Thursday afternoon ride with:

• Tom and Louise in their Caterham 7
• Andy Glaister in his Lotus Elise
• John Miles in his Miata
• Me, on my Suzuki VX-800 (Minus the windscreen for this trip.)

Jeff was supposed to join us in his Crazymobile, but had a family emergency, so bowed out of this ride. Hopefully we can get another ride in before the rains begin, since his car has less protection against water, wind, etc. than my bike.

The plan was to motor east on Novelty Hill Road, and hug the west side of the Snoqualmie Valley up to High Bridge Road which is a wonderfully bendy bit of two lane climbing out of the northwest corner of the valley, and from there, work our way more or less straight back to Kirkland.

We started off with a straight bit of highway driving, I405 S to SR520, which was relatively empty, allowing a bit of lane jockeying and Unseemly Displays of Acceleration. Taking Redmond Way east, we turned north at 204th Place NE (an inspired detour suggested by Andy), which was the best curvy section of the day, IMO. I'm actually somewhat embarrassed that I didn't know about this road, since it's less than a mile from my house. Heading through the boring bit of Novelty Hill, we hit the curves on the end, and turned north on NE Snoqualmie Valley Road.

This is where things came off the rails a bit. About a mile up the road, we found that the DOT had shutdown our route for maintainance. Bummer. This actually turned out to be fortuitous, since we decided to take a slightly longer route than we had originally planned. Off to Duvall! Cutting over to 203, we headed north to the start of Cherry Valley Road, a newly paved loop behind Duvall. Sadly, we got stuck behind a slow-moving Dodge Caravan for most of the fun bits. At the reconnection with 203, we stopped to grab a drink and found out from the woman working the counter that the section of High Bridge that we were originally aiming for was actually open once you were past the closure. We cut over the north end of the valley at Crescent Lake Rd, passing an odd farm with Department of Corrections signs all over it. Very strange, but since it was unoccupied (apparently), I couldn't quite make out what the deal was. Honor farm? Work release?

Connecting with High Bridge, we headed north up and out of the valley. More fun curves here, although again we got stuck behind a slow-moving vehicle. (Amy, stop reading here.) Probably for the best, since I blew an S-curve, and nearly entered the opposing lane of traffic. I was able to use the rear brake to get the bike under control before crossing the line, but I probably made Andy step on the brakes a little harder than he was planning. Need to practice those compound curve entries and exits...

From there, it was more or less just cruising back to Kirkland, via 522 and 202. There was a gratifying bit when we were stopped briefly on 522 at a light with nothing in front of us for at least a mile. This provided another great opportunity for an Unseemly Display of Acceleration. I was in the lead, and Andy was polite enough not to blow by me in the Lotus, which was a bit disappointing, since I wanted to see what the Elise could do from the line.

• Google Earth KML
• Load the track in Google maps

Sadly, the GPS cut out for one major leg, the long straight line across the valley starts at the location we were turned around by the road closure.

/rides | permalink (2006/09/29 16:23)

So that's not a particularly controversial statement, but it really took on new meaning this afternoon. While plowing through Granny in the Xbox 360 profiler, I noticed something rather improbable. A function that did essentially no computation, just a loop and a few conditional dispatches, was taking in excess of 10% of the time in one of our critical sampling paths. Odd. Mispredicted branches are bad, but that bad? So, after setting up a decent test case and stuffing it through the profiler, one number jumped out. In 100 calls to the function, it was missing the L2 data cache 22000 times.

22 f***ing thousand cache misses!!!

It's really hard to overstate just how bad that is. Granny is by it's nature somewhat non-local in it's memory accesses, but that's simply ridiculous. 200+ cache misses per call? A handy rule of thumb for the time taken by L2$ misses on the X360 is "5000 misses ~= 1 millisecond". That's pretty close on the PS3 as well, assuming that the SPUs aren't banging on the memory bus at the same time. So the function was wasting around 4.5 milliseconds per frame just waiting around for memory to be delivered.

The good news is that the problem was really easy to fix. Thrown in a few prefetches, and the cache misses dropped to essentially zero. (~600 per 100 calls, which is totally acceptable.) Throw a few more around, and the application which was missing L2$ 44k times per frame now drops to 12k. That's a savings of 32k L2$ misses ~= 6 milliseconds. Per frame! 12k cache lines is roughly 1.5 megs on the 360, which is close to the working set size of this particular stress test. Much better. Five lines of prefetches sped up the test app by 20%.

The whole episode points to part of the fun (and the pain) of developing for multiple platforms at the present moment in the gaming technology curve. If you don't keep a close eye on the strengths and weaknesses of each platform, you are absolutely doomed. Those cache misses never showed up as a problem on the x86 platform where I do most Granny development, since the out-of-order core hid most of the memory latency. The current generation of Intel and AMD chips also have ninja predictive prefetch hardware, which Microsoft chose not to include in the PPC-based Xenon cores. The PS3 does have a basic predictive prefetcher, but it's not nearly as intelligent as a modern out-of-order core.

Now I just have to figure out how to do something sensible with the SPUs on the PS3...

/tech/work | permalink (2006/09/14 23:43)

By request, I've enabled the Bloxsom RSS feed doohickey. It's always slightly startling to be reminded that on occasion people actually read this stuff. Makes me want to go back and erase a bunch of entries...

For instance, I wrote a snark about iPods a year and change ago. I still believe all of those words are true, but I no longer care. I have an iPod, I love working on the Intel iMac at the office, and if I wasn't fairly sure that it would melt a hole in my lap, I'd be raiding Wyatt's college fund to buy a Macbook. I've been replaced by a pod person. Give me shiny white plastic!

I should just delete the post. I don't think current me should be held responsible for the words of past me.

/misc | permalink (2006/05/03 14:26)

My god, the compiler tools included with Visual Studio 2005 are a flaming bag of poo. How is it possible that a business built on programming can deliver such crappy tools? And the bit that's really getting under my skin right now is technology that was old and boring in 1970: command-line compilers and linkers. Witness:

Exhibit A. Manifests. Holy mother of god, what retard designed and implemented this "feature"? Here's the synopsis: each executable must have an XML resource associated with it that specifies (in part) which libraries it was linked against. So you can't distribute your application without dealing with this crud. The first sign that this is not going to be a pleasant experience is that the resource must have an ID of 1, unless you're compiling a DLL, in which case it must have an ID of 2. Good work, guys. The .manifest file is spit out by the linker, which makes some sense, but the linker doesn't contain a switch to simply stuff the damn thing into the linked file! The simple way to deal with this is to call the new manifest tool with commandlines that look like:

mt.exe -manifest some.exe.manifest -outputresource:some.exe;#1

Yeah, that's hot! ";#1"? Who the hell makes commandlines that look like that? The second way to handle this is to wait for the linker to spit out the .exe.manifest file, create a custom .res file that contains just that manifest as a resource, compile it with the resource compiler, and then link the whole thing again! Awesome!

Look, I get it. DLL hell is no fun. The install program from Gramma's recipe database trys to install the C runtime DLL from 1982 into system32. What I don't understand is why I'm being punished because Microsoft managed to screw up their access controls in the 90s. Guys: if you want to do this, add a linker switch that just does the f'ing right thing! It's not hard. The steps for a normal application are entirely deterministic. You can maintain the above lovely pieces of tech for people that are doing "innovative" things with your environment. By the way, this page is the most informative bit of documentation that I could find on this topic at MSDN. I don't know whether to laugh or cry. NMAKE is not a real build program, just document the damn switches, OK?

Exhibit B. Smarmy deprecation warnings for the C standard library functions. Attention: just because you have problems writing more than 10 lines of code without creating a remote-root buffer overflow exploit doesn't mean that I do. Why do I have to define _CRT_SECURE_NO_DEPRECATE to turn these things off? Shouldn't I have to define _HOLD_MY_HAND_PLS_THX to turn them on? You don't get to deprecate the standard library!

Exhibit C. No inline assembly for x64 targets? I know that we're supposed to pretend that the CPU doesn't exist now and code to the CLR, but hey, that doesn't work. Let me access RDTSC, please. They even removed the _emit keyword, so you can't work around the problem without building a full .asm file for MASM, and incurring function call overhead. Lovely.

Exhibit D. When I start the IDE for VC, the start page goes and loads a feed for important developer news. Good to know that time is spent on the things that matter.

Update: I just gave up on the DLL crt, and linked statically. That's probably the way to go, anyways; who the heck can predict what they're download to a users machine from WindowsUpdate.

/tech | permalink (2006/03/20 16:28)

I'm just going to pretend that I haven't ignored onepartcode for a year. Hey, no one reads it anyways, right? Brief synopsis:

• Moved to Redmond
• Working at Zipper
• Not working at Zipper anymore
• Working at RAD Game Tools

After moving to RAD, I got inspired to customize my dev environment more than I have in the past. My Xemacs sings, which is cool: now I feel like a proper geek. I finally caved, and picked up Elisp, which I've been meaning to do for quite some time. Whee.

| permalink (2006/03/08 01:12)