Mhhh sorry... My config :

OS X.6.8 CPU : 2.8 Ghz Intel Core 2 Duo Philipe.

I got similar results on pc.

1. 76 [*~] max5 => 0%-1% max6 => 1%-2% 2. 10 [pfft~] max5 => 10%-13% max6 => 8%-12%

Intel Core i7 3.4GHz windows 7

i'm having the same problem with my patches. My main patch which takes up 30% cpu in Max5 yet it takes up to 60%-100% cpu in Max6, rendering my patch useless in Max6!

i'm rocking OSX vers. 10.6.8 2.66hz intel core 2 duo 4gb memory

i was hoping this problem was just me overlooking something simple since i'm so excited for Max6, but now i see i'm not alone.

What can we do (besides not upgrade, since i do think Max6 sounds better, at least with those working example patches it does)?

Same here.

The first thing I've tried is to load some of my usual patches to see if all works. All is fine, so far, except CPU is around 2 or 3 times higher than in Max5. I hope it's due to beta and that's not the price of the improvement in the quality of Max

The 64 bit signals will definitely consume more CPU cycles, but the apparent performance hit does seem a bit heavy.

I dearly hope that the beta is a slow debug build, otherwise I will most definitely not be upgrading. I recently bought a top of the line MBP to run Max 5, and now patches that used to top out at 30-40% CPU are crackling in Max 6. I could increase my latency something horrid, but I don't see why I should have to. Before anybody blames my patching skills and accuses me of being "shit at programming", consider this:

The emergence of a set of "SSE optimised" externals for Max 5 indicates that Max 5 does NOT use SSE parallelism (a way of performing calculations on 2, 4, or even 8 pieces of data at a time using special CPU instructions - Intel's version of Altivec). SSE instructions have been around for a long time, and IMHO Max ought to make use of them. From the way things perform in Max 6 I can only assume that this has not changed (somebody please correct me if I'm wrong)!

BTW, there still an option for Altivec optimisation in the Audio settings window, even though Max 6 doesn't run on PPCs.

Given Max's high system demands I think it is now a fair assumption that anyone running Max 6 will definitely have a PC capable of SSE3 instructions. All Intel Macs support this instruction set. I would prefer to spend my money on improvements to years-old code, rather than pretty GUI updates. I find the wheel menu and the patch cord arrows just get in my way.

Using a program like Max requires a certain level of computer-literacy. You have to be a bit of a geek in the first place. The more time spent on making things noob-friendly, the less time spent on bringing the rest of the package up to speed. I don't care how user-friendly something is if it's bloated and sluggish.

Before the petrol bombs fly, I will say that the improvements to [poly~] regarding resampling are an absolute joy. This is something we've desperately needed for a long time. And, the filters sound better. I don't think I'll be using dictionaries much, but that's more because I approach things from a fairly low-level perspective. I can see their value.

But there are many things that seem trivial to implement but have been overlooked:

1. [groove~] has way improved sound quality but still cannot be triggered at audio rate. (How many threads have we seen about that!?!)

2. [play~] does not have improved interpolation. To all intents and purposes, [play~] IS [groove~] but without the internal counter or loop logic. Surely the new interpolation code in [groove~] could be re-used?

3. [phasor~] cannot be re-triggered by a signal.

Regarding [gen~], while I applaud the idea, I can't quite bring myself to love it unless the rest of Max 6 speeds up. Otherwise it feels like a way of making up for lost speed, albeit one that requires a slightly different approach to patching. Don't get me wrong, the [history] node in itself is going to make a lot of issues go away, but even with my meagre C skills I can write simple externals that run orders of magnitude faster than [gen~].

All persons portayed within this post are fictitious and any resemblance to persons living or dead is purely coincidental. The author accepts no responsiblity for any milk spillage, ego bruising, or kitty slaying that may occur as a result of reading. YMMV.

P.S. It's obvious that work has gone into improving performance of FFT algorithms, as well as many other areas. This is great. I don't want to give the impression that the developers haven't been working hard, and I would be the first one to admit that they are vastly more talented and capable than me. But I am dismayed that a number of core objects seem to suffer such a large performance hit. Progress = getting more things done. What good is it if you can patch things easier if the patch itself won't work anymore?

