Possible performance issue with gfortran? denormalized numbers

[Tim Prince]

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