[PD] what makes Pd-extended 0.43 so CPU-hungry?

[katja]

On Tue, Dec 11, 2012 at 8:58 PM, Hans-Christoph Steiner <hans at at.or.at> wrote:

> I added optimization flags to the GNU/Linux and Windows builds:
>
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=16655
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=16656
> http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revision=16657
>

Installed the latest build for Debian Squeeze today. Very happy to see
that optimization is working again for all libs. CPU loads are back to
normal. Probably freeverb~ was the main victim of non-optimization,
with a couple hundred function calls in the perform loop, functions
which are supposed to be inlined. The object was almost ten times more
expensive with all those function calls. And it was just coincidence
that my live setups have four instances of freeverb~ each. Otherwise I
might not have noticed the issue at all.

> I just remembered one issue: one thing that makes it tricky to set optimization flags for all of Pd-extended is the last few remaining type punning issues:
> http://autobuild.puredata.info/auto-build/2012-12-11/logs/type-punning-2012-12-11.txt
>
> I fixed a few recently. Want to try fixing bsaylor/svf~ or oscx?  As for 'extra', I think I'll include your pd-double fixes in the pd-extended 0.43 branch.

Yeah it's better to get rid of all the overt type punning so the
-fno-strict-aliasing need not be set. In bsaylor/svf~ is a type
punning method to avoid denormals, this could probably be replaced by
the PD_BIGORSMALL(). I'll check that.

Katja