Interesting stuff, I'm not sure how many times I'd just use 76 *~ objects in my patches so I decided to make an audio 'voice' which contains:

line~ phasor~ *~ +~ play~ pfft~ svf~ amongst a few other things.

I copied this voice 50 times. One version of the patch houses the voices in a Poly~ (with the addition of gate~) and the other does not. The idea being to approximate the kind of things you might get in an actual performance patch. And to look at how the use of poly~ and multithreading might affect the CPU performance.

I tested the patch in Max 4.6.3, Max 5.1.9, Max 6.0.0 beta.

Results on a MacBook Pro 2.66 Intel Core i7. I/O vect 256, Sig vect 265, Overdrive On, Audio Interrupt On. Not i'm not sure what the Activity Monitor readings actually mean - they jump high when poly~ is in parallel mode.

As you can see the parallel processing option for poly~ seems to really reduce (spread) the load. Another interesting thing is that the performance between 4.6 and 5.1 is greater in some instances than between 5.1 and 6. My only slight concern is that 6.0's CPU usage seemed to be quite spiky on my machine.

Obviously 6. is still a beta an I imagine they still have a few things to sort out so it's a bit early to make any definitive statements on performance. It seems to me that Max 6 offers a lot of new functionality and objects, the gap-less playback, filter design tools, faster JS and better editor, brilliant new jitter tools (materials, lighting, physics, etc). It seems that if you are prepared to optimise your patch using poly~ the performance hit for all these new things is not so bad.

Patches attached - don't forget to turn audio off/on when changing the parallel setting of poly~

That's OK raja, my panties were knotted into a tight little ball :P

But I've been at a dinner gathering and I played with my friends' kitties (no, really), which has lightened me up a bit :)

I'm ironing out the bugs in a sinc-interpolating playback object ATM, and it should be on the share pages within the week. Currently my naive implementation consumes about 1% CPU per instance. Out of curiosity, I started patching together an equivalent in [gen~]. I hadn't even got half-way before the CPU meter was at 12%. Needless to say I gave up.

For 16-point interpolation you need more than 16 peeks, 16 multiplies, a frac or two, 16 adds, and then some, plus a bunch of other utility objects. For this sort of stuff it's not possible to get anything close to 'optimal machine code' out of [gen~] (but then I didn't think so in the first place). This is not to knock the new benefits though; [history] makes a lot of old headaches go away. Not everyone wants to write externals, so I see great things on the horizons for the more conventional Maxers.

Oh, and the new Jitter stuff IS badass, agreed. All I was saying about [play~] is that the same nice interpolation could be achieved with the smallest bit of copy n' pasting. It all comes down to my old sentiment that before we get new goodies, it would be nice to have existing functionality brought up to 'speed' with competing software. I mean, we've already paid a lot of money for what was once somebody else's codebase with a nicer GUI.

well, i do not see that anyone has investigated how the new preferences panel for controlling scheduler values (queue throttle, poll throttle, redraw queue throttle, event interval, enable/disable refresh, refresh rate, scheduler interval, scheduler slop) affects execution time. we all know io-buffer size, but what about adjusting some of these? Might well be different values are more appropriate for various max/msp/jitter applications.(throttle down redraw for better controller/synth work? whatever, needs examining) just wanted to point out the new preferences... oh, and strong parliamentary 2nd on the beta forum bit: this thread should really be moved. Beta software discussions shouldn't be mixed with published software discussions. And, as far as many forum readers are concerned, *some* beta discussions should stay in beta forums!!: once software is released, go ahead state your judgement (once!) and act upon it, but it is really useless to beat the horse *after* the race.

Hi there christripledot,

Could you send me some details about the machine you are testing on, and the 16-point interpolation gen~ patcher? I think we should be able to get very good performance for this from gen~, and if you're not, it may be a great example for us to use in our optimization testing.

Thanks!

Last. Post. Ever.

@grrrwaa:

See attached screenshot: this is more expensive than my whole external.

