Assert vs AssertThrow in the testsuite

[bangerth]

@Rombur writes:
...................
I checked in the testsuite and we use Assert 2644 times and AssertThrow 63 times. I found several tests that do nothing in release in mode :( Should we just change all of the Assert to AssertThrow or go through all the tests and see what's appropriate ?
...................

It's a good question. I don't know what to do. We could:

• Ignore the issue. Most of these tests probably still produce output that is indicative of whether the code worked. We run 7200 tests, if even 100 of those don't do anything in release mode, then that's still only 1%.
• Make a wholesale change. We have a few tests that explicitly want exceptions instead of aborts from Assert but that I think they can only (and probably do) only run in debug mode.
• Other options?

[tjhei]

While I haven't seen/fixed any bug by running the release mode tests, I do think it would be useful to have better coverage in release mode. This is because I had problems with the Intel compiler generating wrong optimized code in the past (hey, that is why we are disabling vectorization...).

But yes, there are several tests that expect exceptions/asserts to trigger so we need to be careful there.

[Rombur]

I checked in the testsuite and, for the Intel compiler, there are tests that fail only in release mode. So the Intel compiler is probably in worse shape that we think. I will go through the testsuite and change Assert to AssertThrow when I think it's appropriate.

[tjhei]

That might also be due to different output/rounding. What tests do you refer to?

[Rombur]

These two tests fail in release mode with nan:
http://cdash.kyomu.43-1.org/testDetails.php?test=7269087&build=4338
http://cdash.kyomu.43-1.org/testDetails.php?test=7270748&build=4338

[tjhei]

Urgh. That boils down to

      DEAL_II_OPENMP_SIMD_PRAGMA
      for (size_type i=begin; i<end; ++i)
        val[i] += v_val[i];

forgetting the last element. Has anybody looked into this further?

[tjhei]

(otherwise we need to blacklist DEAL_II_HAVE_OPENMP_SIMD)

[Rombur]

We could but that's kinda sad that we have to disable vectorization on the only compiler that supports Xeon Phi.

[bangerth]

Is this reproducible on a smaller, self-contained testcase? It's a common enough operation, and a common enough compiler, that it worries me :-(

[tjhei]

Vectorization is already disabled on intel (see check_03_compiler_bugs):

IF(CMAKE_CXX_COMPILER_ID MATCHES "Intel")
  ENABLE_IF_SUPPORTED(DEAL_II_CXX_FLAGS_RELEASE "-no-vec")
ENDIF()

So Xeon Phi compilations do not use vectorization. I should probably revisit this with Intel 15...

[tjhei]

@bangerth I will take a look.

[Rombur]

Yeah but that's the autovectorization. DEAL_II_HAVE_OPENMP_SIMD is the vectorization through OpenMP 4 that's another flag.

[tjhei]

see #607.

[tjhei]

So it is a combination of TBB and SIMD and only for long double. :-(

[Rombur]

That's strange, long double should be 128 bits which means that only Haswell and Broadwell can use the SIMD instructions. Well if it only affects long double that's a good news.

[Rombur]

Apparently vectorization is not supported for long double. I guess we can specialize the template so we don't use SIMD for long double.

[bangerth]

I thought long double uses the crazy and ill-conceived 80-bit floating point format on Intel. Or did they fix this wart in the x86_64 ABI?

[Rombur]

It is 80-bit plus padding to get 128-bit... But I found a post on Intel forum where they say that you cannot use vectorization for either long double or quad precision.

[bangerth]

Sure would have been nice if they just disabled it in that case...

[tjhei]

So what do we do, add this as a compiler check and disable SIMD conditionally?

[bangerth]

I like Bruno's suggestion of using an explicit specialization for this one function.

[kronbichler]

Just one more comment on long double and vectorization to extend on @Rombur : For 80-bit calculations, legacy x87 instructions are used instead of the SSE2 or AVX instructions that get used for double and single precision. Before SSE2/SSE, all computations were done with 80 bit internally but got truncated/rounded before saved to memory. Now the hardware for float and double has introduced vectorization but not for other floating point types. This is well documented in all manuals on SSE2/AVX/AVX512 etc.
I think it makes sense to only have them because vectorization requires several units. A (scalar) 128 bit multiplier certainly has hundreds of thousands of transistors and the field of applications that need true quad precision in hardware is most likely way to narrow to justify general purpose hardware (I don't know many cases where double-double precision is not enough; it is somewhat less accurate but avoids introducing expensive hardware). Let alone to have these guys replicated for vectorization. Hey, as an HPC person I am already happy that double precision runs at half the width of single precision on literally all relevant CPUs. It could be one tenth or less like on GPUs because 95% of processors rarely need double precision.

But back to the topic: thanks for finding the reason and I also favor @Rombur suggestion.

[tjhei]

Okay, easy enough. I will prepare a patch.