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