[Clam-devel] clam and max

Pau Arumí parumi at iua.upf.edu
Wed Jan 30 15:37:53 PST 2008


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. 

pau


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?
> 
> Cheers,
> 
> Xavier
> 
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel





More information about the clam-devel mailing list