# What is the underlying structure of scientific code performance?

Consider two computers with different hardware and software configurations. When running the exact same serial Navier-Stokes code on each platform it takes x and y time to execute one iteration for computer 1 and 2, respectively. In this case, $\Delta = x-y$, is the iteration time difference between computer 1 and computer 2.

What could be the impacting the magnitude of $\Delta$? One obvious candidate is the CPU, my main question is whether there are other factors that could be impacting $\Delta$ on the same order as the hardware difference between CPUs?

• Of course your $\Delta$ is just a single sample. You should also investigate on how $\Delta$ depends on problem size and structure. Second I would suggest to profile the code, trying to split $x$ and $y$ in the sum of different contributions, and analyzing the performance of different portions of the code with respect to the hw and sw configurations. – Stefano M Aug 29 '13 at 22:12
• CACHE LINE MISSES. That's the first thing to consider. Memory is the bottleneck factor for a lot of algorithms. – Deer Hunter Aug 30 '13 at 7:51

This list is nowhere near complete, but hopefully the size of it will give a hint as to the scale of possible factors. I am assuming you are compiling the code from source on your platform of choice.

Software

• Standard Library Performance
• Lin. Alg. Library Performance (if the software links to outside libraries)
• Compiler Choice
• Compiler Optimization
• Compiler Flags
• Background Processes (May vary significantly if OSes are different)

Hardware

CPU

• Clock Speed
• Architecture (the same instruction may take different numbers of cycles on different architectures)
• Cache Sizes
• Cache Latency
• SIMD (Single Instruction, Multiple Data) Capability

Memory

• Number of Channels
• Speed

HDD

• Read/Write speed (mostly only important for writing results, so this depends on how often you are writting output to file for a NS solver, but could be important for other programs that do things such as image processing)

This is all ignoring the little tricks and features different manufacturers include to give their chips an edge in the market. The big one though is that many sparse linear algebra libraries are memory bound. Doing a sparse matrix multiply involves a lot of data moving around without many actual flops.

• I would add, to the CPU, both the number of cores and its SIMD capabilities. – Pedro Aug 28 '13 at 20:22
• @Pedro I left cores off since the question said serial solver, but I will add SIMD. Thanks. – Godric Seer Aug 28 '13 at 20:24
• @GodricSeer I compiled on one machine and then ran it. Then, using the same compiled executable I ran it on second machine. From your explanation it seems it would be better to recompile from source on the second computer. Is that the case? – Isopycnal Oscillation Aug 28 '13 at 20:35
• @IsopycnalOscillation When compiling on/for a specific machine, you can use the gcc/gfortran option -march=native, or the icc/ifort option -xHOST which will apply optimizations specific to the underlying architecture. – Pedro Aug 28 '13 at 20:48
• A key point here is that computer performance is not a one dimensional quantity. The relative balance of all the factors that Godric has listed above can vary tremendously, even for computers with processor chips from the same manufacturer (e.g. Intel.) As a result, different benchmarks can show very different performance ratios for two processors. As a practical matter, most modern machines are seriously lacking in memory bandwidth to support scientific computing workloads and this is often the bottleneck. – Brian Borchers Aug 30 '13 at 1:25

First, @Godric's answer is good, but I would suggest you think in terms of $x/y$, not $x-y$, so you don't have to qualify it by the size of the problem.

Second, your question specifically excludes differences in software. In my experience, the performance rewards for careful tuning can be large factors, so while you're considering hardware issues, don't forget software issues. After all, the hardware can only execute the instructions you give it, and if you give it fewer, it will finish sooner.

Not to expand on this too much, but for any given problem there is a countable infinity of programs that will solve it. Among these, some take less time than all the others, and that is a lower bound. Don't assume any program is at or even near this lower bound if it hasn't been carefully tuned.

This link explains in detail the unorthodox method I use.