Re: [music-dsp] Efficiency of clear/copy/offset buffers
On Mar 8, 2013, at 2:53 PM, ChordWizard Software corpor...@chordwizard.com wrote: But some are quite new - I never realised that multiplication ops were more efficient than divisions. Worthy of some background... When multiplying, you can do all the necessary multiplications in parallel (think of performing a long multiply by hand—1234 x 5678 for instance. It's easy to imagine how you could speed this up by having a few friends help you, where you manage the first digit, 4 x 5678, another handles 3(0) x 5678, etc., at the same time.) but when you divide, you need to finish one digit before you know what the remainder is and you can move to the next digit. There's no way to look ahead—you need the result of the first step before doing the second. So, processors optimize multiplication and addition with parallel circuits, but division is iterated in a microcode loop (or done entirely in software). The 56K DSPs, for instance have a single-cycle multiply, but for division, DIV is a single division iteration—you need to do it for every digit you need to generate. It's just the nature of the operation. Compilers may help you optimize constants, but it's always best to keep track of things yourself so you know what you're getting. So, yes, multiply by the sample period instead of dividing by the sample rate, etc. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. -Original Message- From: Nigel Redmon Sent: Saturday, March 09, 2013 5:15 PM To: A discussion list for music-related DSP Subject: Re: [music-dsp] Efficiency of clear/copy/offset buffers On Mar 8, 2013, at 2:53 PM, ChordWizard Software corpor...@chordwizard.com wrote: But some are quite new - I never realised that multiplication ops were more efficient than divisions. Worthy of some background... When multiplying, you can do all the necessary multiplications in parallel (think of performing a long multiply by hand—1234 x 5678 for instance. It's easy to imagine how you could speed this up by having a few friends help you, where you manage the first digit, 4 x 5678, another handles 3(0) x 5678, etc., at the same time.) but when you divide, you need to finish one digit before you know what the remainder is and you can move to the next digit. There's no way to look ahead—you need the result of the first step before doing the second. So, processors optimize multiplication and addition with parallel circuits, but division is iterated in a microcode loop (or done entirely in software). The 56K DSPs, for instance have a single-cycle multiply, but for division, DIV is a single division iteration—you need to do it for every digit you need to generate. It's just the nature of the operation. Compilers may help you optimize constants, but it's always best to keep track of things yourself so you know what you're getting. So, yes, multiply by the sample period instead of dividing by the sample rate, etc. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
On 3/9/13 1:31 PM, Wen Xue wrote: I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. there are some awful crappy compilers out there. even ones that start from gnu and somehow become a product sold for use with some DSP. i think this guy named Michael Kahl should be the compiler czar of the world. no compiler or development system is released anywhere in the world without his design and/or approval of it. -- r b-j r...@audioimagination.com Imagination is more important than knowledge. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
On Mar 8, 2013, at 10:55 PM, Ross Bencina wrote: If your input is MIDI master volume you have to map from the MIDI value range to linear gain (perhaps via decibels). Maybe there is a standard curve for this? There may be standards for subsets, such as GM. Or perhaps even a more global standard nowadays. Dunno. I have many older MIDI hardware synthesizers, from years when collecting them was almost a sickness. The older ones didn't appear to follow any standard and in fact even similar models from the same manufacturer couldn't be expected to follow an identical company standard volume curve. Maybe there is more consistency nowadays? Tis been many years since buying a new hardware synth. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] Efficiency of clear/copy/offset buffers
There is some discussion here: http://www.kvraudio.com/forum/viewtopic.php?t=348751 Hey Ross, this was a good thread. So the pcture I'm getting is this: 1) a gain curve that is linear in dB will produce an ideal profile where equal incremental movements along the curve produce an equal changes in perceived volume. 2) you can never get this curve to hit zero amplitude, which occurs at dB=-infinity, so you have to patch in a linear segment at the bottom to deal with this 3) a quick-and-dirty solution that approximates the linear dB gain curve (and handles the zero amplitude case automatically) is a simple x^2 curve (in range 0.0 to 1.0) Does it sound like I have the right end of the stick? When multiplying, you can do all the necessary multiplications in parallel (think of performing a long multiply by hand?1234 x 5678 for instance. It's easy to imagine how you could speed this up by having a few friends help you Nigel, thanks for this insight. Makes perfect sense. Regards, Stephen Clarke Managing Director ChordWizard Software Pty Ltd corpor...@chordwizard.com http://www.chordwizard.com ph: (+61) 2 4960 9520 fax: (+61) 2 4960 9580 -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
[robert bristow-johnson] On 3/9/13 1:31 PM, Wen Xue wrote: I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. there are some awful crappy compilers out there. even ones that start from gnu and somehow become a product sold for use with some DSP. Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. (I think the denominator was a c++ template parameter subjected to a binary shift operator but my memory of the exact circumstances is hazy. I do remember it was easy to evaluate at compile time, and my surprise at the compiler not getting it.) Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. there are some awful crappy compilers out there. even ones that start from gnu and somehow become a product sold for use with some DSP. Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. not necessarily: in floating point math a/b and a * (1/b) do not yield the same result. therefore the compile should not optimize this, unless explicitly asked to do so (-freciprocal-math) tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
[Tim Blechmann] Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. not necessarily: in floating point math a/b and a * (1/b) do not yield the same result. therefore the compile should not optimize this, unless explicitly asked to do so (-freciprocal-math) I should have added, when employing the usual suspects, -ffast-math -O6 etc, as you usually would when compiling DSP code. Sorry! Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
Hey while we are on the topic of efficiency and the OP not knowing that division was slower... Often times in DSP you'll use circular buffers (like for delay buffers for instance). Those are often implemented by having an array, and an index into the array for where the next sample should go. When you put a sample into the buffer, you increment the index and then make sure that if the index into the array is out of bounds, that it gets set back to zero so that it continually goes through the array in a circular fashion (thus the name circular buffer!). Incrementing the index could be implemented like this: index = index + 1; if (index = count) index = 0; Another, more compact way could be to do it this way: index = (index + 1) % count; In that last one, it uses the modulo operator to get the remainder of a division to make sure the index is within range. The modulo operator has to pay the full cost of the divide though to figure out the remainder so it is the same cost as a division (talked about earlier!). There's a neat technique to do this faster that I have to admit i got from Ross's code a few years ago in his audio library PortAudio. That technique requires that your circular buffer is a power of 2, but so long as that is true, you can do an AND to get the remainder of the division. AND is super fast (even faster than the if / set) so it's a great improvement. How you do that looks like the below, assuming that your circular buffer is 1024 samples large: index = ((index + 1) 1023); // 1023 is just 1024-1 if your buffer was 256 samples large it would look like this: index = ((index + 1) 255); // 255 is just 256 - 1 Super useful trick so wanted to share it with ya (: On Sat, Mar 9, 2013 at 12:14 PM, Tim Goetze t...@quitte.de wrote: [Tim Blechmann] Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. not necessarily: in floating point math a/b and a * (1/b) do not yield the same result. therefore the compile should not optimize this, unless explicitly asked to do so (-freciprocal-math) I should have added, when employing the usual suspects, -ffast-math -O6 etc, as you usually would when compiling DSP code. Sorry! Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
On 10/03/2013 7:01 AM, Tim Goetze wrote: [robert bristow-johnson] On 3/9/13 1:31 PM, Wen Xue wrote: I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. there are some awful crappy compilers out there. even ones that start from gnu and somehow become a product sold for use with some DSP. Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. I don't think this has anything to do with crappy compilers Unless multiplication by reciprocal gives exactly the same result -- with the same precision and the same rounding behavior and the same denormal behavior etc then it would be *incorrect* to automatically replace division by multiplicaiton by reciprocal. So I think it's more a case of conformant compilers, not crappy compilers. I have always assumed that it is not (in general) valid for the compiler to automatically perform the replacement; and the ony reason we can get away with it is because we make certain simplifying assumptions. Ross. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
