Date: Tue, 01 Apr 2008 11:40:22 +0200
From: Terje Mathisen <terje.mathisen@hda.hydro.com>
Newsgroups: comp.arch
Subject: Re: Future Risc
Message-ID: <j4ednTSVtKybnm_anZ2dnUVZ8qGdnZ2d@giganews.com>

Andrew Reilly wrote:
> On Mon, 31 Mar 2008 16:11:49 +0200, Terje Mathisen wrote:
>
>> x87 with 80-bit extended would seem to (mostly) avoid the issue, as long
>> as the load/store pipes could handle it. Did you see the same levels of
>> slowdown here?
>
> I certainly have.  Posit: you've got a recursive filter (i.e., the common
> sort) running real-time on some audio.  The audio source goes digital-
> silent for an extended period of time.  The filter state decays fairly
> slowly, but ultimately it reaches the range of denormals, and suddenly
> your computer appears to have crashed, because the process with real-time
> scheduling priority goes from using <10% to >100% of the CPU.  You pretty
> quickly learn to find the "turn denormals off" switch, or (because there
> isn't one on traditional x87 math) do dorky things like adding low-level
> noise or offset, or periodically flushing state to zero manually.

OK, that does look a lot like the problem my friend Jeff stumbled
across, he was also working with audio processing, and as I wrote, he
had to periodically add some low-level noise/offset.

I don't remember if he ever told me exactly which architecture(s) this
happened on.

> The slowdown really is unaceptable, even when it's handled by the
> hardware.

OK, noted. Thanks!

FlushToZero it is for my code at least.

Terje

--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"