The Core Software Strategy - 9 Years Old and Still True!

I wrote this post on my Intel® Software Blog back on September 20, 2006. Unfortunately, the post was apparently too old, and I must have missed the notice that it was going to be unpublished. Fortunately, Google caches this stuff, so I was able to resurrect the text, which I am reposting below. Thanks, Google!

I'm surprised at how well the content stands up even after nearly a decade. I could have written this today and it would still be valid.

Of course, today I would emphasize the open source angle of this. By looking into the git logs and the like, you can see which architectures are getting the most focus. That's a great hint that the vendor in question is helping to make that software run great with their products.

So when you look into HHVM, Python or PHP, you will see Intel® people contributing and trying to help your PHP and Python programs run faster. Certainly it's possible to write inefficient Python code, so this upstream contribution is not enough. But it's a good start!

Anyway, I hope you enjoy this classic from September 20, 2006. It is reproduced here without editing:

---


I can safely predict that if you are a developer, you are looking for ways to get your job done faster. Get working code quicker, find bugs faster, take advantage of new technologies and get working performance as smoothly as possible. This is why the saying "steal with pride" comes up --it's a well-worn technique to borrow or adopt code where you can. (Of course, I'm not saying you would commit a crime by borrowing copyrighted code, but go with the analogy here).

So it makes sense to think about one of the most common short-cuts available to you: make sure you pick the right Core Software. But I think few developers realize how powerful this is.

It's a sad truth, but for all of the time we spend creating elegant, beautiful code which is a pleasure to read and appreciate, the reality is that the majority of the run time isn't in our code! (This is a blow to my ego, but it's often true.)

For example, countless enterprise applications which are written in Java spend much of their runtime in the JVM. Database apps spend most of their time in the RDBMS engine. Business apps run in the business logic of the app server and so on. Even gaming code these days spends a significant amount of time in a game engine, which comes from a 3rd party.

Now if you are lucky enough to be writing a database or a game engine, then you need to spend a measurable part of your time thinking about performance optimization anyway. This goes for most OS developers, embedded developers and HPC app devs.

But for the rest of us, we are focused on adding features or on threading our application. How can we get ahead of the curve on performance, when the bulk of the time gets spent in the engine?

My advice is to pick the engines which have been optimized for the platforms you care about.

I call this the "Core Software" strategy.

For example, if you are writing a database app, make sure you pick a RDBMS which has been optimized for your hardware. If it's a Java app, pick the JVM that runs best on your platform of choice.

Fine, Dave, but how do you know which one that is? One way is to simply ask the ISV, "Which hardware platform do your core developers use? Which platforms get the follow-on ports?" Look at standard benchmark results, like TPC-C for instance for database servers or SPECjAppServer for Java. Often times software companies don't want to reveal which platform they develop on, but it's hard to hide consistently decent benchmark results.

But don't take my word for it -- find out on your own!

For more complete information about compiler optimizations, see our Optimization Notice.