OK, my knickers are untwisted. FWIW, I got the CPU down a great deal, and here's a sinc interpolating playback [gen~] for y'all. I get ~6% CPU, which is aight but by no means great (not to diss [gen~], but this sort of thing is definitely much better in pure C). I reckon if [play~] had the same interpolation as [groove~], the CPU consumption would be negligible compared to this.

[edited for tidy patch cords and pretty colours]

[edited again for bugfix and added sine test]

I can't reproduce your experience here. I have replicated the patch, however, without any outlets (or side-effects) there is no actual signal processing being done in the generated machine code. According to the gen~ object it is using about 0.01% of available time, which is probably under measurement error. In the parent patcher, 0.4% CPU is being used, which captures the overhead cost of the gen~ container. Measuring performance in top, or activity monitor, shows a greater percentage, but this appears unchanged whether the gen~ object is present or not.

Could I ask you what OS version and the details (model, cpu) of your Mac, and how you measured the high CPU cost of the gen~ patcher? There certainly shouldn't be a high overhead of this nature for the patch you sent; if there is, this is a bug report.

Thanks,

Graham

Ah, sorry Graham. Please see the above post. I have no idea why my CPU meter was so high with that unfinished patch. If it helps, MBP 2.2GHz i7, 8GB RAM, Snow Leopard.

I guess I was writing my reply when you posted!

FWIW, with your new patcher, on my machine (MacBook Pro 2GHz Core i7, running 10.6.8) I'm getting about 0.5% from gen~ (according to the gen~ internal measurement), and around 2% for the parent patcher (according to the mixer engine measurement). The gen~ measurement goes up to about 0.8% if I drive the phasor~ at 100Hz.

There's no doubt that it hand-coded C can generally be tuned and optimized to have better performance than something which has been generated from a more generic system, but overall we've been quite pleased with the performance gen~ is producing. It's important that gen~ has good performance, on average significantly better than a comparable MSP patcher (of sufficient complexity), but performance is not the only motivation for Gen. Simply making available low level processing within an environment that doesn't require knowledge of pointer arithmetic is very important; it makes available to any user (regardless of their programming background) a whole range of processes that were previously impossible or impractical in MSP, especially regarding the [history] operator as you say. The ability to generate and test live without needing to stop the program and recompile is also very important to support exploratory and live programming, both of which are very important creative activities. To expose this kind of generality may imply trade-offs for performance, but overall I think Gen is handling that trade-off quite well.

By the way, the 12 point interpolator sounds great, would you mind if we modified it slightly and added it to the distribution examples?

Graham

I'd be honoured! (Is it not 16-point though, or is there a hole in my understanding?)

For all my ranting recently, let it be known that I am seriously impressed by much of the work that's gone into Max 6. As you say, the benefits of [gen~] extend far beyond processor savings.

Thank you all for the feedback. There are many things to balance w/r/t performance, quality, multi-threading, seamless audio, etc., and we will be working to improve performance both before and after the release.

Here are a few things to keep in mind regarding performance testing:

- Max 6 is still in Beta.

- What is in this beta is not a debug build, and there are some unresolved issues. We acknowledge that.

- We take performance seriously, and are working on these issues (as well as many other aspects of the software, which are equally important to address).

- Some things are faster, some things are slower in Max 6. Some of that will remain the case even after release.

- There are a variety of priorities we are balancing. Performance will sometimes suffer at the expense of quality, flexibility, and maintainability. You are always welcome to continue to use Max 5 (or Max 4) for the situations where you find it performs better if you prioritize performance over quality and flexibility.

- Multi-processor support does incur some costs and we'll be working in the short and long term to improve this.To adequately compare a comparable Max 5 and Max 6 patch, please disable multi-threading support in the Max preferences to take any multi-threading overhead out of the equation. This is especially the case when trying to compare 1% vs. 3%. CPU.

- Whenever possible, please give us detailed examples of the performance tests you are making. Thank you to those who have already done so. We will make use of them and improve them where possible.

- Some things about using 64bit do come at a cost (e.g. among other things it uses more memory for signal vectors, and hence cache performance will not be as good). We think that the audio quality makes some of these performance costs worth it.

- Some things about the mixer also come at a cost (e.g. patcher cross fading while editing). We'll be trying to make this easier to configure UI wise so that you can more easily configure for seamless audio vs. CPU performance.

