64 bit summing engine -- how far should it be pushed?

[earlevel]

Yes, it's of course more complicated in the details. Mentioning 24 bits was quite arbitrary and I could have said as a controversial bait for example 18 bits.

True. And of course the the real complication is one could be talking about the data path between processes, or the computational bit-depth. It makes my head hurt when I happen upon similar discussions on less-knowledgable boards (say, ones that are primarily about using a particular DAW, where the people are musicians, not engineers), and six or eight people are having a big flame war over bit depth, and most of them are talking about completely different things without knowing it.

[Xenakios]

IIRC Xenakios' app hourGlass has some bit-crushing capacities among it's many mangling possibilities. You might like it.

Well, thanks for the compliment but actually HourGlass doesn't yet have a really proper sound degrader built-in. The Bitmapper thing can achieve the usual bit reduction result, but is quite inconvenient to use just for that purpose. (Getting a 8 bit reduction can require 8 mouse clicks heheh...) The specialty about that effect is that it can turn bits on/off and route them to other bits (also "summing" them), to cause quite unpredictable (but pretty much certainly noisy and severely distorted) results.

[Richard_Synapse]

The whole path being 64 bit isn't a huge performance hit at all, unless some 3rd party stuff messes things up in the middle. Reaper's developer has done test builds of Reaper so that it uses 32 bit floating point numbers instead of 64 bit ones to see if there's some notable performance difference, and there wasn't. "Massively slow down" is thus grossly exaggerated. Audio buffers being 64 bit floats double the memory usage of the buffers obviously, though. (And perhaps with really old hardware that additional memory bandwidth use might slow down actual DSP calculations too, but we really should always talk about realistic average current day hardware and not some junk from 2001.)

Memory is still a bottleneck today, even more so with multiple cores sharing the same data. But that's not the only problem, when using e.g. SSE2 instead of SSE code that alone can half the performance (2 doubles versus 4 floats). So no, I did not exaggerate, as that's a big difference compared to the <1% or so that the 64-bit summing costs.

Note that in order to measure the correct 64-bit performance, all plugins have to employ a full 64-bit signal path (very few do that). Mixing in anything that contains 32-bit code will of course skew results.

Richard

[dasdeck]

btw. is it true that 32 bit SSE calculations can be less precise then normal 32 bit float, as the alu can store in between values with greater precision (like 80 bits or something) ? i use 64 bit SSE for most of my stuff, as most of the time i can not process things in parallel anyways, and stereo comes very cheap most of the times then (there may be places for channel interaction of course). you can also see that 32bit 64bit can have quite different values for calculated filter coeffs for example.

not really relevant for the original posters question thought. sorry for that.

cheers


jm

[Richard_Synapse]

Yeah, using doubles makes things a lot easier and more precise, but not as performant. Fundamentally speaking, the time (or complexity) required to add two 64-bit numbers is always twice that of adding two 32-bit numbers, and for the more important multiplications and divisions it gets worse the higher the bit count (as those operations do not scale linearly).

So 32-bit processing is going to stay around for a while, with the upcoming AVX2 we'll still be able to process 8 floats in parallel vs. 4 doubles. With FMA and gather support it'll be a dream for DSP development in any case.

Richard