Me: I thought it was about time for me to learn how filtering works.

Coworker: Everybody has to walk through that convolution and correlation forest at some point and come out the other side as a man.

I’m kind of proud of this little feature for its simplicity, and it shows a lot of the power of MATLAB. In fewer than 200 lines of well-structured code, I was able to implement a robust file reader. Here are a few features it uses that anyone creating their own file reader in MATLAB might also try to take advantage of:

assert — Stop writing if blocks that only exist to check whether everything is okay and error if it isn’t.

fid = fopen(filename, 'rb');
assert(fid > 0, 'Could not open file.');

And . . .

assert(isfield(meta, 'sizes') && ...
       isfield(meta, 'dimension') && ...
       isfield(meta, 'encoding') && ...
       isfield(meta, 'endian'), ...
       'Missing required metadata fields.')

onCleanup — Why worry about trying to remember to clean up resources? Let the onCleanup class take care of it for you. Construct one of these objects by giving it an anonymous function that closes your file handle when the object goes out of scope—whether from an error or at the end of the function.

cleaner = onCleanup(@() fclose(fid));

regexp — Use MATLAB’s regular expression engine to handle complicated text parsing for you.

theLine = fgetl(fid);

% "fieldname:= value" or "fieldname: value" or "fieldname:value"
parsedLine = regexp(theLine, ':=?\s*', 'split', 'once');

Dynamic structure field indexing — If you have a string that’s a legal MATLAB identifier, there’s no need to write complicated logic just to use it as a field name in a structure. Simply use the .(string) construct.

field = lower(parsedLine{1});
value = parsedLine{2};

field(isspace(field)) = '';  % Remove embedded spaces.
meta(1).(field) = value;

Using temporary files to decompress data — The NRRD format supports storing the image data as raw bytes, human readable text, or GZIP-compressed byte streams. When a file contains compressed or encapsulated data and MATLAB has a file reader capable of handling that, it’s easiest just to write the data to a temporary file and use the supported reader. Consider the readData() subfunction that recursively handles three different kinds of encoding:

function data = readData(fidIn, meta, datatype)

switch (meta.encoding)
 case {'raw'}

  data = fread(fidIn, inf, [datatype '=>' datatype]);

 case {'gzip', 'gz'}

  tmpBase = tempname();
  tmpFile = [tmpBase '.gz'];
  fidTmp = fopen(tmpFile, 'wb');
  assert(fidTmp > 3, 'Could not open temporary file for GZIP decompression')

  tmp = fread(fidIn, inf, 'uint8=>uint8');
  fwrite(fidTmp, tmp, 'uint8');
  fclose(fidTmp);

  gunzip(tmpFile)

  fidTmp = fopen(tmpBase, 'rb');
  cleaner = onCleanup(@() fclose(fidTmp));

  meta.encoding = 'raw';
  data = readData(fidTmp, meta, datatype);

 case {'txt', 'text', 'ascii'}

  data = fscanf(fidIn, '%f');
  data = cast(data, datatype);

 otherwise
  assert(false, 'Unsupported encoding')
end

swapbytes — Like many formats, NRRD supports little-endian and big-endian byte ordering. The swapbytes function makes it dead simple to change endianness, and the computer function helps you determine whether swapping is necessary. Here’s the pattern, which uses the “endian” metadata value read from the .nrrd file:

function data = adjustEndian(data, meta)

[~,~,endian] = computer();

needToSwap = (isequal(endian, 'B') && ...
               isequal(lower(meta.endian), 'little')) || ...
             (isequal(endian, 'L') && ...
               isequal(lower(meta.endian), 'big'));

if (needToSwap)
    data = swapbytes(data);
end

Happy coding!

Techie people, the good stuff—code, results, more info—is below the fold.