- For the initial Max 6 release, we will not be focusing on less maintainable SIMD code, though over time we will be investigating this more, both in the existing object set and in code generation.

I hope this helps to address some of the questions and concerns raised in this thread. We have some good ideas in a variety of these areas, and we hope that in the next public release, you will find some improvements.

Your continued feedback is important to us. Please keep letting us know how we can make things better. It might not always happen in the time you like, but as a small team working hard on a project we care about, for a community of talented and interesting people, we try hard to make Max something that is enabling rather than limiting.

Thanks, Joshua

Thank you for taking the time to give such a thorough reply! Thumbs up to all the above! :)

I made the CPUtests of leafcutter, but needed to reduce the number of voices to 20...

White Macbook 2 GHz dual core OS 10.6.8

20 voices non Poly~ version CPU% reported by Max CPU% reported by Activity Monitor Max 4.6 24% Activity Monitor: 31% after closing idle 9% Max 5.1 29% Activity Monitor: 39% after closing idle 10% Max 6.0 37% Activity Monitor: 53% after closing the patch idle 20% after closing a different patch (10*gizmos) idle consumption went down to 6%

20 voices within Poly~ version CPU% Max (w/parallel) CPU% Activity Monitor (w/parallel) Max 4.6 25% - n/a - 32% - n/a Max 5.1 31% - 19% - 41% - 44% Max 6.0 40% - 26% - 52% - 55%-62%

The cost for 64-bit sound seems high at the moment. I appreciate the efforts to make it better. I really love the gen~ object and the overall enhancements within the work flow...

I updated Max6 now to 6.0.1

I must say (for the moment) that for me and my laptop: MacBook Pro i7, 2,3 GHz, 8 GB, OSX.6.8

Max6 is useless.

The reasons are well explained in this post. I also find that 64-bit is a feature at a great cost of CPU, firing numbers beyond any control. And unfortunately I can't estimate the audio quality with my ears on my own work.

Can be considered an improvement?

My patch is the outcome of three years of work on Max5, that finally has found the right balance of Performance / CPU / GUI, making large use of Max, Msp and Jitter togheter.

Max6 is simply unable to do the same job, also due to a very slow GUI response, that can cause a crash if the patch opened has a relative density of patch cords to rebuild. Yes, the GUI is more charming, more user friendly, more...

Can be considered an improvement?

I don't consider myself a skilled user and I don't want to belittle the work done at Cycling, I'm just realistic about what it concerns my experience, and at the moment I can't glorify Max6.

Yes, I continue to use Max5.

You didn't update. Max5 is still available on your computer.

Max 6 isn't useless; I've found some good uses out of it. I'm sorry that you haven't been able to notice differences in 64 bit audio. Here's a hint to where you might find improvements: https://cycling74.com/articles/max-6-sneak-peek-msp-audio-quality/

You are an early adopter and may need to find out why some of these things are happening and report them. They could be bugs that help everyone. That's part of the responsibility that comes with the benefit of using the software immediately.

All of the things you have mentioned can be tuned in preferences and options. I would try that as well. If you use this as a learning experience to figure out tuning max preferences and figuring out where bottlenecks are, you will certainly be a lot closer to being a skilled user. I don't want to belittle your experience right now. I want you to realize that you have a lot of options that will inevitably make you a better coder.

> You didn't update. Max5 is still available on your computer. Can you be more clear? Am I forgetting to read some documentation about it? Or even some post?

>Max 6 isn't useless; I've found some good uses out of it. I'm sorry... I can't estimate the audio quality, since my patch doesn't run properly in Max6 as it does in Max5. This great cost of CPU causes an enormous latency with obvious consequences on the audio signal. Yes, I've seen all the documentation came out since the Beta release but usually I don't admire something that can improve my work till it really does it.

>All of the things you have mentioned can be tuned in preferences... Unfortunately there's nothing to tune, nothing that can magically quiet a nervous CPU performance.

Bugs > a very slow GUI response that can cause a crash.

I don't think to be the only one here to experience this.

^ To be fair, both Max 5 and 6 crash on me on a pretty regular basis, even when patching simple things. I've learned to live with it, and to save often. This sucks big hairy plums, but I don't think it's got any worse with Max 6.

