[Clam-devel] clam and max
xavier at amatriain.net
Wed Jan 30 15:42:30 PST 2008
Yes, yes, I know... I am only saying that in Greg's original message he
*was* referring to copy constructors as "allocations" in the broader sense.
Pau Arumí wrote:
> xavier, i think this is quite missleading.
> copying data and data allocation are very different things when
> referring to real-time performance. the first takes a time proportional
> to the size copied *in worst case* while the second (alloc) is a
> blocking call that have no worst case bound (imagine when need to wait a
> disk swap to get new memory). so when doing allocations there is no 100%
> guaranty that we'll meet the (callback) deadline.
> On dj, 2008-01-31 at 00:22 +0100, Xavier Amatriain wrote:
>> Hi Greg, and thanks for taking some time to try this out and for
>> your valuable feedback. Some clarifications below...
>> Greg Kellum wrote:
>>> This is
>>> part of what makes Max fast. Max was for instance one of the first
>>> applications that were able to do a real time FFT on a desktop. (That
>>> was over ten years ago...)
>> First let me be clear: allocating during sound processing is a
>> bad practice. As a matter of fact in our first designs of CLAM this
>> was avoided at all costs. However soon we decided to favor
>> flexibility over efficiency. Besides, I have been profiling CLAM
>> long enough on several OS to know that allocations are not a
>> performance bottleneck in CLAM (except in very few cases where
>> that was solved). Things like trigonometric functions or bound
>> checking during loops, for instance, are much worse problems
>> in that sense.
>> As a matter of fact with my little experience in Max I can assure you
>> that you can do very inefficient things in Max, just like you can
>> do very efficient ones in CLAM ;-)
>> Also, saying that this is why Max was one of the first software to
>> run FFTs on a desktop is a bit of an overstatement. As far as I
>> know Miller Puckette did not implement an optimized version of
>> the FFT computation such as FFTW. These implementations are
>> the reason why 10 years ago people were able to do FFTs on a
>> desktop, not the fact that copies were avoided.
>>> Due to this constraint, I knew that it wouldn't be possible to run
>>> CLAM networks in Max. The networks are allocating new memory every
>>> time something is passed from one CLAM object to another over a
>>> network connection.
>> Again a network does not strive for efficiency but rather for
>> flexibility. Inplace processing is possible in CLAM but not using
>> Networks. So, yes, in a Network a Processing Object copies its
>> output onto the channel. Although this does not necessarily imply
>> an allocation (I think that in the Audio case it doesn't) it might
>> imply so when dealing with complex structures (those that Max
>> would not allow to pass anyway, right?).
>>> and Max was crashing
>>> in the middle of a call to an object's copy constructor where it was
>>> calling new.
>> I also wonder like David, how can that happen. Any idea if Pd also
>> implements this restriction and how it does it?
>> Clam-devel mailing list
>> Clam-devel at llistes.projectes.lafarga.org
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
More information about the clam-devel