Friday 15 July 2011

Why Mechanical Sympathy?

A little while ago I discovered this wonderful quote by Henry Peteroski:

"The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry."

This observation has been a great source of employment for me over the last two decades.  In this series of blog posts I will try and share some of the techniques I've learned for getting the most out of our underlying hardware.  The name "Mechanical Sympathy" comes from the great racing driver Jackie Stewart, who was a 3 times world Formula 1 champion.  He believed the best drivers had enough understanding of how a machine worked so they could work in harmony with it.

Why does the software we use today not feel any faster than the DOS based applications we used 20 years ago???  It does not have to be this way.  As a software developer I want to try and produce software which does justice to the wonderful achievements of our hardware friends.


  1. I've now read all your posts, in reverse order. I've switched from C++ to Java about 10 years ago, because I could get more work done in my day. The Java Community says "you should forget about the low level, and concentrate on the design", which I like to believe most days. But since I get the job of doing profiling and optimizing, I can never really forget about performance.

    Reading all of this got me rather depressed. What it all means is that if it's got to run fast, you just can't get away with forgetting about the real hardware. And it also confirms my feeling that the Cloud and virtualization might be good for availability, but prevent you from getting the best performance, since you don't actually know on what hardware your code will run.

    I'd like to thank you for this very informative series of posts.

  2. Monster,

    You are right that it is such a shame folk in our industry show so little passion for the computer science of what is happened further down the stack. All part of our "instant gratification society" I believe.

    I am not so down about it all. For me the most important thing is taking the time to model the business problem correctly. If this is done then the majority of performance issues are avoided. Yet most developers seem to be more interested in creating megabytes of Spring config. I think my modelling post sums up my feelings well on this.


  3. Hello Martin, Hello Monster,

    I've now read all the posts, too, in reverse order. Great Blog! I am doing most programming work in C++ and avoided Java wherever I could - for different, not unusual reasons. But now I probably should revise my attitude towards Java ;-)

    Despite everything, reading all of this got me rather euphoric!

    Particularly the "Disruptor" is a very interesting development that has a good chance to replace many of the queue based designs.

    Until appearance of the Disruptor, the concurrent queue (in all its incarnations: using locking or lock-free, bounded or unbounded) seemed to be the undisputed utility for message passing between threads.

    And then this new utility appears: reasonable, clean, simple, flexible. This shows that our overall software development knowledge is still growing.

    The Disruptor proves, that there still is room for radical progress in our profession.

    Regards & Thanks,

  4. And yet another one that reads all the posts in reverse! I honestly hope that someday I will use at lest 1% of the knowledge I gain by simply reading your blog Martin! We even have a saying at work: "Well it's not Martin fast, but fast enough for them..." :)

  5. Dear Martin,

    Thank you for sharing the knowledge in such professional way.

    Initially by reading the articles helped me to understand the importance but it was such a moment when I saw in reality the benefits on a solution I was working on.

    Regards and thanks,