CPU Usage on Static Patches

OWL Firmware
#1

Hi,

I noticed that a patch that uses for example 25% of the cpu, in static mode (uploading inside the firmware) uses more than 100%. I suppose it has something to do with memory fetching. Is there a way to improve this?

#2

So it runs slower compiled with OwlWare than uploaded with OwlProgram? Master branch?

It is probably because key memory sections have ended up on the heap, ie external RAM.

Looking at the code, it seems that the Patch object is created on the heap (FactoryPatches.cpp:25).

If you don’t need the external RAM you can change line 24 to
sram_init((char*)PATCHRAM, 1024*1024);

This sets up 64kB of internal ram as heap.

Come to think of it, are you compiling in debug mode? Try with make CONFIG=Release and see if it doesn’t speed things up!

#3

Yeap, master branch. I didn’t touch the Makefile.

I’ll play with those two thing and see what happen.

#4

I was in deed compiling the Debug version. make CONFIG=Release improved the performance.
In fact, now the static patches consume less CPU.

#5

I’ve pushed a branch memmathperf to OwlProgram which can improve performance by several times on dynamically loaded patches.

It does this in two ways:

  • fast approximate math functions for powf(), atan2f() and expf() (in addition to already optimised trigs and sqrt)
  • multiple heap areas uses available CCM and PATCHRAM for small objects

Additionally, for PD patches the dependences on printf and malloc have been removed which reduces program size by quite a bit, allowing bigger, more complex patches to be compiled.

To try it out, simply check out the branch in OwlProgram and recompile your patches (only for offline compilation at this point).

#6

I think something is wrong with the [pow~] object. I don’t know if it is because this update. I’m having problems with the master branch as well.

This patch:
https://hoxtonowl.com/patch-library/patch/Filtremolo/
no longer works. The output of [pow~] is 0 so the filter cutoff is at 0Hz. The last time I pulled the repository was on the 21st of February so one of the last 9 commits is the culprit.

#7

Yes you are right, the fastpowf() function seems to mess it up.
I’ve disabled it in both branches.

#8

Would be nice to implement this scheme:
http://www.hxa.name/articles/content/fast-pow-adjustable_hxa7241_2007.html
along with a test suite to ensure accuracy and measure performance gains…

edit: it’s now on the todo list!

#9

I’ve pushed the performance updates to the master branch and deployed to the online compiler. This can lead to major performance improvements, e.g. GVerb is now running at 36% instead of 96% of CPU.

The improvements work by offloading critical memory sections to fast, internal RAM.

The heap is now using parts of the internal memory (CCM and SRAM) as well as the large (but comparatively slow) external memory. To make the most of it, allocate any frequently used segments early on in the patch constructor. Anything that is too large to fit internal will be allocated to external RAM.

If you have any problems, like patches that used to work but work no longer, let me know!