| Thought has been given. However, in my experience Csound runs about 5 times faster with ksmps of 10 or more than with ksmps of 1. I wouldn't call that a minimal performance gain.
The basic cause of this performance difference appears to be mainly going into the innermost loop to compute ksmps samples and being able to keep all code and variables in local cache until the loop is done. If ksmps is 1, the inner loop exits immediately, and there is a cache hit to bring the outer loop code back into cache. This is of course an artifact of contemporary processor design, but it has been more or less like this for some time, and I don't expect it to change soon.
The same consideration applies to any DSP graph and for this reason, almost all software sound synthesis systems employ this distinction between control rate and audio rate. The only one I know of that does not is ChucK.
Regards,
Mike
-----Original Message-----
>From: Michael Bechard
>Sent: Jul 7, 2008 3:07 PM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Get rid of ksmps != 1? [WAS: Re: a-rate if]
>
>I've often kind of wondered about the many issues that arise from the whole ksmps issue. What should it be, how does it affect the sound, etc. So many opcodes now seem to operate best (sometimes only) if ksmps = 1, so has any thought been given to making future versions of CSound always have ksmps = 1, thereby basically making it go away altogether? I understand it's there and configurable for performance reasons, but the (often minimal) performance gains seem overshadowed by the confusion the distinction often causes. If ksmps always equalled one, then there really would be no need to distinguish between k and a-rate variables at all. It would simplify things immensely.
>
>Of course, I defer to the developers on this issue, and it would represent a fairly radical change. But it's at least an intriguing idea.
>
>Michael Bechard
>
>
>
>----- Original Message ----
>From: John Lato
>To: csound@lists.bath.ac.uk
>Sent: Monday, July 7, 2008 12:44:54 PM
>Subject: [Csnd] Re: a-rate if
>
>Joseph Sanger wrote:
>
>> 2. Is there another opcode which I've overlooked? Like the 'a' opcode,
>> but in reverse; something which simply copies the a-rate variable to
>> k-rate every ksmps, without averaging or finding the maximum.
>
>In general this isn't possible. Since an a-rate variable is an array of data (with
>length ksmps), it's clear that to convert from a-rate to k-rate you need some sort of
>aggregating function (e.g. calculate the average or maximum). In the special case of
>ksmps=1 aggregating is unnecessary, but both averaging and taking the maximum would
>return the same value then anyway, so it doesn't make any difference.
>
>I agree this can seem inelegant to many csound users, but if you think of how the
>orchestra is interpreted by csound it should be clear.
>
>>
>> 3. Is there any reason why 'if' can't be made to accept a-rate variables
>> in the (near!) future?
>>
>
>I can think of several. Again, understanding that an a-rate variable is really an
>array should make it clear. Csound operates at the k-rate. 'if' accepting a-rate
>variables only makes syntactic sense in the case of ksmps=1, all other values would
>mean creating separate execution paths within a single a-variable array. I doubt
>that could be implemented in any fashion that doesn't defeat the purpose of the
>k-rate (which means that ksmps=1 is what you really want anyway).
>
>Working at ksmps=1, I would use max_k as you are already. Downsamp and interp are
>other options.
>
>John W. Lato
>Sarah and Ernest Butler School of Music
>The University of Texas at Austin
>1 University Station E3100
>Austin, TX 78712-0435
>(512) 232-2090
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>
>
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
|