On 2/2/2016 2:30 PM, Toon Moene wrote:
On 02/01/2016 12:55 PM, Jose Miguel Reynolds Barredo wrote:
Hi everyone,
I was developing a tridiagonal block solver and I found a performance
issue that is ingriguing me: doing operations with numbers in the
denormalized range is around ten times slower than regular numbers
(https://en.wikipedia.org/wiki/Denormal_number). As an example, I
builded a very simple code:
The reason operations with denormal numbers are ten times slower has -
unfortunately, as otherwise we could do something about it - nothing to
do with the compiler or the run time library (of *any* language).
Denormal number operations are handled by the operating system, because
it is too costly to allocate silicon to handle them on the CPU. So when
the CPU detects a denormal number, it traps. This trap is caught by the
OS, which dispatches the computation to a routine written for the
purpose. The trap and the software implementation of the handling of the
operation involving a denormal are costly, as you observed.
There is nothing the compiler writers (*any* compiler writers, not just
GCC's) can do about this.
You seem to have been unwilling to spend an additional minute reading
the remainder of those Wikipedia posts.
gcc/gfortran bury the initialization of the CPU to abrupt underflow in
the -ffast-math option. ifort makes it a default. This removes the
performance problem, with the consequence of inaccurate results when
underflow is involved.
Intel CPUs released from Sandy Bridge on have eliminated the penalty for
addition/subtraction involving subnormals, largely on account of the
widespread use of gradual underflow with gcc. A significant penalty for
multiplication remains. One might question whether a CPU from over 5
years ago need be your primary target for new project development.
SPARC CPUs historically had a similar problem with underflow.
Intel Itanium CPUs had an extremely severe problem with partial
underflow as well as with true underflow, so operation in gradual
underflow mode was impractical.
--
Tim Prince
