Comparing gen and Reaktor core level

Without getting into details, the most important difference is that Gen is actually generating and compiling source code from the Gen patcher. This means that a gen~ object functions within your patch like a compiled C object, although you can always open up the Gen patcher to alter the code. As you make changes, Gen recompiles the source code in place (assuming Auto-Compile is on). Using the codebox in Gen, you can also integrate text-based procedural code and expressions with visual programming.

Hi Ernest,

Regarding performance:

For MSP, you will see large gains if you are using many simple objects in MSP to perform some task. So the same thing that you might be motivated to program an external object in C in order to get good performance. You won't see better performance than making your external object in C, but it will be quite close to that.

The basic rule of thumb, is that when you would be using a similar number of objects to accomplish the same task in MSP or Gen, the performance will be dramatically higher (e.g. 3-10x faster at 64 sample signal vector, and much more as the signal vector decreases).

In practice, you might be using only a handful of high level objects in MSP, in which case, you may not find any performance benefit to using Gen.

This latter case is probably similar to what you are describing--i.e. why in practice, most of the things you were doing in Reaktor didn't benefit from using Core. Typically, Reaktor programming is focused on high level objects, which are already compiled in C as a single unit. In MSP, there is much more of a low-level programming tradition, and therefore more of the former case, and I think for that reason, it will be of more benefit to MSP users.

For Jitter, if you use jit.gl.pix, you will see huge performance gains over using jit.op or other objects on the CPU. Similar to the above, however, you will not get much better performance than doing the equivalent in your own GLSL shader code.

We'll be working on the documentation and information surrounding Gen to make a variety of things clearer of when and why you might want to use Gen, but here's a short list:

General:
- You want to program visually at a low level while getting the performance of compiled C or GLSL code
- You want to use a concise text based expression language (codebox) rather than visual programming or coding in GLSL
- You want to avoid having to compile separate windows and macintosh versions (and in the future, 64-bit application binaries)

MSP:
- You want single sample feedback for things like building your own filters, FM synths, physical modeling, etc.)

Jitter:
- You want to be able to have a simple way to make use of the GPU for image processing both in visual and textual form

In the future:
- You want to program visually and get output as source code for use in other programs which you are working on as a developer

I hope this helps clarify a few things. We will be posting some examples which demonstrate some of the things I describe soon.

-Joshua

Here's a really quick and dirty benchmarking example.

To demonstrate gen as faster than using many low level MSP operators:

benchmark-example-msp.maxpat ~47% cpu in minimixer
benchmark-example-gen.maxpat ~9% cpu in minimixer

So roughly 5x faster at 64 sample signal vector size. This is a pretty synthetic benchmark, but hopefully it illustrates the point of when and around what amount of improvements you might be able to achieve.

To demonstrate that gen~ is close to as fast as compiled C code, here's 512 biquads in Gen vs. MSP.

biquad-bench-msp.maxpat: ~19%
biquad-bench-gen.maxpat: ~22%

So it's only ~15% slower than the equivalent compiled C code for biquad~. This is a small network and a relatively simple MSP object, each with many instances. As the gen patcher and corresponding MSP object becomes more complex, the benefit should improve. And since the code is being generated, this can get better as we improve the system.

This should demonstrate that building something in gen~ is close to the as efficient as the equivalent compiled C code.

We can work on more examples of these sorts of things as time goes on, but hopefully this answers some of the questions you raise.

-Joshua

Thanks, it becomes to be clear for me, now.

Keep going, please. Really helpful.

Yes, thank you, those are really interesting answers.

On of the main problems for core-level performance in Reaktor is 'domain conversion' when transferring data between primary and core level. Is there a similar cost to signal movement in and out of core, that is, there are greater perofmrrance gains with lower I/O counts to gen?

How are gen~ objects disabled so they don't consume any CPU? How much overhead is there when a gen~ object is in some form of disabled state?

Architecturally the specifics are significant in many cases, for instance, whether to get performance improvement by building one multiple-ouput oscillator sharing one ramp, or whether to build one ramp in one gen~ unit, and disable different shapers on the ramp output for different oscillator waveforms.

I'm also curious about oversampling in gen, whether it requires separate objects, or whether oversampling is accomplished within the gen unit. Would you have any insight on that?

Super brief answers:

- disabling objects is similar to other msp objects. Rare occurrence but possible, and not much overhead when the case.

- migrating data into gen has relatively minimal overhead.

- oversampling in gen is not present yet, but we will add it soon. For now wrap in poly~ for oversampling.

What about wrapping gen inside pfft? Can we wrap pfft inside poly and gen inside pfft? =D

Also, what about some kind of way of making it easy to create kind of subpatches inside gen? This would be great considering that a lot of low level code easily gets really messy... Perhaps named busses like in core could be used to tidy up structures (not having loads of cables when routing one source to many destinations).

Also, when playing around with codebox I found that the for word was colorized, is this something you're planning on implementing?

- pfft~? Yes. See spectral delay example.

- subpatchers? Not in first release, but soon.

- for loops? Also soon.

thanks a lot to Joshua for his great answers.

One amazing thing (among others):

In the future:
- You want to program visually and get output as source code for use in other programs which you are working on as a developer

Currently writing a little paper here:
http://designthemedia.com/blog

More about gen~
- what do you mean by "concise text based expression language (codebox) " ?
- I often use JS instead of big max patch architecture tricky parts. can I put js inside gen~? does it make sense ? js isn't compiled. but could I expect improvements with gen~ ?