Max 6 isn't useless; it's a great new piece of software with teething troubles... but it IS a CPU hog, and the difference is noticeable. Those of us with big patches that Max 6 seemingly can't sustain are entitled to our grumbling. It's not fair to dismiss someone's valid complaint by suggesting he become a "better coder", even if he was a bit brusque.

http://en.wikipedia.org/wiki/Moore%27s_law i really appreciate cycling74 for focusing on quality. I personally wont buy max 6 too soon because of the performance hit. I don't understand the discussion, but it's nice to get those benchmarks on a regular basis.

yes, I was brusque.

Because I think this topic must be on the top of the paradigms to take in consideration in Max6. And because I don't understand why I must start to think smaller in Max6 with the latest generation laptop. I love quality too, Max itself is quality, 64-bit processing audio means a great quality. I plain to use just Max6 for any audio application and don't corrupt audio recordings / performances through any plugin or other softwares with ambiguous algorithms.

But now I've a candy that I can't unwrap

and I'd like to know that in the next future I can finally taste it. As christripledot said, thanks... it happens especially to who is keen on building big patches. Of course, it's hard to find solutions for every taste.

@ lasmiveni Have a look at 6.0.1. We addressed a lot of performance issues. Hopefully this candy you can unwrap.

"But now I've a candy that I can't unwrap" I feel the same way because i am also building one big patch since a couple of years that i'm quite sure won't work with max 6 because of performance issues. And i dodn't want to stop the discussion, i just find that the point really is that a company decided to do the next step to early for our budget.. Max 5 is still here as somebody else said. i just find it really dump to say things like max 6 is useless, although i also wanna taste the candy...

A lot of work has been done (and will continue to happen) to improve MSP performance for this update. I look forward to hearing how you all get on with the update.

Thank you Wesley for your reply,

as I pointed above, my experience is the same on the 6.0.1.

ah you're right. Sorry for the oversight. If you have a patch that's causing performance problems, please either post it here or send it on to support@cycling74.com . The more and varied testing we can do the better. regards!

@woyteg

I've grown sick of this discussion too. I don't want to dump on Max 6; it's a quality piece of software. The benefits [gen~] brings are staggering, particularly for the educational field.

I've gone and bought Max 6 because I don't want to fall behind. In order to continue to realise my all-conquering performance patches, I now find myself writing more and more C and assembly. Such is life. In any case, I'm learning a lot more about DSP and programming in general, even if it does up the development time.

@lasmiveni

It appears that the majority of users aren't so bothered about performance. I feel your pain.

@Wesley Smith

I recognise and appreciate the huge amount of work that has gone, and continues to go, into Max. I'm sorry that you and your colleagues have to bear the brunt of such vocal complaints - it can't be nice.

For the programmers, it must seem like we're treating you with contempt. For this I am sorry.

It's a two-way street though - I just bought a high-powered MBP, and even that can't run my main patch anymore. That feels like a slap in the face. Plus there are new bugs that should never have seen the light of day. I'm sure they'll be ironed out, don't get me wrong, but it's not fair to expect everyone to be happy.

Anyway, I have a feeling a certain somebody is going to be along any minute to put me in my place, so I'm going to make myself scarce once again.

Pax.

To reiterate Wesley's call, please keep sending us patches which illustrate performance issues and bugs. We are actively working in these areas. Anything concrete, we can act upon. General complaints without examples won't get investigated in the same way.

Thanks for your continued feedback!

" but it's not fair to expect everyone to be happy."

@christripledot I'm pretty sure I didn't say this, at least it wasn't my intention. As for negative or harsh comments, it comes with the territory and is not that big of a deal. My aim is simply to turn them intro something constructive that we can use to make Max better. If you have patches that demonstrate serious performance deficiencies between Max5 and Max6 please send them on. Reading your comments above, I'm seeing something about gen~ and object feature requests, but nothing comparing Max5 to Max6. thanks!

Hi Wesley,

Sorry, I think I was dragging you into an older debate - didn't mean to put words into your mouth.

