log in | contact | about 
 

This short post is an update for the previous blog entry. Most likely,
the Intel compiler does not produce the code that is 100x faster, at least, not under normal circumstances. The updated benchmark is posted on the GitHub. Note that the explanation below is just my guess, I will be happy to hear an alternative version.

It looks like the Intel compiler is super-clever and can dynamically adjust accuracy of computation. Consider the following code:

  1. float sum = 0;
  2. for (int j = 0; j < rep; ++j) {
  3. for (int i = 0; i < N*4; i+=4) {
  4. sum += exp(data[i]);
  5. sum += exp(data[i+1]);
  6. sum += exp(data[i+2]);
  7. sum += exp(data[i+3]);
  8. }
  9. }

Here the sum becomes huge very quickly. Thus, the result of calling exp becomes very small compared to sum. It appears to me that the code built with the Intel compiler does detect this situation. Probably, at run-time. After this happens, the function exp is computed using a very low-accuracy algorithm or not computed at all. As a result, when I ran this benchmark on a pre-historic Intel Core Duo 2GHz, I was still able to crunch billions of exp per second, which was clearly impossible. Consider now the following, updated, benchmark code:

  1. float sum = 0;
  2. for (int j = 0; j < rep; ++j) {
  3. for (int i = 0; i < N*4; i+=4) {
  4. sum += exp(data[i]);
  5. sum += exp(data[i+1]);
  6. sum += exp(data[i+2]);
  7. sum += exp(data[i+3]);
  8. }
  9. sum /= float(N*4); // Don't allow sum become huge!
  10. }

Note line 9. It prevents sum from becoming huge. Now, we are getting more reasonable performance figures. In particular, for single-precision values, i.e., floats,
the Intel compiler produces a code that is only 10x faster compared to code produced by the GNU compiler. It is a large difference, but it is probably due to using SIMD
extensions for Intel.