Friends, I’ve been in my head a bit recently. That’s not necessarily bad—it’s a nice neighborhood, really—but one of the dark alleys I’ve had to walk past a lot lately involves way too many imposter-type feelings. As I previously mentioned, we’re hiring, and we’re looking for someone to do many of the same job tasks that I do. Being mostly self-taught at software engineering and computer science, I have to remind myself that I have more than a dozen years of experience; whereas, for most of the people whose résumés cross my desk, they do not.

It’s sometimes hard to silence those voices that say “everyone else is more accomplished than you.” Even though it’s not true, I’ve been meaning to pick up some more skills so that I can (a) try to feel like less of an imposter and (b) write more awesome code to make our product more awesome and help us fend off our competitors and make more loot.

So yesterday afternoon, rather than coming up with (yet another) daunting list of all of the places where I feel like I should learn more, I just picked one that I already knew about: Streaming SIMD Extensions, a.k.a. SSE. For me, the best way to learn is to write a program that does something (theoretically) useful, run into real-life obstacles, and workaround the pitfalls I encountered. Practice, practice, practice.

My dear readers who don’t program, you can now safely navigate away for another day without guilt. The rest of the post is rather technical and describes how I took an example I found online, made it work with gcc, and got a 4x speedup by using SSE. A speedup and happier outlook. Not bad for a few hours on a Saturday!

The first real examples I found online were this post from The Supercomputing Blog and this one from LiraNuna. Together they got me started.

The program computes sqrt(x)/x many times and compares the results and performance. On my 2006-era CoreDuo MacBook Pro, I got these results, when evaluating this equation over the range 0 to 64,000 and computing all of the values 10,000 times:

Without SSE: 26.404 seconds
With SSE, using division: 6.705 seconds (3.9x faster)
With SSE, using reciprocals: 4.204 seconds (6.3x faster)

The example code below uses the following functions and datatypes that were new to me:

_aligned_malloc
posix_memalign

__m128

_mm_add_ps
_mm_div_ps
_mm_mul_ps
_mm_rcp_ps
_mm_set_ps
_mm_set1_ps
_mm_sqrt_ps

I compiled, ran, and timed the code using these commands:

g++ -O2 -msse sqrtxdivx.cpp -o sqrtdivx_ssediv
g++ -O2 -msse sqrtxdivx.cpp -o sqrtdivx_sserecip
g++ -O2 -msse sqrtxdivx.cpp -o sqrtdivx_ssenone
time ./sqrtdivx_ssediv ; time ./sqrtdivx_sserecip ; time ./sqrtdivx_ssenone

For more info on SSE:

• Art of Assembly Language book — See chapter 11.
• Intel Architecture Software Developer’s Manual (PDF) — See chapter 9.
• Wikipedia’s SSE page

Without more delay, the code!

#include <stdio.h>      // printf()
#include <xmmintrin.h>  // SSE compiler intrinsics
#include <stdlib.h>     // posix_memalign()
#include <math.h>       // Non-SSE sqrt()

//#define USE_SSE  // Define this if you want to run with SSE.
//#define USE_DIV   // Define this if you want to use SSE division (slower, accurate).


// We will be calculating Y = sqrt(x) / x, for x = 1 to 64000