I must confess I find the whole, "send us your patch and we'll look into the problem, but until then there is no problem" attitude a little bothersome. Are you seriously telling me you haven't noticed a performance hit in your own patches? Or maybe everyone at c74 has an 8-core superMac?

Christopher,

Sorry for any miscommunication here, I was not trying to imply that there is "no problem". I just wanted to clarify that general complaints will not be investigated in the same way as concrete complaints. There are many issues, some we know about and some we don't. We are actively working on improving the software in countless ways. The more people that present us examples of issues which are affecting them, the more we will focus on these issues.

If you don't want to help us in this process by providing examples, that is fine, but I will repeat that clear demonstrations of issues will result in prioritization and action more effectively than a general complaint. Not that no action results from the general complaint.

Thanks again, Joshua

›christripledot

yes I agree with you.

›Wesley

Because I'm sorry, but I can't post a patch that is the result of 3 years of work.

In the past I always reported simple patches to the support@... and in some case they've been usefull for all of us to solve a bug.

Anyway, I know that it could be usefull but I can't think to pack the whole patch and send it by email.

i mostly use max version 4.x until today - and i must say it rocks.

nobody forces you update to something you dont like.

@ christripledot:

>>To be fair, both Max 5 and 6 crash on me on a pretty regular basis, even when patching simple things.

That is not my experience (or at least not in the same way). Almost all the crashes I see with Max are caused by externals I am debugging. Other than that Max is very stable. I patch a lot. I patch in classes on max - I don't ever expect to have regular random crashes. If you really are seeing this it suggests to me that there might be an issue with your installation / unreliable 3rd party externals or something else.

>>I must confess I find the whole, "send us your patch and we'll look into the problem, but until then there is no problem" attitude a little bothersome. Are you seriously telling me you haven't noticed a performance hit in your own patches?

You are assuming that there are uniform performance hits in Max6, which is not the case. You may have a patch that clearly demonstrates a specific performance problem / bug. Such patches highlight problems that are not obvious to programmers because it is not possible to anticipate all combinations of objects or user requirements. Let's say you use one object 1000 times in your patch that is now twice as expensive as in Max5 - that might be a problem for you, but someone using 2 of them might not even notice any difference.

In Max 6.0.1 it is actually also possible to construct demo patches (useful or not) than run faster than in Max5.

If you want the software to improve please consider participating constructively by providing example patches.

Finally it is worth perhaps mentioning that if you are using a lot of 3rd party MSP externals that are 32 bit then the cost of wrapping them could be noticeably large. This is not a cycling issue and cannot be blamed on them. They could have decided not to perform this wrapping and so all 3rd party MSP stuff would be broken in Max6 until rewritten. Without a patch it is impossible to know the issues that are causing problems.

A.

Almost all the crashes I see with Max are caused by externals I am debugging. Other than that Max is very stable.

.

Max5 almost never crashes on my Mac. But Max6 crashed very often (10 times a day), only trying new objects with extremely basic patches (but no 3rd party objects). Unfortunately, nothing reproductible so far, so no bug report... Sorry to be unproductive! Let 's see if 601 is more stable!

p

When MAX5 was released, I experienced the same problems with 4 vs. 5 Back then I decided to make a benchmark test which could show all the differences on different platforms

I am very sad to say, that NOTHING in the audio performance in MAX5 has improved since then. Now I am experiencing the same sad feelings; I feel that I have to buy the new version because I do want the new features (only gen really), but at the same time MSP gets more and more useless since it is such a CPU hog.

So now I am in the situation where everything that is critical (I make a lot of software for embedded machines) Still has to be made in MAX4, unless I need the features of 5 (only multythreading really), then I'll use 5, and If I really need the gen functionality, I'll use 6....

But I think it is very sad that we have gone down in performance almost 4x since MAX4 :(

Mind you, it really is not my intention to be so negative, but I really, really would like to see a large performance stepup, since I really would like to use only MAX6 (I fear the day that externals will not be compatible anymore which I suspect won't take a terrible long time anymore)

If anyone (the devs maybe?) feels that it is useful to have a new benchmark test I'd be happy to make that and collect all the results, but only if I have the feeling that something will be done with the outcome.

@Kessito

I have the same experiences with MSP and the same fears! Philippe