Francesco Cameli

I have noticed that the CPU usage for exported gen code is way more than the one used by the gen~ object. Specifically, referring to the example retrieved from https://github.com/Cycling74/gen-plugin-export, I have a CPU usage of around 14% with the vst version, while not more than 5% with the gen~ one. Why is that the case? Is the code used by the embedded gen~ somewhat different from the exported one? What sort of optimization is going under the hood? Is there something that gen~ programmers should pay attention to when exporting, in order to achieve similar CPU performances between gen~ and the exported code?

Hello everyone,
I have noticed that the CPU usage for exported gen code is way more than the one used by the gen~ object. Specifically, referring to the example retrieved from https://github.com/Cycling74/gen-plugin-export, I have a CPU usage of around 14% with the vst version, while not more than 5% with the gen~ one.  Why is that the case? Is the code used by the embedded gen~ somewhat different from the exported one? What sort of optimization is going under the hood? Is there something that gen~ programmers should pay attention to when exporting, in order to achieve similar CPU performances between gen~ and the exported code?

Hello everyone,
I have noticed that the CPU usage for exported gen code is way more than the one used by the gen~ object. Specifically, refe

cpu-usage-when-exporting-gen-code

I'd think the difference could be caused at least to some extend by the different host programs the code is running inside when exported as a plugin. Even when exporting it as pluging and running it in Max with [vst~] there should be still an aditional layer wrapped around.... But would be interesting to hear a well informed opinion.

I'd think the difference could be caused at least to some extend by the different host programs the code is running inside when exported as a plugin.  Even when exporting it as pluging and running it in Max with [vst~] there should be still an aditional layer wrapped around.... But would be interesting to hear a well informed opinion.


I was expecting a performance drop caused by the additional layers of different APIs such as the vst one, but 10% more seems quite a big hit. Also, I have noticed that the main CPU problems are caused when exporting gen code that uses delays. Let's see if someone at Cycling'74 can tell us something more about this issue.

I was expecting a performance drop caused by the additional layers  of different APIs such as the vst one,  but 10% more seems quite a big hit. Also, I have noticed that the main CPU problems are caused when exporting gen code that uses delays.  Let's see if someone at Cycling'74 can tell us something more about this issue.

There is too redundant code in gen export , you can go through the .cpp and "simplify".

interpolation, for example you may find that several readings or data writes can use a single control of (wrap, clip etc) boundaries.

There are operations and functions that in certain cases are exported without recognizing that they could be used or constants or make a calculation only at the beginning.

And use what is already defined as a fast function, or look for things like ex.:

https://www.codeproject.com/Articles/69941/Best-Square-Root-Method-Algorithm-Function-

There is too redundant code in  gen export , you can go through the .cpp and "simplify".
 interpolation, for example you may find that several readings or data writes can use a single control of (wrap, clip etc) boundaries.
There are operations and functions that in certain cases are exported without recognizing that they could be used or constants or make a calculation only at the beginning.
And use what is already defined as a fast function, or look for things like ex.:

https://www.codeproject.com/Articles/69941/Best-Square-Root-Method-Algorithm-Function- 

I have managed to reduce the cpu usage by simplifying the .cpp code, but I found myself actually changing it for the most part. In my opinion, the case of modifying parts of gen exported code is kind of a huge drawback, as I mostly use gen to avoid writing strict c++ code. My question is specifically related to what makes the gen exported code different from the embedded gen object one. Isn't the object compiling the same code that is exported with the exportcode message?

I have managed to reduce the cpu usage by simplifying the .cpp code, but I found myself actually changing it for the most part.  In my opinion, the case of modifying parts of gen exported code is kind of a huge drawback, as I mostly use gen  to avoid writing strict c++ code.  My question is specifically related to what makes the gen exported code different from the embedded gen object one. Isn't the object compiling the same code that is exported with the exportcode message?

this is a complex topic, and hopefully a real expert like graham can chime in soon with better explanations.

