[Stk] problems implementing polyphony...

Tue Sep 18 08:41:22 PDT 2012

I did some of my own experimentation, which seems to point to method calls
themselves (even with all of the calculation inside them commented out)
being responsible for much of the cpu use of HevyMetl.

I've been using STK all along with the assumption that all calls to tick()
without frames, or any other per-sample function call was going to be
significantly less efficient than operating on buffers. I'm aware of
the existence of inlining, but not savvy enough to understand if it's
happening or not, and under what conditions it can happen. It seems
suspicious to me to think that inlining could happen on pointers. I mean,
if you have a pointer to an stk::Generator, and you call tick() on it, I
don't see how the compiler could know ahead of time which subclass of
Generator it should be inlining.

I'd love to find out that all my meticulous buffer passing in order to get
reasonably performant code is unnecessary, but until I understand
otherwise, or better, I'm working with the assumption that method calls are
expensive and best to minimize. Another thing I like about calculating
samples in batches/buffers/stkframes is it allows me to use
Apple's accelerate framework, which offers some very nice performance
boosts.

However, I certainly trust Gary's assertion that this HevyMetl ran just
fine on 90's machines, and I'm very curious about what has changed. Has the
code itself changed, breaking inlining? Is there something about method
calls on the Apple hardware that makes them much more expensive than on
Gary's 90's hardware?

>From a place of great ignorance and curiosity.

-Morgan

On Tue, Sep 18, 2012 at 11:07 AM, Stephen Sinclair <sinclair at music.mcgill.ca
> wrote:

> I also messed around a little with a program used to time a bunch of
> calls to HevyMetl::tick().  It was indeed slower than e.g. Clarinet.
> I couldn't get to the bottom of it, but for what it's worth removing
> the calls to setFrequency() made it about twice as fast.  Removing
> those and all calls to tick() (for ADSR and wave objects) made it like
> 10 times faster.
>
> Not sure why this stuff would be slow, as I traced through and
> couldn't find an unexpected amount of indirections and virtual calls.
> I had a quick look at assembly output to see about inlining but had
> trouble immediately making sense of it.  I think there were some
> "call" instructions in there, but it didn't seem like a lot of them.
> I would want to step through the assembly with a debugger but don't
> really have time for that right now.
>
> I played around with removing the std::vectors, and also removing the
> indirection of the arrays (e.g. making them arrays of ADSR instead of
> ADSR*), and also using link-time optimisation, none of which seems to
> really help.
>
> Steve
>
> On Tue, Sep 18, 2012 at 10:39 AM, Tristan Matthews
> <le.businessman at gmail.com> wrote:
> > 2012/9/17 Rumi Humphrey <rumi at refresh.vu>:
> >> I think you can get your (modified for momu) FM class to compile if you
> >> comment out this line in FM.h:
> >>
> >> virtual StkFrames& tick( StkFrames& frames, unsigned int channel = 0 )
> = 0;
> >>
> >> I'm not exactly sure why that is or how to use tick with frames i think
> the
> >> MoMu version of STK might implement it differently or something.
> >>
> >> Unfortunately though doing this and using arrays instead of vectors
> didn't
> >> seem to help performance that much at least not on my ipod touch. I'm
> still
> >> only able to get one voice to play using HevyMetl.
> >
> > How does your hardware handle denormal floats? The FM class contains a
> > TwoZero filter,
> > which I believe can lead to denormals. You could try adding a small DC
> > offset the samples
> > before they are input to the TwoZero filter.
> >
> > This article has some background, as well as how to test denormal
> > computation on your hardware:
> >
> http://stackoverflow.com/questions/9350810/denormalized-floating-point-in-objective-c
> >
> > The only other thing I might try is changing StkFloat from double to
> float.
> >
> > Best,
> > Tristan
> >
> >>
> >> On Sep 17, 2012, at 7:27 PM, Patrick J. Collins wrote:
> >>
> >> Hmmm..  So after I put replaced the FM files with those two that you
> >> provided, building failed first because of:
> >>  #include "SKINI.msg"
> >>
> >> Claiming that file was not found...  I changed it to what it was
> >> previously:
> >>
> >>  #include "Skini_msg.h"
> >>
> >> Then the .cp failed with:
> >>        if ( nOperators_ == 0 ) {
> >>            oStream_ << "FM::FM: Number of operators must be greater than
> >> zero!";
> >>            handleError( StkError::FUNCTION_ARGUMENT );
> >>        }
> >>
> >> Saying "use of undeclared identifier oStream_"...  So I changed that to
> >> errorString_ as it was before...
> >>
> >> Then finally after doing that, the build fails at a point in my own code
> >> where I am doing:
> >>
> >>  // in my .h:
> >>    HevyMetl *instrument[4];
> >>
> >>  // in my .mm:
> >>    voicer = new Voicer();
> >>    instrument[0] = new HevyMetl();
> >>    instrument[1] = new HevyMetl();
> >>    voicer->addInstrument(instrument[0]);
> >>    voicer->addInstrument(instrument[1]);
> >>    voicer->silence();
> >>
> >> ...  It's failing at "new HevyMetl()" saying "Allocating an object of
> >> abstract class type 'HevyMetl'"...
> >>
> >> Patrick J. Collins
> >> http://collinatorstudios.com
> >>
> >> _______________________________________________
> >> Stk mailing list
> >> Stk at ccrma.stanford.edu
> >> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
> >>
> >>
> >>
> >> _______________________________________________
> >> Stk mailing list
> >> Stk at ccrma.stanford.edu
> >> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
> >>
> >
> >
> >
> > --
> > Tristan Matthews
> > web: http://tristanswork.blogspot.com
> >
> > _______________________________________________
> > Stk mailing list
> > Stk at ccrma.stanford.edu
> > http://ccrma-mail.stanford.edu/mailman/listinfo/stk
> >
> >
>
> _______________________________________________
> Stk mailing list
> Stk at ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/stk
>

-- 
===============
Morgan Packard
cell: (720) 891-0122
aim: mpackardatwork
twitter: @morganpackard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ccrma-mail.stanford.edu/pipermail/stk/attachments/20120918/a722b8da/attachment.html 