Thursday 30 Jun 2011 comment? Before I regale you with pics from my travels, a few words of explanation. I chose a route that went through sections of Utah and Nevada I hadn't seen before. Parts of the drive were great, but the extraterrestrial highway was so-so. Unless you wanna stop at the alien-themed tourist trap (I didn't), or drive up to the boundary of area 51 (I didn't) to break the monotony for the camo dudes, it's nothing special.
Wednesday 29 Jun 2011 3 comments I'm in Lone Pine for a while. I have a routine of tasks to do upon arriving home: light the water heater, wind the clock, plug in the refrigerator, ... . Today's routine had an added twist: fetch a smoldering iron and splice the refrigerator cord after cutting out a rodent-gnawed section. (I discovered the damage by getting juiced while plugging it in. At such moments, one appreciates that most US outlets are only 120V.) ![]() Thursday 23 Jun 2011 comment? I thought 8 ribs was sharp looking, but it seems to have been just a passing phase. A nascent ninth rib is at 9 o'clock in the pic. ![]() Wednesday 22 Jun 2011 comment? Wikipedia: Selenium rectifiers had a shorter lifespan than desired. During catastrophic failure they produced significant quantities of malodorous and highly toxic fumes that let the repair technician know what the problem was.Reading that reminded me of a line in a story by Wolfgang Hildesheimer: "...the light-footed Finnish vase tips over at the slightest opportunity, as if that were its function."* What Hildesheimer spelled out ("as if that were its function"), the Wiki line implies: "During catastrophic failure" makes it sound like an intended phase of operation. The page's history shows the phrasing change bit by bit, from the very first revision (Selenium rectifiers had a short life/When they failed they generated a nasty stink that let the repair technician know what the problem was) to the state of refinement we see today. Lord knows, not every Wikipedia page is a model of good writing. But sometimes I find sentences there that I just love.
Tuesday 21 Jun 2011 comment? In 1999, I bought a copy of Micros--t Visual C++ so that I could deliver a program I was developing in Windows-usable form (at a client's request). In the course of my work I found a bug in Visual C++. There's nothing remarkable about that; a C++ compiler is a complicated piece of software and may exhibit the occasional bug. I was able to work around the bug, but I wanted to tell Micros--t about it. Reporting bugs is a service; it helps developers know where their products need improvement. Mozilla and Google value bug reports enough to have offered bounties (for reports on certain kinds of bugs in Firefox and Chrome, respectively). I submitted a Visual C++ bug report with the web page Micros--t provided for the purpose. It told me not to expect a response of any kind: I would get no followup email, no confirmation, no word on when the bug was fixed. I.e., even though you paid money for our software and are helping us out by reporting a bug, we will not show the courtesy of acknowledging your report. For compiling C and C++, Linux distributions offer gcc. I remember submitting gcc bug reports in the 1990s and being impressed by how it usually took less take than a week for someone to read my report, reproduce the problem, and respond. But I wondered how sustainable that was. It's one thing to field a trickle of bug reports (fewer people used Linux then) but it's quite another to keep that up once your user base grows. This is free support for free software. I found a bug in gcc yesterday and submitted a report. 11 hours and 33 minutes later, someone responded to confirm that it's a bug (in five different versions of gcc, no less). I don't know just what happens nowadays if you submit a Visual C++ bug report--but to be fair, I note that Micros--t seems to have moved on from the "expect no response whatsoever" days. Their page now says "Please note that we may use your Microsoft Connect Profile information to follow-up with you regarding this issue." I'd bet you a nickel, though, that they won't reproduce and acknowledge a bug in under 24 hours. I am impressed not only with gcc support but also with how well the compiler works. I'm keeping today's posting non-technical, but maybe some day I'll post some fun examples of gcc-generated code. Happy solstice, everyone. Sunday 19 Jun 2011 comment?
A taste of what's occupied me over the past few weeks: The LOCK XADD instruction provides a means for multiple
threads running concurrently on x86 cores to, for example, push requests
onto a single queue with what looks like a short, sweet piece of
code--but you will pay dearly for pipeline stalls, bus snooping,
and cache invalidation. Even if you were expecting it to take a while,
the length of the delay may give you pause.
And if you were hoping to do better by shopping around,
AMD's Magny-Cours architecture is in some ways worse in this regard than
Intel's Nehalem (which bums out those of us who like to root for the underdog).
We have a deadline looming at work, which has been leaving me without much time/energy for things like blogging. And when work is my focus, to blog about my life would (largely) be to write about technical stuff. I suppose it's possible to blog about cache coherence in a way that would entertain a wide range of readers, but that has felt like a tall order. A few days ago, I almost blogged to say that the music for the sequence from 24:40 through 25:50 in the film Cautiva is an (uncredited) adaptation of the last movement of Béla Bartók's fourth string quartet, but how many times can you blog about movie scores lifting material from Mr. B. Happy nineteenth, everyone. |
current journal
FAQ contact rss/xml atom/xml spam notice archive
|