lvdw

I tried to put gen~ in poly~: 300% more expensive. Why is that? Is it not a good idea in general? Anybody here that has something wise to say about this?

gen-in-poly

Sorry, posted a bit too quick. The answer is probably that this subpatcher simply isn't better off inside gen~. Should have tested that first. Not poly~ related I guess.

Interesting. I get very different figures here:

Could you tell me details about your system?

I tested with Mac 10.6.8, Core i7 2Gz (4Gb RAM). 64 sigvs, 44.1kHz, no overdrive or SIAI.

That said, performance tuning is something we are actively working on right now across numerous MSP objects, the MSP audio chain and mixer, and gen~, and improvements can be expected in updates over the coming months.

Interesting. I get very different figures here:
withgen: 34-25%
oldstyle: 38-39%

That said, performance tuning is something we are actively working on right now across numerous MSP objects, the MSP audio chain and mixer, and gen~, and improvements can be expected in updates over the coming months.


Interesting indeed, especially since gen~ actually is a bit faster in your case.

I use a MacBook Pro 13" // 2.4 GHz Intel Core 2 Duo // 4GB 1067 MHz DDR3 // Mac OS X 10.7.2 and the latest Max 6 build. The results above are with the same settings, but overdrive turned on. But I tried various other combinations with the overdrive and interrupt settings, and it doesn't seem to make a big difference, maybe one percent up or down.

Looking forward to future improvements, also in terms of documentation of gen~ and its own objects. And do you plan to incorporate some ways of monitoring processes inside of gen~, or maybe some test mode? Or do I miss something? I understand that it's pretty much against its nature, but probing and monitoring the internal behavior is problematic now (and thus not entirely with 'the comfort of max'...)

Yes, we are also exploring ways to support debugging modes for probing etc. in Gen patchers, as well as ways to make accessing help more comfortable.

iMac 3.06 GHz Intel Core 2 Duo - 4GB 800MHz DDR2 SDRAM - 10.6.8

It's worth also noting that small subpatchers (like this example) are not likely to show better performance than native objects: there is some unavoidable overhead in passing from the gen~ object to the generated native code, and with a small patcher there isn't much opportunity for automated optimization to improve over hand-tuned optimization. Gen is a new technology, and efficiency is only one of its motivating goals. We expect gen~ performance to increase in coming updates.

I should add that in this particular patch the bulk of the processing is in the cycle~ object / cycle operator. The

cycle~ object has been heavily optimized in a way which cycle in gen has not yet been, but that we will be working on making those changes to cycle in gen in a future update.

I should add that in this particular patch the bulk of the processing is in the cycle~ object / cycle operator. The
cycle~ object has been heavily optimized in a way which cycle in gen has not yet been, but that we will be working on making those changes to cycle in gen in a future update.

Anyway, like I said in the third post: it's not poly~, since the subpatch itself is already faster without gen~.

Still, the differences in performance results are interesting, I think. Do you have a clue? Is it a processor issue?

That last bit is very interesting.
Anyway, like I said in the third post: it's not poly~, since the subpatch itself is already faster without gen~.
Still, the differences in performance results are interesting, I think. Do you have a clue? Is it a processor issue?