[Clam-devel] clam and max

[David García Garzón]

That's exactly the problem, Pau. Some token objects do allocations on copy. I 
don't remember about DT's, but stl structures including strings do that 
unless you specify them a realtime pre-allocator and i think we are not doing 
that.

On Dijous 31 Gener 2008, 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.
>
> 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
>
> _______________________________________________
> Clam-devel mailing list
> Clam-devel at llistes.projectes.lafarga.org
> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel



-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080131/4a04f833/attachment-0001.sig>