int main(int argc, char* argv[])
{
  // Compute sqrt(x)/x for the first 64,000 nonnegative integers.
  const int length = 64000;
  
  // float *pResult = (float*) _aligned_malloc(length * sizeof(float), 16);  /* MSVC */
  float *pResult;
  posix_memalign(reinterpret_cast<void **>(&pResult), 16, length * sizeof(float));  /* gcc */

  printf("Starting calculation...\n");

  for (int stress = 0; stress < 10000; ++stress)
  {
    #ifdef USE_SSE
      __m128 *pResultSSE = reinterpret_cast<__m128*>(pResult);  // Intermediate pointer

      __m128 x = _mm_set_ps(4.0f, 3.0f, 2.0f, 1.0f);  // Initialize x to <1,2,3,4>.
      __m128 xDelta = _mm_set1_ps(4.0f);  // Set the xDelta to <4,4,4,4>.

      const int sseLength = length / 4;
      for (int i = 0; i < sseLength; ++i)
      {
        __m128 xSqrt = _mm_sqrt_ps(x);

        #ifdef USE_DIV
          // Use slower, more accurate SSE division.
          pResultSSE[i] = _mm_div_ps(xSqrt, x);
        #endif
        #ifndef USE_DIV
          // Use faster, less accurate reciprocal and multiply.
          __m128 xRecip = _mm_rcp_ps(x);
          pResultSSE[i] = _mm_mul_ps(xRecip, xSqrt);
        #endif

        x = _mm_add_ps(x, xDelta);  // Advance x to the next set of numbers.
      }
    #else  // USE_SSE
      float xFloat = 1.0f;
      for (int i = 0 ; i < length; ++i)
      {
        pResult[i] = sqrt(xFloat) / xFloat;
        xFloat += 1.0f;
      }        
    #endif // USE_SSE
  }

  // To prove that the program actually worked, look at the first 20.
  for (int i = 0; i < 20; ++i)
  {
    printf("Result[%d] = %f\n", i, pResult[i]);
  }
}

The raw output. Notice how the first (SSE with division) and the third (no SSE instructions) gave the same answer, while the second set of results (using SSE and a reciprocal calculation) gave decidedly less accurate computations.

Starting calculation...
Result[0] = 1.000000
Result[1] = 0.707107
Result[2] = 0.577350
Result[3] = 0.500000
Result[4] = 0.447214
Result[5] = 0.408248
Result[6] = 0.377964
Result[7] = 0.353553
Result[8] = 0.333333
Result[9] = 0.316228
Result[10] = 0.301511
Result[11] = 0.288675
Result[12] = 0.277350
Result[13] = 0.267261
Result[14] = 0.258199
Result[15] = 0.250000
Result[16] = 0.242536
Result[17] = 0.235702
Result[18] = 0.229416
Result[19] = 0.223607

real	0m6.705s
user	0m6.678s
sys	0m0.008s

Starting calculation...
Result[0] = 0.999756
Result[1] = 0.706934
Result[2] = 0.577209
Result[3] = 0.499878
Result[4] = 0.447104
Result[5] = 0.408149
Result[6] = 0.377872
Result[7] = 0.353467
Result[8] = 0.333252
Result[9] = 0.316151
Result[10] = 0.301470
Result[11] = 0.288605
Result[12] = 0.277282
Result[13] = 0.267196
Result[14] = 0.258136
Result[15] = 0.249939
Result[16] = 0.242469
Result[17] = 0.235645
Result[18] = 0.229365
Result[19] = 0.223552

real	0m4.204s
user	0m4.196s
sys	0m0.007s

Starting calculation...
Result[0] = 1.000000
Result[1] = 0.707107
Result[2] = 0.577350
Result[3] = 0.500000
Result[4] = 0.447214
Result[5] = 0.408248
Result[6] = 0.377964
Result[7] = 0.353553
Result[8] = 0.333333
Result[9] = 0.316228
Result[10] = 0.301511
Result[11] = 0.288675
Result[12] = 0.277350
Result[13] = 0.267261
Result[14] = 0.258199
Result[15] = 0.250000
Result[16] = 0.242536
Result[17] = 0.235702
Result[18] = 0.229416
Result[19] = 0.223607

real	0m26.404s
user	0m26.360s
sys	0m0.033s

Update — 6 February 2012: On Sunday I wanted to see what would happen when I changed the code to work on 64-bit, double-precision floating-point numbers. While I saw the expected 4x speedup when operating on four 32-bit floats at once, I did not see the same 2x improvement with doubles. The SSE and no-SSE versions each took approximately 26 seconds. Why?

