Initial review doesn’t make it obvious where gen is actually faster. We all hope the same isn’t true for Max 6 as for Reaktor. All of us. Partly it must be a matter of choosing when to use gen….

For what applications exactly does gen provide a real performance improvement?

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

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

Keep going, please. Really helpful.

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?

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

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?

- subpatchers? Not in first release, but soon.

- for loops? Also soon.

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~ ?

- re: the js or any other non gen object for source generation: no. There will not be support for exporting the other code for any non-gen max objects; only what is inside the gen objects. That doesn’t mean we couldn’t have some js code output from the gen patcher, but then you would need to add your other js code to the output somehow yourself after export. It’s still a while before that’s ready, and I won’t have time to answer lots of questions about functionality which doesn’t yet exist. Thanks for your patience in the meantime.

With the biquad example, on the other hand, Max 5 and Max 6 need roughly the same 27%…

I am puzzled…

Still the price for Max 6 seems at least 1000 Euro, as my patches which run fine in Max 5 do not run flawless anymore in Max 6 and I would need to buy a faster computer…
One patch doubles the CPU hit, the other is the same. They should both run with 64-bits as far as I know. It doesn’t explain that difference in the CPU hit, as I run both Maxversions on a 64-bit processor. I would expect a performance hit, but anything which is more than 10% is not worth the gain in sound quality…
I’d rather keep the existing sound quality, than being forced to a new computer which would have lost a normally expected performance boost right out of the box…

Don’t get me wrong, I love the new features and the overall advancement in the GUI, but the cost seem very high at the moment, and I can’t overcome it with gen~ alone. I wonder how close we get with the performance problems with the final version. I know the elves are working on it…

Stefan

Btw, where are you guys getting those prices above? Max is 399 USD and Gen is 100 USD for the full retail version. The max upgrade is 199 USD or 249 USD with gen. At current exchange rates, that’s 178 EUR, not 450 EUR, Julien.

http://cycling74.com/2011/07/22/max-6-and-gen-retail-pricing/

cannot wait for the RC!!

Elsehwere on the forums it’s reported the minimum dalay is the vector size/ Is the same true in gen~, or is it possible to obtain a single-sample dealy in gen~?

Single-sample delay/feedback is one of the exciting use-cases for gen~ (use the ‘history’ object or ‘delay @feedback 1′). This makes possible things like feedback FM, physical modeling synthesis, etc. that weren’t possible using standard MSP objects before.