in the mean time i wanted to point out some problems with what has been said.

first of all, the code generated whilst patching in gen~ is identical to the c++ you get on codeexport. issues may arise with the environment in which you wrap it, as that environment will not be optimised for hosting gen exported code (unless cycling have been involved, such as the optimised owl pedal and mod duo pedal work). juce is great, but slow and full of bloat. i have also had massive cpu increase compiling vst's with no additional optimisation in juce. however i have had much better results working hard on the wrapping and comipling via iplug. note, this is not a scientific study, i may be at fault here.

secondly, modifying your exported code sort of completely defeats the purpose of writing in gen~ in the first place, no? i mean you might as well be writing straight into c++.

gen~ has no vectorisation or arrays. no access to integer maths or assembler. crucially, gen~ is a 'perform loop', always on 64bit doubles. once you understand that, a great deal of optimisation can be done in gen with audio rate / param rate separation, etc.

@arabrab, citing sqrt newton recursion style approximations is totally worthless for gen users. this specific algo does not produce speed improvements in gen. in fact it costs about double to the time of a native sqrt(), as sqrt is a single native instruction set on intel, and gen cannot compete with its 64bit doubles environment doing this sort of approximation. you really need to cite empirical evidence if you are to make such suggestions.

also, whilst the exported gen lib that comes with your exported file lists all gen methods, they do not get used if not called. actually all the gen lib is remarkably fast for what it is. the error is usually user error (e.g. using a native 8th order taylor series sine for an lfo that could be easily approximated even in gen 64bit doubles environment).

i agree there could be big improvements to gen (i am looking forward to possibility of preprocessor scripts). But compared to similar environments such as Faust, the cpu usage is comparable for jit-compiled perform loops (in initial Faust you cannot even if/else block for cpu management, which of course we can do in gen).

i made one commercial plugin using codeexport, and got cpu lower in VST/AU format than in native gen~ format. however, making commercial stuff is not easy - you have to write in a special way to make sure resets / etc will work properly.

this is a complex topic, and hopefully a real expert like graham can chime in soon with better explanations.
in the mean time i wanted to point out some problems with what has been said.
first of all, the code generated whilst patching in gen~ is identical to the c++ you get on codeexport. issues may arise with the environment in which you wrap it, as that environment will not be optimised for hosting gen exported code (unless cycling have been involved, such as the optimised owl pedal and mod duo pedal work). juce is great, but slow and full of bloat. i have also had massive cpu increase compiling vst's with no additional optimisation in juce. however i have had much better results working hard on the wrapping and comipling via iplug. note, this is not a scientific study, i may be at fault here.
secondly, modifying your exported code sort of completely defeats the purpose of writing in gen~ in the first place, no? i mean you might as well be writing straight into c++.
gen~ has no vectorisation or arrays. no access to integer maths or assembler. crucially, gen~ is a 'perform loop', always on 64bit doubles. once you understand that, a great deal of optimisation can be done in gen with audio rate / param rate separation, etc.
@arabrab, citing sqrt newton recursion style approximations is totally worthless for gen users. this specific algo does not produce speed improvements in gen. in fact it costs about double to the time of a native sqrt(), as sqrt is a single native instruction set on intel, and gen cannot compete with its 64bit doubles environment doing this sort of approximation. you really need to cite empirical evidence if you are to make such suggestions.
also, whilst the exported gen lib that comes with your exported file lists all gen methods, they do not get used if not called. actually all the gen lib is remarkably fast for what it is. the error is usually user error (e.g. using a native 8th order taylor series sine for an lfo that could be easily approximated even in gen 64bit doubles environment).
i agree there could be big improvements to gen (i am looking forward to possibility of preprocessor scripts). But compared to similar environments such as Faust, the cpu usage is comparable for jit-compiled perform loops (in initial Faust you cannot even if/else block for cpu management, which of course we can do in gen).
i made one commercial plugin using codeexport, and got cpu lower in VST/AU format than in native gen~ format. however, making commercial stuff is not easy - you have to write in a special way to make sure resets / etc will work properly.


