The Philosopy of Performace and Scaling

For those of you who have worked with me (or currently do), it may be better to read through my non-technical blogs (business, CEO type stuff), mainly because there is nothing new here than what you may already know through our technical conversations.

We will get a lot into the meaning of the terms - Performance and Scaling. This blog is the start. When I have time on hand I'll try to compile some of this and hopefully much more into a book. I believe there are two ways to write a book: keep taking detailed notes as you do development of some hard-assed problem in computer science, or, teach a class in systems design and programming. The latter suits me better as I'm too selfish with my time when I'm writing code. Coding is very beautiful and to get distracted is to give an ounce less to the thing on hand (which is what all these blogs are all about :)).

I'm excited to see The Art of Multiprocessor Programming by Maurice Herlihy and Nir Shavit. I'll share my thoughts when I have read this book. But flipping quickly through it I see much out there where we can value add in terms of getting those great algorithms a run for the money on some of the coolest h/w coming out in industry.

What a shame seeing some good computer science talent coming out of school wanting to manage people or do business development. Embarrassing as that statement may seem given my life as a programmer today (Not!), I ask you - the brilliant CS student - what do you go to school for if you don't want to step out and give what you've learnt a road-test? If the CS degree was just a stepping stone for landing a well-paying job in a completely different domain then you are doing the right thing getting into business; rest assured, the world of building "beautiful" will not miss you. The economics of being a programmer v/s a manager or biz person are similar to that of a masonry brick layer v/s the contractor; sure, there is a scalar multiplier involved in terms of actuals $$s involved :). But some of my most successful engineer friends have done pretty damn well financially, compared to their management counterparts, and contributed immensely to academia and industry. I'm excited to say that the $$s business has never come in a significant way (haha) of my love for programming.

To conclude, performance and scaling is not a job IMHO. It is a way of life. Marrying s/w to the underlying h/w to get the most out of performance and scaling is a natural by-product of well written code. It does not require a "performance engineer," to run through your dirty laundry after you have written code, to "speed" things up. We will focus on becoming well-rounded engineers who do not have a surrogate relationship with processors, compilers, Instruction Set Architectures, machine architecture, etc. As we go higher through the s/w stack and away from silicon we will use the same building blocks that we used when close to bare metal. The problem is not very different when building a distributed system or a loosely coupled cluster than when designing for a symmetric shared-memory MP system with snoopy or directory based caches. Neither is it different when writing a compiler for a processor pipeline. The key is to distill the mathematical basis - once you have that down you are in a powerful position to build any vector. I may go years before I've discovered something fundamental that can become a part of my synchronization toolchest, thereby adding to my basis.

Concurrency and synchronization are an intrinsic part of any large real-life system. It is good to train ourselves on home turf, take baby steps, and set ourselves for bigger challenges over time.