It’s either the processor or an OS issue. When I applied the same changes to the code at work, I saw not only a 2x speed up for doubles, I also got an almost 8x speed up for single-precision. That was surprising. When I looked at the differences between the Linux assembly of the “float” and “double” programs, the only things different were the obvious: minor array size and offset differences and the presence of the “_pd” versions of the routines instead of the “_ps” ones. This was similar to the differences I remember seeing when I compared assemblies built on my MacBook Pro.

The major differences between the two environments:

• 32-bit MacOS 10.6 versus 64-bit Debian 6 Linux (running under VMware)
• gcc 4.2.something versus gcc 4.4.5
• An older Intel CoreDuo processor (ca. 2006) versus an 8-core 3.07 GHz Intel Xeon (late 2009)

Clearly streaming SIMD instructions make a difference for some types, but the effect is limited (or helped) by the processor that executes those instructions. (Of course, I still have to check that GCC or the OS aren’t part of the difference.

A half-decade after Herb Sutter wrote that the “free lunch” of Moore’s Law is over, he’s back with his prophet’s wisdom about where we’re going in his January Dr. Dobbs article, “Welcome to the Jungle”. I’ll give you a moment to decide whether to get the Guns N’ Roses song out of your head or use it as a backdrop for this juicy quotation:

If hardware designers merely use Moore’s Law to deliver more big fat cores, on-device hardware parallelism will stay in double digits for the next decade, which is very roughly when Moore’s Law is due to sputter, give or take about a half decade. If hardware follows Niagara’s and MIC’s lead to go back to simpler cores, we’ll see a one-time jump and then stay in triple digits. If we all learn to leverage GPUs, we already have 1,500-way parallelism in modern graphics cards (I’ll say “cores” for convenience, though that word means something a little different on GPUs) and likely reach five digits in the decade timeframe.

But all of that is eclipsed by the scalability of the cloud, whose growth line is already steeper than Moore’s Law because we’re better at quickly deploying and using cost-effective networked machines than we’ve been at quickly jam-packing and harnessing cost-effective transistors. It’s hard to get data on the current largest cloud deployments because many projects are private, but the largest documented public cloud apps (which don’t use GPUs) are already harnessing over 30,000 cores for a single computation. I wouldn’t be surprised if some projects are exceeding 100,000 cores today. And that’s general-purpose cores; if you add GPU-capable nodes to the mix, add two more zeroes.

The big takeaway for software engineers like me is that we’d best be learning how to develop solutions using the emerging APIs so that we can harness all of those extra orders of magnitude of scalability. That involves figuring out how to . . .

• Deal with the processor axis’ lower section [of Sutter's chart] by supporting compute cores with different performance (big/fast, slow/small).
• Deal with the processor axis’ upper section by supporting language subsets, to allow for cores with different capabilities including that not all fully support mainstream language features.
• Deal with the memory axis for computation, by providing distributed algorithms that can scale not just locally but also across a compute cloud.
• Deal with the memory axis for data, by providing distributed data containers, which can be spread across many nodes.
• Enable a unified programming model that can handle the entire [memory/locality/processor] chart with the same source code.

Perhaps our most difficult mental adjustment, however, will be to learn to think of the cloud as part of the mainstream machine — to view all these local and non-local cores as being equally part of the target machine that executes our application, where the network is just another bus that connects us to more cores. That is, in a few years we will write code for mainstream machines assuming that they have million-way parallelism, of which only thousand-way parallelism is guaranteed to always be available (when out of WiFi range). . . .

If you haven’t done so already, now is the time to take a hard look at the design of your applications, determine what existing features — or better still, what potential and currently unimaginable demanding new features — are CPU-sensitive now or are likely to become so soon, and identify how those places could benefit from local and distributed parallelism. Now is also the time for you and your team to grok the requirements, pitfalls, styles, and idioms of hetero-parallel (e.g., GPGPU) and cloud programming (e.g., Amazon Web Services, Microsoft Azure, Google App Engine).

p.s. — I can’t believe that it’s been almost four years since I took a course with Herb out in Washington. That was some hard-core learnin’.

(From How to Think about Parallel Programming: Not!)

• When optimizing code for GPU, FPGA, or CPU, definitely focus on pipelining and overall throughput, not just local optimizations.
• There’s a trade-off between “faster” and “sooner.” It’s not always worth saving a few seconds (or even a few minutes) if the kernels take hours or days to compile. (Then again, sometimes it is.)
• Try to reduce dependence on the language/compiler “stack” that removes inefficiencies. The optimizer does good work, but you can do things to help it. Think about the hardware or architecture format. It’s not a sin to reduce the amount of abstraction in the service of performance. Pay attention to things that affect processor pipelining and cache movement.
• BTW, some languages and technologies exist to provide higher level programming that’s close to the hardware, but they’re proprietary, secret, or still in R&D.
• Use algorithmic optimization techniques. Step back and find the shortest-time computation.
• Avoid using if statements. The goto construct is considered harmful, but if is basically the same thing. Instead think about state machines and polymorphism. There’s no branch-prediction penalty to pay, since the system “just is” in the state it’s supposed to be in. The logic is clearer, because there are no switches, making it easier to test, too.
• Don’t always assume that floating-point values are necessary. Integers can often be creatively used and are far faster for math than double-precision numbers.
• Of course, there’s a compromise between speedy/efficient and readable/maintainable.
• Aim to structure programs as “symbolic intent.” Mathematical descriptions are bad ways of expressing programs. Think about functional programming models instead of procedural.

If you want to know more, you should definitely watch the half-hour interview. And if your reaction was more along the lines of “Yes, yes; that’s all true, and it’s how I design my image processing code,” then I definitely hope you’ll consider applying for the GPU/multicore engineering position we have open.

This is another one of those posts. Every year between Christmas and New Years Day, I try to use the quiet week to get stuff done and tie up loose ends. Last year, I cleared out a bunch of notes. This year, I’m looking at presentations and slides from the QCon SF 2011 conference (wrap-up). Its focus on software architecture and project management is about 75% of my job, so many of the presentations seemed tailor-made for me. Here’s some of what I learned.

Erik Doernenburg. “Software Quality: You Know It When You See It” has a really good slide deck that got me thinking about some projects I might want to set up. It’s full of practical, usable suggestions:

• View the code at the 1,000 view, rather than ground-level or 30,000 feet.
• Look at the test-to-code ratio, not just code coverage.
• Graph the change of metrics between versions and revisions, compare across different parts of the code, and look at them relative to industry standards.
• Measure the “toxicity” of code by rolling up various quality metrics about a bunch of modules into stacked bar charts.

We should pose these questions during design and code reviews:

• Is the software/change of value to its users?
• How appropriate is the design?
• How easy is the code/design to understand and extend?
• How maintainable is the software?

It was full of some really great links to things like Metrics tree maps (a.k.a., pretty heatmaps for source code) as well as a few tools: SourceMonitor, iPlasma, and using Moose to visualize quality.

Joshua Kerievsky. “Refactoring to Patterns” — some notes:

• Refactoring is like algebra’s equivalence-preserving manipulations. “Design patterns are the word problems of the programming world; refactoring is its algebra.”
• Understanding the refactoring thought process is more important than remembering individual techniques or tool support.
• Code smells have multiple refactoring options and often benefit from composite refactorings.
• Look for automatable refactorings first. Consider changing the client of smelly code before the smelly code itself.

Guilherme Silveira. “How To Stop Writing Next Year’s Unsustainable Piece Of Code” was pithy and thought-provoking.

• There is no value for architecture or design without implementation. That’s just interpretation of the software.
• “New language. New mindset. new idiomatic usage. Same mistakes.”
• Complexity and composition are natural and good, but if they’re invisible, they’re evil.
• Start with a mess and refactor right away. Starting “right” is hard (and misguided thinking). Refactor for better, not just prettier.
• Make complexity easier to understand and see.
• Hiding complexity in concision hurts testability, since no one knows the complexity is there. Furthermore, if it’s hard to test, it’s also hard to use correctly.
• “Model rules. Do not model models.”

Michael Feathers. “Software Naturalism: Embracing The Real Behind The Ideal” is a presentation that I would like to see/hear, since the slides seemed full of information but weren’t self-explanatory. Here are two things I could glean: 80% of software defects in large projects were in 20% of the files. In general, the more churn in a file, the more complex it tends to be.

Panel: “Objects on Trial” was perhaps the most unusual presentation, since it was a mock-trial. I use objects all the time . . . some of them are good . . . some demonstrably so. Even so, I never latched onto the idea of object-oriented (OO) design versus objects as types. The four panelists, in one way or another, basically said, “That’s the problem.”

One of the panelists drew an extended analogy between the space program and OO. The space shuttle (which we all love) was fixated on reuse but basically was a waste of heavy lifting; people don’t reuse the right stuff. In software, object reuse is largely accomplished by cut-and-paste copying of boilerplate code that does close to what you want. Of course, the panelist acknowledged that we do reuse the ideas in OO via design patterns, and no one seems to have much of a problem with that. Ironically, having a rich pattern language means that software engineers are in a better place than ever before to use objects correctly.

A key problem with our approach to objects is that we’ve failed (generally in software engineering) to handle complexity well, which was supposed to be the point of OO design. A conflation of beauty and OO design makes things worse. Internally, software is ugly, and beauty shouldn’t be a goal. Making a fetish of beauty makes code inflexible because people don’t want to extend the beautiful thing that works.

For other panelists, objects weren’t the problem at all. For them it’s static typing in “OO languages,” such as C++, Java, and C#. We’re at a place now where all of the good things about OO have been lost in an attempt to make OO languages as fast as C. This runs counter to the goal of having “ordinary,” understandable code. Generic programming using strongly typed (possibly template heavy) languages just makes everything complicated.

For me, it’s moot. C++ is what I use, and I don’t have a large proprietary object system that I can tap into for reuse. I’m in the camp that uses C++ objects to generate new types for data hiding and aggregation, as well as (to a lesser extent) reuse. But some of these types are generic, template classes that are hard to understand. I plead “no contest.”

My running plan includes plenty of tempo running and interval sessions. And I’ve finally gotten to the point where there’s “normal swimming” and “harder swimming.” But how do I know how hard to work when cycling?

I think the answer is heart rate training, which is new to me. Have any of you had success doing this?

I’ve figured out several of the basic calculations based on my computed maximum heart rate (183 bpm) and resting heart rate (52 bpm). According to an online calculator, these are my target heart rate zones:

Zone 1: 118-131
Zone 2: 131-144
Zone 3: 144-157 (Aerobic)
Zone 4: 157-170 (Anaerobic)
Zone 5: 170-183 (Maximal)

Now, where do I go from here?

You should know a few things about my decision to get this bike:

1. I have been saving money to buy a new bike at some point in the future ever since I bought my last bike in 2009.
2. I hadn’t expected to buy a tri-bike after just one season.
3. Lisa suggested, out of the blue, that I should get one. Merry Christmas from my sweetie (and my slush fund)!
4. I’m deeply, deeply ambivalent about this bike for so many reasons.

A couple of my coworkers and I joke that “triathlon is a rich white person’s sport.” And while I’ve seen people riding all sorts of bikes and wearing all manner of kit during various triathlons, the joke is uncomfortably close to the truth. Even though swimmers can wear just about anything (although a wetsuit will give you some advantage) and running is running is running regardless of your income level, anything involving a bike—including triathlon—is going to start to seem like thoroughbred horse racing. Cycling is where all of the money is spent, often for diminishing returns

“$2,000 for an aero wheelset to save a couple of minutes over 112 miles? $500 to save 30 grams by switching pedals? Yes, those are just what I need to get me to Kona.” Um, right. It would be like most of us thinking we can buy our way to a Boston Qualifying time by getting better shoes. I’m not saying the advantages aren’t real or that people shouldn’t be able to spend their money in whatever race-legal way they want. It just seems that common sense goes out the window whenever our reptilian brains see anything associated with two wheels.

So how did I end up standing around in my bike shorts and jersey this afternoon at Landry’s bike store waiting to get fit for a super-aero time trial/triathlon bike? Believe me, I’ve been asking myself that question and second-guessing myself and looking deep inside my athlete’s soul for the answer.

I guess it’s the simple fact that tri-bikes are faster than the bike I have now. Not just a little bit faster. No. A lot faster. A couple years ago I was just a guy with diabetes on a bike, but after this past year I consider myself an athlete. I feel I can be competitive in several of the races on next year’s docket, and I’d like to see how far I can go by giving my potential just a bit of help. [1]

This is the big, up-front investment. While it’s true that you never really “just buy a bike,” I don’t plan on putting much additional loot into this one right away. I hope I’m more down-to-earth than that. After all, it’s “not about the bike.” There’s a whole lot of hard work for me to do to feel like I’m living up to the potential of this bike, and that’s a big motivator.

Of course, maybe I’m just making a big deal out of nothing at all. Why don’t I just get on with telling you about the bike fit process.

When I bought my road bike (at a different store) the fitting was really simple: “Sit on the bike on a trainer while I get out my calipers and protractor and we will adjust the saddle.”

Today was nothing like that. Over the better part of an hour I was videotaped riding a highly reconfigurable “bike.” A specially trained bike shop guy reviewed the video frame by frame, measuring various angles, reconfiguring, retaping, remeasuring, repeating, . . . He used a laser level to aid in making extremely accurate measurements throughout the process.

Having recorded myself swimming, it was interesting to have this applied to another event. (Now I just need someone to film me running and to analyze my stride, in order to complete my mini-series triathlon.) Turns out I have very long arms and legs and a rather short torso—which I already knew, since most of my clothes must be tailored in order to fit right. I also have very flexible hip, knee and lower back joints, so I can get into a pretty aggressive aero position. That was unexpected.

Forty-five minutes after stripping down to my bike clothes (which I was wearing under my regular clothes [2]) I was ready to get bike recommendations. Or rather one recommendation. “Can we at least pretend like I comparison shopped?” I asked; so we played that charade quite convincingly. If I got that less expensive bike I would need to spend more money in accessories to get the same fit as the “right” bike. Or I could spend twice as much for the same fit with better components (like aero-er wheels and lighter pedals and shit like that.)

And then, the soft sell: “Do you want to take it for a ride?” Without a helmet? “We can lend you a helmet.” Outdoors in the cold? “Do you want a jacket or something? [Seriously, man, HTFU.]” I can manage without one for a few minutes.

It wasn’t the same pure joy that I had when I first pedaled my road bike. That feeling of effortlessness and the fluidity was replaced by wobbliness as I got used to the equivalent of driving a Porsche with a go-kart’s steering wheel. Because I was in a residential neighborhood, I didn’t really get the chance to open it up; nevertheless I could feel the responsiveness of this almost weightless bike.

I can hardly wait to give it a try.

1 — 2011 really was the year when I became an athlete. I competed in nine different races, and I used a couple of training plans to prepare for them. I was actually a bit haphazard in the events I chose, and I’m trying to be a little more focused next year. Of course, I’m also trying to keep a lot of the spontaneity and love for what I’m doing, which is precisely why I rebel against most triathlon training programs. “Life is choices.” [Back . . ]

2 —  I put my new office gym membership to use for the first time today over lunch so that I could change clothes. OMG, those were some chatty guys in the locker-room with me. I thought we were genetically programmed to become mute and blind in the presence of other naked men. (It’s a mutation on the Y chromosome. That’s a fact. Look it up.) This is going to take some getting used to. [Back . . ]