2
$\begingroup$

Which C standard should be used for computational science code ?

Should we keep compatibility with C89/90/ANSI or jump to C99 or C11 ?

Context:

  • Code will use third-party : BLAS, LAPACK, MKL, OpenBlas, Direct Sparse Solvers, ...
  • Parallel computation | HPC | OpenMP | MPI
$\endgroup$
1
  • $\begingroup$ FYI: some useful libraries (e.g. <boost.org/>) are only available in C++. The speed benefits (if any) of using C over C++ might not be worth it. $\endgroup$
    – solalito
    Commented Jan 16, 2019 at 14:09

3 Answers 3

9
$\begingroup$

In theory, as the original authors, you're free to pick and name a standard, then expect others to follow it. In practise, if you're supporting an HPC system, then your choice is likely to be restricted among the compiler standards that the given system you're using for testing has for its tool stack (you are testing your software, aren't you?). This might involve having to roll your own code to get around various compiler bugs which have slipped into the various implementations out in the wild. This all ought to be documented.

In terms of following the herd, then following a moderately recent version of clang's implementation of C11 is now relatively unlikely to leave potential users out in the cold, but don't be too surprised to be contacted by someone trying to build on outlandish hardware with a hand-rolled compiler forked from an ancient version of gcc. It's then up to your project how much free customer support you want to attempt to give them.

$\endgroup$
1
  • 1
    $\begingroup$ I agree. I consider C11 to be safe for use these days. In fact, C++11 is also safe for use these days. $\endgroup$ Commented Jan 16, 2019 at 0:59
7
$\begingroup$

You should definitely jump to C99, or newer(!). The C99 standard introduced the restrict keyword. Loosely speaking, with this keyword you can inform the compiler that A[i] and B[j] do not access the same memory location. In that case the compiler can generate better optimized code.

For example, it makes it easier for the compiler to auto-vectorize code. This is essential for achieving high performance on today's CPUs, which usually support SIMD instruction sets (such as Intel SSE/AVX, Arm NEON, PowerPC Altivec, etc.).

Citing the restrict Wikipedia page: The use of the restrict keyword in C, in principle, allows non-obtuse C to achieve the same performance as the same program written in Fortran.

$\endgroup$
1
  • $\begingroup$ Thank you for your answer and all references! $\endgroup$ Commented Jan 16, 2019 at 15:08
0
$\begingroup$

I'd say when in doubt, use the oldest standard possible. Who knows what kind of compilers we'll encounter on increasingly powerful iot and accelerator devices. Custom installed parallel clusters are always good for a surprise as well.

There is good reason to use restrict, but I'd do this in a portable way by testing its availability with cmake or autoconf and #define it to nothing if not supported. This way you get the best of both worlds.

$\endgroup$

Your Answer

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

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