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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
