The cpuburn package contains several hand crafted assembler "burn" programs to load x86 processors and to maximize heat production to stress a system. This also is the intention of the stress-ng "cpu" stress test which contains a variety of methods to stress CPUs with a wide range of instruction mixes. Stress-ng is written in C and relies on the the compiler to generate efficient code to hopefully load the CPU. So how does stress-ng compared to the hand crafted cpuburn suite of programs on modern processors?
Since there is a correlation between power consumed and heat generated, I took the liberty to measure the CPU package power consumption measures using the Intel RAPL interface as one way of comparing cpuburn and stress-ng. Recent versions of powerstat supports RAPL, so I ran each stressor for 120 seconds and took CPU package power measurements every 4 seconds over this interval with powerstat.
So, the cpuburn "burn" programs do well, however, some of the stress-ng CPU stress methods seem to do better. The best stress-ng CPU methods are: ackermann, callfunc, hanoi, decimal128, dither, int128decimal128, trig and zeta. It appears that ackermann, callfunc and hanoi do well because these are very localised deeply recursive function calls, so I expect register save/restores and some stack activity is the main power consumer. The rest exercise the integer and floating point units and memory load/stores.
As it stands, a handful of stress-ng CPU stressors aren't as good as cpuburn. What is noticeable is that burnBX on an i3120M seems to do rather well in terms of loading the CPU.
One conclusion to draw from this is that modern C compilers such as gcc (in this case, gcc 4.9.2) with a suitably chosen mix of stores, loads and integer/floating point operations can outperform hand written assembler in terms of loading the full CPU package. When I have a little more time, I will try and repeat this experiment with clang and gcc 5