I searched the forum, but saw no technical argument for a 64 bit pipeline. Could someone explain to me why we are migrating to 64 bits, or point me to such an argument please?

There are certainly arguments against it. MMX optimisations for one.

The latest and greatest, XMM, can process two doubles (64 bit) at once, but that's only on P4-level CPUs. It can also process 4 floats (32 bit) at once. Older CPUs derive nothing from MMX with doubles, but still benefit with floats.

32-bit float has a 24-bit mantissa. I'd assume, from extrapolation, that 64-bit has a 48-bit mantissa? That way, you can get accurate 32-bit linear output. :B With 32-bit, you're limited to a total range of 24-bits, assuming that there's no dynamic range exploitation of more or less. This way, DSPs that add a bit or two of error can be more easily accommodated, and do not negatively affect 24-bit output.

It's a tradeoff: Speed, or (somewhat negligible) Quality? FB2K's always been more about the quality, although the 64-bit math may significantly affect older CPUs.

Although I'm sure some people would appreciate the ability to choose between the formats, it'd probably be a headache for some plugin developers, and for Peter. Thus, I doubt that feature'll come.

Let's also add that MMX cannot manipulate any form of floating point data. You'd be better off using SSE or 3DNow!, if modern platforms will benefit noticeably from SIMD optimized code.

Well, we can settle the numbers.

IEEE single precision, AKA 32 bit floating point, utilizes 1 bit for sign, 8 bits for exponent and 23 bits for mantissa. The exponent is normalized so that the most significant bit of mantissa is always 1 (except for the smallest numbers). This bit is called the integer bit, and is not stored. So, the effective mantissa is 24 bits.

IEEE double precision is 64 bits. Again, 1 sign bit. After that, 11 exponent bits and 52 mantissa bits. The integer bit is not recorded again, yielding effective 53 bit mantissa. The 11 bit exponent gives sufficient dynamic range (2^2^11 = 2^2048 ~ 10^616.5 = 12330 dB) to compare the sizes of the universe and a neutrino and still leaves plenty of headroom. The 53 bit mantissa can locate that neutrino anywhere in the solar system, not to mention positioning air molecules in your room. The actual precision is 2^53 ~ 10^16 = 319 dB.

Single precision gives you a dynamic range of 2^256 ~ 10^77.1 = 1541 dB and precision of 2^24 ~ 10^7.22 = 144 dB.

But does a 24 bit mantissa hold the same information as a 24 bit integer? No, it holds more. The 24 bit integer knows whether it is positive or negative, and that information takes up a bit. The mantissa does not, the information is placed in the sign bit. So, a single precision float is as precise as a 25 bit integer. (Btw, all dB values above do not count the sign. I think we should measure the distance from 0 to full scale, not -fs to fs. Otherwise, bump by 6 dB.)

Moreover, this only applies when the integer is over half full scale. When the integer is less than that its most significant bits are wasted. When it goes over full scale, it clips. The float maintains the same logarithmic precision in both cases. It is more precise than the integer with quieter signals, and it sacrifices a (linear) lsb when it goes over (linear) fs.

So, single precision does give you one extra bit for errors at all times, it preserves precision when you would otherwise clip, and it is far more precise with quiet signals. My question stands, why do we need the extra 29 bits?

Yes, I do mean extensions that build on top of MMX. The modern platforms can definitely benefit from the acceleration of the computation. All it takes is some custom inline assembly, no OS support required.

Could you elaborate on what you mean? You are very vague here.

MMX is not a floating-point instruction set and AFAIK it can't help in FP arithmetic. That is what your FPU & Streaming SIMD Extensions are for. I'm not clear on which extensions you are referring to.

How can non-FP (emulated?) code yield better performance than the SSE2+ architecture? If what you are saying is true, then your idea should be quite popular. I know that floating-point registers map onto the MMX storage bank, but I can't make the better-than-intel connection.

EDIT: Perhaps you could post some code to illustrate. I believe most here know IA32 assembly.

Is it true that there is a migration to 64 bit fp? As explained by Doctor, this is totally useless as an audio data interchange format, 32 bit fp is already overkill. The only effect of using 64 bit would be to consume more resources, without giving any audible improvements *at all*, in *any* case.

I might be totally off here, but why then not use a 32 bit (signed?) integer. That should be fast on any CPU and has plenty of "range" and precision.

Sorry if I missed the good reason for using floats
--
Ge Someone

Integer numbers have the drawbacks of being subject to overflows (equivalent to clipping), and to "destructive" loss of resolution on certain operations. For example, if you attenuate a 32 bit integer wave, say 100 dB, you lose 100 dB of precision that can't be recovered again even if you amplify it 100 dB. On the contrary, with floating point there would be little of no loss of precision in thas exact same case, and there can be no clipping under any circumstances.

