[Clam-devel] clam and max

[Pau Arumí]

On dj, 2008-01-31 at 01:00 +0100, David García Garzón wrote:
> 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.

then a serious assessment of that is in order. agree? 

could we use valgrind to trace the alloc system calls? then it would be
matter of collecting the results occurred only during the running phase
of all our functional tests.

i think to remember that efficientyguardian already implementes that
kind of "start counting" "end counting". you'll know better if it might
be usefull.

pau


> 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
> 
> 
>