I'd love to see a performance-oriented, pure C++ synthesis library come to prominence. STK gets partway there, with the inclusion of the vectorized tick method, but in order to be performant and highly modular, parameter setting needs to be vectorized as well. I've taken steps toward this goal with my EZPlug wrapper for STK. In my own code, I use a sine oscillator which can take an stk::generator as a frequency input. <div>
<br></div><div><a href="https://github.com/morganpackard/EZPlug/blob/master/EZPlug/EZPlugGenerators/SineWaveMod.h">https://github.com/morganpackard/EZPlug/blob/master/EZPlug/EZPlugGenerators/SineWaveMod.h</a></div><div><br>
</div><div>This way, I can work at a bit of a higher level, more "patching style", but without having the added layer of complexity and obfuscation that would come with using PD. Creating an efficient FM synth becomes a matter of just patching together the right sine waves and helper generators (Multiplier, Adder, FixedValue).</div>
<div><br></div><div>-Morgan</div><div><br><div class="gmail_quote">On Tue, Sep 18, 2012 at 6:37 PM, 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">This is difficult. I have been playing with the code and gcc options<br>
and gprof, and it seems there is no specific bottleneck. HevyMetl is<br>
about 15% the speed of Clarinet. I managed to get it down to about<br>
the same speed, but I had to do several things:<br>
<br>
- moved several functions into their headers for inlining<br>
(FileLoop::setRate, FileWvIn::tick, etc.. anything that is referenced<br>
from HevyMetl::tick.)<br>
<br>
- set some gcc options to force inlining of as much as possible,<br>
e.g. -Winline --param inline-unit-growth=65536 -finline-limit=65536<br>
<br>
- used link-time optimisation available in gcc 3.6 and up (-flto on all code)<br>
<br>
- set -ffast-math<br>
<br>
Even then it is not quite as fast. I found fmod used in FileLoop was<br>
a bit of a bottleneck.<br>
<br>
In general I find it pretty surprising that gcc doesn't succeed in<br>
speeding this up more, but FileLoop seems to be a bit of a problem for<br>
reasons that aren't clear to me. I sprinkled the code with checks for<br>
denormals and came up empty. I checked the assembler and used gprof<br>
and -Winline to make sure inlining was working as expected.<br>
<br>
Oh, I should mention this was on my fast desktop computer, not an ARM<br>
tablet, so proper profiling on the target hardware may be warranted.<br>
<br>
In any case, Morgan's right in that the vectorised versions are<br>
probably better to use "in production," since the whole "inline" thing<br>
in C/C++ is not supposed to be fully relied on for efficiency. (e.g.<br>
the compiler might choose not to inline due to code size rather than<br>
speed.) The per-sample tick functions are however important for<br>
certain algorithms, and generally useful as a teaching tool, so their<br>
presence in STK is desirable. That said, usually a vectorised<br>
approach is preferred in application code.<br>
<br>
Just a couple of notes...<br>
<div class="im"><br>
<br>
On Tue, Sep 18, 2012 at 11:41 AM, Morgan Packard<br>
<<a href="mailto:morgan@morganpackard.com">morgan@morganpackard.com</a>> wrote:<br>
> I did some of my own experimentation, which seems to point to method calls<br>
> themselves (even with all of the calculation inside them commented out)<br>
> being responsible for much of the cpu use of HevyMetl.<br>
><br>
> I've been using STK all along with the assumption that all calls to tick()<br>
> without frames, or any other per-sample function call was going to be<br>
> significantly less efficient than operating on buffers. I'm aware of the<br>
> existence of inlining, but not savvy enough to understand if it's happening<br>
> or not, and under what conditions it can happen. It seems suspicious to me<br>
> to think that inlining could happen on pointers. I mean, if you have a<br>
> pointer to an stk::Generator, and you call tick() on it, I don't see how the<br>
> compiler could know ahead of time which subclass of Generator it should be<br>
> inlining.<br>
<br>
</div>That's true, but most STK code uses the final child class, not the<br>
superclass, so the compiler should have all the information it needs.<br>
<div class="im"><br>
> I'd love to find out that all my meticulous buffer passing in order to get<br>
> reasonably performant code is unnecessary, but until I understand otherwise,<br>
> or better, I'm working with the assumption that method calls are expensive<br>
> and best to minimize. Another thing I like about calculating samples in<br>
> batches/buffers/stkframes is it allows me to use Apple's accelerate<br>
> framework, which offers some very nice performance boosts.<br>
><br>
> However, I certainly trust Gary's assertion that this HevyMetl ran just fine<br>
> on 90's machines, and I'm very curious about what has changed. Has the code<br>
> itself changed, breaking inlining? Is there something about method calls on<br>
> the Apple hardware that makes them much more expensive than on Gary's 90's<br>
> hardware?<br>
<br>
</div>I think one experiment would be to compare run-times of<br>
HevyMetl::tick() for previous versions of STK. My meticulous building<br>
of a git archive of the previous tarballs might finally pay off!<br>
<br>
<a href="https://github.com/radarsat1/stk/commits/upstream" target="_blank">https://github.com/radarsat1/stk/commits/upstream</a><br>
<br>
If a really old version does turn out to be faster, I was thinking<br>
maybe a well-crafted "git bisect" command might help get to the bottom<br>
of this.<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><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>