hups

wonder how long it takes to see people swear up and down that they can 'feel' a huge difference with 64-bit?

True, but there are floating-point caveats as well:
- unlike with integers, the addition and substraction is not always exact
- unlike with integers, the data set is distributed unevenly in the set of numbers.

In general, when you know in advance the magnitude of the data you'll be working with, you should use a fixed-point representation (it's the most efficient for a given number of bits).

Floating-point is needed for some very complex filters, where magnitude of numbers can vary greatly. Unfortunately, many people use floating-point for everything (including file pointers !) just because it's easy - which is an aberration.

64-bit floating point could be useful in theory, when dealing with very complex filter combinations. However, the said filters usually treat numbers as 80-bit internally, so it's no real issue I think.

Depends upon the DSPs being used, yes with fp you could scale down (or up) a few orders of magnitude and it will go through the DSP chain, but before it goes to the sound card it needs scaling right. Personally I cannot think of a situation where integers and correct ordered DSPs would not give the same results.

But that said any graphic eq will certainly use fp (did Winamp have a fixed interger eq?)

In fact many of the most powerful algorithms (RSA, JPEG2000 decoding, arithmetic coding) are all done using integer operations.

I have nothing against a switch from 32-bit to 64-bit FP in foobar - because there's most certainly no performance hit on current workstation CPUs - but let's think a bit about an embedded foobar (on a portable) that should be integer-friendly..

Wouldn't it be nice if there was two possible pipelines (let's say 32/48/64-bit integer vs. 64-bit FP) ? That would allow for direct re-use on small devices with weak floating-point possibilities..

BTW: 2-3 years ago I implemented a 10-band graphic equalizer using solely 48-bit integer operations on a DSP, and it ran much faster than its FP counterpart.

Arithmetic coding isn't really done with integer operations. It uses integers to represent fixed point decimal numbers.

But is exact enough for all means in this case. See, I'm talking about 32 bit fp as interchange format among components in the pipeline. For complex operations inside components, many times 64-bit or even 80-bit fp is needed and is in fact currently used for good accuracy. Integer representation in audio is only needed at the time of feeding the DAC, and can be easily converted from floating point just rounding the values.



Similarly, not a problem in audio and this particular case.

CEP also uses 32 bit fp as representation format (although I'd bet a greater precision is used for some DSP operations) and I haven't seen a case where this is not enough.



I think that in case of audio, a floating point representation saves a lot of problems and has no practical drawbacks.



Agreed. However, in this case we are in the case of those complex operations, or results from those operations: decoding, filtering, etc. Floating point makes much easier and problem-free the chaining of different DSPs.

I think it's because integer is faster in most platforms, and more portable.



I have against it that is is useless. It's like putting an 1-inch thick cable as interconnect. Does nothing but give a warm feeling to esoteric-type audiophiles. Is same as using floats as file pointers, it has no sense.



On the contrary, this would have advantages in case of low resources machines.

"<KikeG> I think 64 bit floating point would sound better"
:B
Anyway, float64 pipeline has NOTHING to do with ANYTHING audible, it's mere for DSP accuracy etc.
I won't be arsed to explain anything in this thread since it pisses me off too much.
It's hard to reply civilized to such an idiotic startpost of this thread, easier to remove the goddamn thread or stay away from it.
For those who think float64 "sound better" - piss off.
For those who think it's unneeded - too bad for you - it's there and you can't do shit about it so stop whining....

Yes, I was just provoking people at the IRC because it was too quiet, read the whole conversation. By the way, I indeed provoked Peter, so I can't understand this change now.


That kind of accuracy is needed just inside the DSP's but not outside them. I use 32 fp regularly as "result" format in CEP and I've not seen any problem with it, even doing complex DSP operations.



Sorry, but I'll whine as much as I want over this issue because:

1.- I think 64 bit fp has no sense.
2.- Even if it's not changed I have all the rights to say it is useless. I can't change a lot of things that I don't like in the world, but that doesn't prevent me from complaining against them.

Yeah, I know you were trolling IRC about that. hehe, but still it was fun to insert at this point.

about bitching about this - it's highly unintersting. Sure you can point out that there little use of it; that it would not likely yield in any difference of important matters, but.... it's still uninteresting. No whiningthreads are apprciated.
It's there - it will stay - no use whining.

edit: whining is extremely annoying

For you, maybe. Not for me. Who knows for others.



Even if they are fair?



And your posts recommending me to shut up are too. Sorry.

Why is it and idiotic post? Why insult people this way? It seems that Doctor knows what he's talking about (apart from his confussion on MMX issue), and he was just asking something. He deserves some respect.

Please read FB2K forum rule nº 2.

Read how to post on this forum...

If this thread doesn't become constructive quickly, I'm going to close it.

:-P

It never was constructive, it's just about whining