CPU Usage on Static Patches

Home Forums OWL OwlWare CPU Usage on Static Patches

This topic contains 8 replies, has 2 voices, and was last updated by  Martin Klang 1 year, 9 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #2258

    JoseFuzzNo
    Participant

    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?

    #2259

    Martin Klang
    Keymaster

    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!

    #2260

    JoseFuzzNo
    Participant

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

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

    #2261

    JoseFuzzNo
    Participant

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

    #2262

    Martin Klang
    Keymaster

    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).

    #2263

    JoseFuzzNo
    Participant

    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.

    #2264

    Martin Klang
    Keymaster

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

    #2265

    Martin Klang
    Keymaster

    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!
    https://github.com/pingdynasty/OwlProgram/issues/36

    #2267

    Martin Klang
    Keymaster

    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!

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.


Latest News

Links

Follow us on Twitter