|
The floating point unit works at 80 bit precision on
32 bit Intel (and, I believe, 64 bit Intel) but when results are moved to memory
(including, where necessary, temporaries) then the results are truncated to 64
bits. SSE instructions exist to process both 32 single precision and 64
bit double precision values. Single precision values are processed
four at a time and double precision two at a time, so single precision is faster
for this (but not much else). I actually found that vectorising
double-precision operations made little difference, but that might be
because I don't know much about SSE and wasn't getting the best out of
it.
The DSP I do (IIR filters, Fourier transforms, matrix
manipulation and some other stuff) is mostly done in double precision because if
you work in single precision the errors mount up, depending on the exact
nature of the maths you are doing, even if the samples themselves are
relatively low precision.
A 'hidden' factor influencing speed is
that fewer double precision numbers fit in the CPU
cache and for this reason I do my FFT's on single precision arrays,
which speeds things up noticeably and seems to work pretty well. OTOH
matrix manipulation (specifically, matrix inversion) in single precision
sometimes gives hopelessly unpredictable results so I had to give up
on that idea. Google numerical stability for some insight as to
why.
I have no idea if any of what I just said is useful to
anyone. As Jens says, there are people who hang out on the core-audio list
who know about this kind of stuff. You might also want to visit
dsprelated.com and possibly Hydrogen Audio.
Regards,
Paul Sanders.
----- Original Message -----
Sent: Monday, June 14, 2010 7:17 PM
Subject: Re: long double data type
On Jun 14, 2010, at 10:58 AM, Luigi Castelli wrote:
> I am
working on a DSP audio mastering application that needs to perform mathematical
operation at very high resolution.
CoreAudio natively uses 32-bit floats
(with 24-bit mantissa) to represent samples. I believe that resolution’s
sufficient for even pro apps — Red Book [CD] audio is only 16 bits, and I don’t
think even high-end formats use more than 24-bit.
I’m not an expert on FP
math, but I don’t know of any float data type supported on Mac OS with more than
64 bits of precision (aka ‘double’).
> Is it a viable choice for a DSP
audio application or will I regret it in the long run?
To my knowledge,
the vector processing units on x86 only support 32-bit floats. So you wouldn’t
be able to vectorize higher-resolution operations, greatly reducing performance.
Definitely a consideration if you want to run in real-time.
You might
want to ask on the coreaudio-api list, in case anyone has advice on what kind of
numeric precision is needed for pro audio work.
—Jens
|