Comparing compiled patches from PD versus from Gen here.
A simple double head pitching tape delay in mono reads
130% CPU from PD, but only
19% CPU from Gen.
The .syx code compiled from the PD patch is about 3 times larger, than the compiled Gen code.
Obviously the gen patch works well on the OWL pedal, whereas the PD code makes the unit stall.
Anybody else with such or contradicting experience?
I noticed that some old patches don’t work anymore due to efficiency problems. For example this patch:
https://hoxtonowl.com/patch-library/patch/Filtremolo
It used to run at 61% CPU but if you compile it now you’ll get around 125% CPU usage.
Yes i had the same problem since V12 and actually didn’t care to update the patches yet. Martin had announced for a fix last year, but i haven’t seen any yet. Some of the work can probably be translated to gen. Unfortunately i am too much a novice in C++ to attempt it there.
Another patch i worked on which is here now is a broken fuzz.
Again i originally did this in PD, but then switched to gen for CPU efficiency reasons.
PD 120& CPU
GEN 20% CPU
I suspect that the heavy compiler has issues, or, even worse, Pure Data already has issues there. I will address that on the PD mailing list for a start.
are you using pd subroutines? I found recently using pd~ helped me with several FFT/PV patches over on the organelle
perhaps worth looking into
pp
Patrick, actually i didn’t, as pd~ is not on the list of supported objects of the Heavy compiler.
Worth a try, nonetheless. The Organelle uses libpd, no?
Asking, because i also use a Bela, and for that platform official statements indicate, that libpd there runs slower, than Heavy-compiled code. I haven’t tried it, though, again for limited PD object set in Heavy.
My patches get CPU-intense all too soon,
so where’s actual truth about absolute speeds/code efficiency there?
It is quite possible that some fast-math procedures currently used in Gen compilations is skewing the results in favour of Gen.
If your patch uses exp then currently the Gen implementation is using a very crude, but fast, approximation (see discussion elsewhere [1]). The Pd version uses the math.h implementation, which is slow but accurate.
We have an accurate and fast implementation in the works which we can use for both Gen and Pd. However it requires flash storage to deal with some fairly large tables, and is therefore stuck waiting in the todo list… Oh, dependencies!
[1] https://hoxtonowl.com/forums/topic/gen-sample-rate-problem/
@patrickpagano forgot to mention, that PDs fft objects are also not supported… and there isn’t a way to use fft in gen as well, as the relevant msp objects are outside the gen object. Gen works per sample, so sampling a window for further processing is the first task to solve, besides there isn’t any way further inside a gen object yet.