I'm curious about the mathematical ramifications of turning on or off these various settings.
The options are there for a reason: Because different numerical processing requirements affect the tradeoffs between speed and accuracy. Sometimes, you need the precision, and slowing down the processing is acceptable. Other times, real-time performance might break if processing time increases, and so the accuracy has to be sacrificed in order to meet timing deadlines. For example, in audio DSP, is it always acceptable for reverb tails to fade to a certain level and then suddenly drop to dead silence? Conversely, is it possible to design for sufficiently more processing power than is needed to meet real-time deadlines, such that the extra accuracy for faint signals would contribute to the quality of the sound? Brian Willoughby On Apr 8, 2023, at 2:06 PM, Sampo Syreeni <de...@iki.fi> wrote: > On 2023-03-27, Ethan Fenn wrote: >> My understanding is that on any reasonably modern Intel/AMD machines, you >> just have to make sure that the Flush To Zero (FTZ) and Denormals Are Zero >> (DAZ) hardware flags are set when your DSP code runs and there will be no >> penalty. > > Only it's really difficult to set those flags from the userspace. Also, > handling the exceptions in case they would be the best way to go about, is > doubly so. > > The predominant IEEE floating point standard is nowhere near the kind of > hardware-software integration we'd like to have today. It leaves too much > into the air, quite irrespective of bit width. > > Oh, and do take a look at what they've done in narrower formats in the GPGPU, > TPU and like formats, aimed at AI work. They don't do flags or exceptions at > all. Obviously they don't cater to DSP either, but they've as well simplified > the architecture down from denormals, DnD's, infinitudes, asynchronous > exceptions, and the like.
