We were making a presentation at Lawrece Livermore this past week...

[Ivan Godard <igodard@xxxxxxxxxxx>]

and they had some interesting things to say about their computational 
needs. Most interestingly to me, they wanted saturating arithmetic 
without denormals (i.e. flush-to-zero), and wanted all NaNs to trap at 
point of production. They said that they had several codes which 
absolutely required FTZ and on a machine with denormals they had to run 
special denormal-replacing loops at places where they could be produced 
in order to remove them. Ditto NaNs, which they always wanted to have 
treated as a program error that should drop to a debugger or logger.

On further digging, it seems that the main reason for wanting FTZ was 
that their hardware trapped on denormals and ran the operation in 
software. As a result the bulk of their actual run time was spent in the 
trap handler rather than in "useful" work. Their algorithms (they felt) 
couldn't use the added precision of a denormal and saturating was much 
faster than the software. If denormals were free (i.e. done in hardware) 
then they might reconsider.

Just a datapoint from a world-class user of FP calculations.

Ivan