I gave an example, any that I found, as an example for that purpose, of what I was referring to, not to use Taylor's approximations and even commented code, because the last time I referred to the genlib content there was a bit of tension.

"Secondly, modifying your exported code sort of completely defeats the purpose of writing in gen-in the first place, not mean you might as well be writing straight into c ++."

To me it may be useful to prototype some times, and others maybe make some modifications and use that code ...

I gave an example, any that I found, as an example for that purpose, of what I was referring to, not to use Taylor's approximations and even commented code, because the last time I referred to the genlib content there was a bit of tension.
 

"Secondly, modifying your exported code sort of completely defeats the purpose of writing in gen-in the first place, not mean you might as well be writing straight into c ++."
 

"secondly, modifying your exported code sort of completely defeats the purpose of writing in gen~ in the first place, no? i mean you might as well be writing straight into c++. " 

I couldn't agree more, as I also stated before in a previous answer. 

I would also like to underline the problem with the cpu usage of delays and datas with gen exported code. In my case, when exporting gen code with no use of data/delay/buffer to other environments, the CPU usage is fine in most cases. I managed to successfully use exported gen code to build a SuperCollider UGen out of this brilliant Lockhart Wavefolder gen patch:

http://smc2017.aalto.fi/media/materials/proceedings/SMC17_p336.pdf?fref=gc

http://research.spa.aalto.fi/publications/papers/smc17-wavefolder/?fref=gc

The CPU usage was almost identical both in gen and in the built SuperCollider UGen. 

On the other hand, my ported SC UGen of the gen creepyverb example has the same limitations as the provided VST export example. The CPU usage in SC was more than double the one of gen. At first, I thought this was caused by my use of the SC API's method of memory allocation for the buffers needed for the delays, but when I built the same example as VST using JUCE (and the standard genlib memory allocation), the same CPU problems occurred (Actually, the VST version was even more computationally expensive). Let's wait for better explanations from people at Cycling '74.

"secondly, modifying your exported code sort of completely defeats the purpose of writing in gen~ in the first place, no? i mean you might as well be writing straight into c++. " 
I couldn't agree more, as I also stated before in a previous answer. 

I would also like to underline the problem with the cpu usage of delays and datas with gen exported code. In my case,  when exporting gen code with no use of data/delay/buffer to other environments, the CPU usage is fine in most cases. I managed to successfully use exported gen code to build a SuperCollider UGen out of this brilliant Lockhart Wavefolder gen patch: 

http://research.spa.aalto.fi/publications/papers/smc17-wavefolder/?fref=gc

The CPU usage was almost identical both in gen and in the built SuperCollider UGen. 
On the other hand, my ported SC UGen of the gen creepyverb example has the same limitations as the provided VST export example. The CPU usage in SC  was more than double the one of gen. At first, I thought this was caused by my use of the SC API's method of memory allocation for the buffers needed for the delays, but when I built the same example as VST using JUCE (and the standard genlib memory allocation), the same CPU problems occurred (Actually, the VST version was even more computationally expensive). Let's wait for better explanations from people at Cycling '74.

does anyone have any information about this topic?

@Cycling '74, 
does anyone have any information about this topic? 

(Sorry, I hate to "up" a post, but I am in the middle of developing some software that relies on this topic)

up

(Sorry, I hate to "up" a post, but I am in the middle of developing some software that relies on this topic)

Let me bump this topic again. I'm using data and delay operators in a reverb patch for the Mod Duo and also see an increase of 10% in cpu. Any way to minimize the cpu?

Let me bump this topic again. I'm using data and delay operators in a reverb patch for the Mod Duo and also see an increase of 10% in cpu.  Any way to minimize the cpu?

CPU usage with exported gen code