Mechanical Sympathy…

This term has been coined by Jackie Stewart, a famous British race driver. He used it to describe his driving philosophy; he spent countless hours with the engineers and mechanics to get a deep understanding of where lied the limits of the mechanic, allowing him to get close to the edge and get the max out of it and when to let it rest a bit.

This strategy helped him win races when competitors were pushing their car too hard.

Gravity

The thought process is obviously complex, but it often relies on mental models. Those are abstractions the brain use to understand, analyze and interact with the physical world.

They are built through the brain’s learning process, refining them until they are proven accurate enough to act upon them.

For example, we all have a clear mental model of gravity: if we drop an object, it has an accelerated fall. So, this mental model helps us catch something that may have slip out of our hands. If we train hard, we get better at this, until we have a decent juggling ability.

About reality

Coming back to Jackie Stewart:

every driver (incl. you and me) has a mental model of a car, which helps him steer the car; but he can only spend so much time refining his model, i.e. driving and exploring possible situations. And he relies on a very basic model of the car engine, brakes and stickiness of the tires. That’s why he loses most of his skills if it rains or if there is a mechanical malfunction.

By spending a significant time with technicians, James was able to refine his mental models of the various car components. In the process, he could better anticipate the brakes/engine/steering behavior of his car….

Old technology

In my younger years, I was the proud owner of an Atari ST: I was constantly cracking games’ protections, learning how they were written and coding technical demos of some sort. Those demos required expertise and a deep understanding of the guts of the computer, which mostly meant understanding the MC68000 processor.

Its frequency was 8MHz and instructions took between 2 and 20 or more of those cycles, depending on how many memory accesses were required. Typical cycle count was around 6-8, leading to  (roughly) 1M instructions per second (3 orders of magnitude less than now). So if you wanted a 50 fps demo, your algorithm had to fit in 160,000 clock ticks=> ~20,000 instructions.

One time, I had devised a cute scrolling algorithm – remember, no GPU – but I failed short of reaching the expected smoothness: animation was 25 fps not the 50fps I was aiming for. Meaning I needed more than one screen refresh period to update the image…

Tenacity

Something was fishy there, and I had to understand what and why. Reality was not fitting the theory.

Toying with the parameters of the algorithm (reducing text size if my memory serves me we’ll), I was ultimately able to reach the holy grail of smoothness. But my algorithm was now significantly below the 160k cycles barrier, on the paper at least, so I should have reached 50 fps. 

Epiphany

Then it dawned on me and I immediately did write a quick micro benchmark to assess the hypothesis.

Bang!

Actual instructions’ cycle count was always a multiple of four, rounded up (of course). My theory was that the shifter used half of the memory access slots for display purposes (actually, this is a bit trickier than I though). Atari 520 ST Motherboard

I adjusted for that, which meant rewriting part of my algorithm and lowering my ambitions by reducing the amount of moved pixels. And now my scrolling was running smoothly at 50 fps.

Adaptability

My mental model had to be adjusted to match the reality of the hardware. It was an indispensable step to reach my objectives, which definitely performance oriented. But after this failure, I was able to predictably reach 50 fps when needed. I was basically a better demo coder than I was before.

Temporary

In this post, I tried to give you a brief introduction into mechanical sympathy and mental models. I also took the opportunity to brag about my past minor successes.

Doing this, I expected you to start pondering

• how good is my mental model of the hardware I am working on?
• are there any signs that I am wrong?
• can I find some?
• and foremost, does it matter?

In the next post, I will dig into the models of various parts of a PC and relates this to actual performance impact.