Re: [LAD] "enhanced event port" LV2 extension proposal

Dave Robillard wrote:

> We could use float I guess to save a bit of space, but I definitely
> prefer floating point. Fixed point is just a PITA, modern CPUs are much
> faster at FP anyway, why bother?

1. The "modern CPUs are much faster at FP" thing is a myth that shows up
here and there and is usually taken as a gospel by people who don't know
what they're doing (or what their CPU is doing). It depends. Sure,
implementing an IIR filter with 4:28 fixed point is not going to be
efficient, or even easy. That's one of many tasks where floating point
just works better.

But we were talking about comparing numbers or calculating an integer
difference (with fixed point, it's basically shift and subtract, with
floating point you have float-to-int conversion which is slow and
unelegant unless you use SSE-based conversion or tricks on IEEE
representation, which are not portable).

One could compare an integer loop index to a floating point event
timestamp instead of converting the timestamp to integer, but that would
mean that perhaps every inner loop would have to be written this way.
Bad idea, IMO.

2. With floating point, the precision of the fractional part decreases
with log2(sample_number). This is not going to be a practical problem,
but you're either wasting bits or losing precision here.

3. See: page C-24 in "Intel® 64 and IA-32 Architectures Optimization
Reference Manual" (keep in mind that the tables show latency/throughput
numbers for different CPUs, so compare apples with apples!),
instructions ADD/SUB vs FADD/FSUB. Intel doesn't seem to support your
claim that modern CPUs are much faster at floating point than at fixed
point (assuming same bit allocation) - certainly not for that particular
operation pair :)

And they will probably never be, because the complexity of adding two
floats is simply higher than of adding two integers (because one of the
mantissa values needs to be shifted and exponent has to be set properly).

Of course, it's not just ADD vs FADD. In the reality it's ADD+SHR vs
FADD+float to int conversion (or SUBSS+CVTSS2SI). Still, fixed point
seems to win.

4. I would agree that floating point numbers are usually much better for
representing rational numbers than fixed point numbers are. But
"usually" doesn't mean "always". This particular situation is a textbook
example of where a fixed point values should be used!

Anyway, keep thinking. You already have three solutions to pick from
(floats, 16:16 fixed point, or an integer). If you use integers, perhaps
the timestamps should be stored as delta values. Perhaps fractional
parts could be just stored in events that demand fractional timing (ie.
grain start event), removing that part from generic protocol. Perhaps
we're still overlooking something.

Krzysztof

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Nov 30 12:15:05 2007