11
$\begingroup$

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?

$\endgroup$
2
  • 4
    $\begingroup$ 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. $\endgroup$
    – Stefano M
    Aug 29, 2013 at 22:12
  • 4
    $\begingroup$ CACHE LINE MISSES. That's the first thing to consider. Memory is the bottleneck factor for a lot of algorithms. $\endgroup$ Aug 30, 2013 at 7:51

2 Answers 2

13
$\begingroup$

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.

$\endgroup$
7
  • $\begingroup$ I would add, to the CPU, both the number of cores and its SIMD capabilities. $\endgroup$
    – Pedro
    Aug 28, 2013 at 20:22
  • $\begingroup$ @Pedro I left cores off since the question said serial solver, but I will add SIMD. Thanks. $\endgroup$ Aug 28, 2013 at 20:24
  • 1
    $\begingroup$ @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? $\endgroup$ Aug 28, 2013 at 20:35
  • 1
    $\begingroup$ @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. $\endgroup$
    – Pedro
    Aug 28, 2013 at 20:48
  • 1
    $\begingroup$ 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. $\endgroup$ Aug 30, 2013 at 1:25
2
$\begingroup$

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.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.