The Engineer-in-a-Box: Lucky You!

When I posted recently about the Core Software Strategy, I was advocating that when you are looking at implementing a project, you should spend at least some effort in identifying what is the "engine" which consumes most of the runtime of the application or system, and at least pick an engine that has been optimized for the platform you are likely to run on. This will greatly simplify the task of getting reasonable performance, particularly if it's an engine that Intel has been spending a lot of time and effort optimizing. Intel engineers work with the most popular engines out there, use workloads which represent common usages, and optimize the heck out of those code paths which get exercised.

This turns out to be a fine strategy, if in fact the majority of your runtime is in such "engine" code. In fact, there are plenty of cases where you are doing a fair amount of computation in your code, and you are not able to depend on an engine like a database or a gaming engine.

Fortunately, you are in luck!

In many cases, when we work with some company's application, we would like to see if we can achieve speedup by focusing on how our compilers generate code. For example, suppose we work with an ISV's code and we observe that a particular code sequence is getting generated by our compilers which cause performance degradation, like unnecessary cache misses and the like. Rather than suggest that the source code change, we can get into our compilers and get it to generate better code.

This has big advantages! By improving the code generation, we can make these optimizations available to a broader audience when they have code or workloads which are similar to the ones we have worked with.

This is why you often hear our Intel folk recommend that your first step for getting better code is to switch to the Intel Compiler! This product represents not only the wealth of experience of the guys working on the compiler itself, it also represents countless engineer hours, experts like Robert Reed and David Levinthal who are going deep into how code behaves in other applications, and looking for ways to make their improvements available to others. It's like getting an army of performance engineers in that compiler box!

One story here to make the point. I have a collegue here who was working with a particular application and having no luck getting it to scale. He was really getting frustrated about it. We were both hanging out playing pool at a party, and I remember him saying that he thought this particular application domain just doesn't work well on Intel Architecture! Now this is a particularly brilliant engineer with tons of experience, so I know how frustrated people can get when they can't solve a performance problem. We talked about it for a while, and I hooked him up with another engineer who was pretty successful in driving his changes into the compiler. Know what? By trying a particular "-O" optimization flag, he got a terrific boost in performance, and was on his way to ultimate success!

So how can you take the best advantage of this engineer who comes in the box?

· Switch to the Intel compiler. If you develop today in C++ on either Windows or Linux, you should definitely go in this direction.

· Evaluate several of the "-O" optimization flags. The different optimization levels represent different characteristic workloads, so you need to pick the right one.

· Measure the impact of your changes with a repeatable workload that can have a representative metric. This is a deep topic here, but don't just take my word for it " measure your results!

· Check out some of the useful content on this topic in the Intel Software Network or a class with the Intel Software College.

One closing thought. The above assumes that most of your system runtime is outside of the Core Software, and when I say "system runtime", I am including the many tiers of a server application. Do you know where your application or system spends most of it's time? How long has it been since you ran a profile on your application? Have you checked out VTune lately?


The opinions in this piece are mine alone and do not reflect the official position of Intel on products or strategies.