Forums > MaxMSP

SERIOUS Max 5 performance thread

October 21, 2008 | 7:39 pm

There has been a significant discovery (regarding Max 5 canvas performance) made in the midst of the past few flaming threads, but I seriously doubt that any of the c74 staff have wasted their time to wade through the dozens of childish name-calling posts to find it. So, I’ve started a thread to seriously discuss this performance issue, without the detrimental insult posts to confuse everyone.

The complaint is that Max 5′s canvas is slower than many people would like. When dragging many objects around, the frame rates can get somewhat low. The discovery which was made was that Max 5, unlike Max 4, constantly recompiles the patch as you drag objects around. To prove this discovery, vuxivil created a patch with a metro object that bangs two message boxes. While the metro is running, you can drag one message box to the other side of the other message box, and the order in which they are banged changes BEFORE you’ve let go of the mouse. This seems to indicate that Max is doing a lot of behind-the-scenes calculations, which may or may not be unnecessary, and which may or may not be contributing significantly to the GUI slowdowns. The patch vuxivil created is below:

– Pasted Max Patch, click to expand. –

Continuing with this logic, how can we test if this is actually causing performance degradation? I thought of one way, which may or may not prove anything. I made a patch with 256 unpatched metro objects. When I select them all and try to drag them around (on my slow G4) I get a frame rate of about 4 FPS. Then, I made a patch with 256 metro objects, all connected in a line. When I drag these 256 objects around, I get a frame rate of about 2 FPS. To me, this is a possible hint. My theory is that Max has to do a lot of extra calculations to recompile the patch when the objects are connected vs. when they are not connected. This is why the performance is much lower when they are connected. Thus, if Max was not recompiling the patch during drags, and just recompiled once on mouseup (which I believe the majority of Max users would not cry about), then we should expect a significant performance increase. Below is the unconnected metro patch followed by the connected metro patch, for you to try yourself:

– Pasted Max Patch, click to expand. –

– Pasted Max Patch, click to expand. –

One other thing I’ve found while playing around: The frame rate drops way down even as you are selecting a lot of objects. If you drag a selection window across a number of objects, once you have 4 or 5 objects selected the frame rate is still fine, as you near 100 objects the frame rate gets noticeably lower, etc. The frame rate for selecting objects seems to be the same as the frame rate for moving that same number of objects around. This seems strange.

So, can anyone try these patches and confirm what I’m talking about? Also, c74 staff: do you have any comments to add?

Let’s keep this constructive and professional.


October 21, 2008 | 9:14 pm

There’s 2 separate but related problems in Max5 which shouldn’t be lumped into one.

The problems are: JUCE’s code, and MAX’s code.

1A) JUCE’s performance.

Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios– a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE’s performance couldn’t be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt’s software rendering of vector is also devastatingly faster than JUCE.

And this is the *foundation* of the future of Max… Think about that for a moment.
What a wonderful executive move.

The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven’t worried about it since.

It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.

If Max5 was truly pushing the envelope, right on the edge of what’s even possible to do with our computers– doing something amazing on computers just barely capable of keeping up with its demands, I’d be using it and loving it despite the flaw. But rather, the *missed potential* as a result of Cycling’s choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.

If Cycling is interested in some CPP code to show how ridiculous JUCE is, I’ll provide it, but this is trivial for them to whip up.

1B) JUCE’s latency.

The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui’s are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That’s out of Cycling’s control unless we started seeing commits by them, and that shouldn’t be their job.

2) Specifically addressing swieser1 and vuxivil’s point:
Max 5′s code.

Cycling has coded Max5 in a way which is *straightforward* and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It’s ‘Solve the problem cleanly first, and then optimize later.’ The patch which vuxivil provided demonstrates Max5′s *straightforward* implementation.

If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won’t work for Max5 because of its faulty foundation. JUCE’s weakness triggers a chain of events which ruins Max’s straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.


October 21, 2008 | 9:40 pm

Dear Zola,

- Kindly move this commentary into a new thread, perhaps titled "Juice
Tests to Examine Latency", and **post supporting code**. How do I know
what you’re saying is true? Sounds to me like you’re pulling numbers
out of thin air, so PLEASE prove me wrong. Post code, system specs,
and an XCode and/or VisualStudio project file so other people can test
your assertions.
- We’re trying to keep this thread for SERIOUS isolation of Max5
performance issues. Continuing your last rant in this thread just
isn’t right. Surely you can understand that. Competent community
members are now trying to follow up on your complaint; they don’t need
more cathartic input from you at this time.

yours
-Jerzy

On Tue, Oct 21, 2008 at 5:15 PM, Zola wrote:
>
> There’s 2 separate but related problems in Max5 which shouldn’t be lumped into one.
>
> The problems are: JUCE’s code, and MAX’s code.
>
> 1A) JUCE’s performance.
>
> Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios– a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE’s performance couldn’t be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt’s software renderin
g!
> of vector is also devastatingly faster than JUCE.
>
> And this is the *foundation* of the future of Max… Think about that for a moment.
> What a wonderful executive move.
>
> The day I benchmarked JUCE and Qt, I removed Max5 from my computer and haven’t worried about it since.
>
> It was a moment of understanding, and I realized I could never come to accept Max5 with this knowledge in mind.
>
> If Max5 was truly pushing the envelope, right on the edge of what’s even possible to do with our computers– doing something amazing on computers just barely capable of keeping up with its demands, I’d be using it and loving it despite the flaw. But rather, the *missed potential* as a result of Cycling’s choices, is why I cannot use Max5. It was a huge letdown, something that could have been great.
>
> If Cycling is interested in some CPP code to show how ridiculous JUCE is, I’ll provide it, but this is trivial for them to whip up.
>
> 1B) JUCE’s latency.
>
> The way that JUCE works, is to complete its operations over a period of time. This is how JUCE works. JUCE ui’s are long pipelines. Regardless of how perfect Cycling codes up their end of the deal, JUCE still works with an inherent latency. That’s out of Cycling’s control unless we started seeing commits by them, and that shouldn’t be their job.
>
> 3) Specifically addressing swieser1 and vuxivil’s point:
> Max 5′s code.
>
> Cycling has coded Max5 in a way which is *straightforward* and clean to them, but which fails to introduce a lot of hack-code to avoid pegging JUCE. It’s ‘Solve the problem cleanly first, and then optimize later.’ The patch which vuxivil provided demonstrates Max5′s *straightforward* implementation.
>
> If you look at a graphical system which has something like the composite pattern, or rather anything like a set of update dependencies / dependencies which can trigger other things to need rerender, it can sometimes be faster to *just do it straight* and let the fast graphics backend handle the cases of duplication, rather than chewing CPU time trying to avoid duplication. But this won’t work for Max5 because of its faulty foundation. JUCE’s weakness triggers a chain of events which ruins Max’s straight approach. And so Cycling will have to introduce more intelligence to try to avoid their vector toolkit, which is a sad state of affairs.
>
>


October 21, 2008 | 10:22 pm

At this point, further pontification on the subject of performance, including speculation about our coding practices, executive decision-making, use of third-party technology, etc. is no longer of any interest to anyone at Cycling ’74, and does not serve the purpose of obtaining the desired performance optimizations in future versions. It just wastes the time of the people who could be working on the problem, but, like passers-by at the scene of an accident, feel compelled to look at the latest uninformed screed.

I appreciate that a small number of users are concerned about the speed at which hundreds of objects can be dragged around. Frankly, we haven’t spent a lot of time optimizing this particular case up to this point. However, since pretty much anything can be optimized with effort once it has been identified as a problem, we are currently in the process of looking at it. I can tell those of you who might care that based on our preliminary analysis, all the speculation about the source of the performance problems that has been posted here is, unsurprisingly, wrong.

David Z.


October 21, 2008 | 10:52 pm

David, Max5′s performance shows just how right you’ve been so far.

You fail to address the point of JUCE’s underlying vector performance, and say your analysis was "preliminary."

Why would your analysis be preliminary if you’re well aware of the problem?

The speculation I’m ‘wrong about’ (sure, we have no idea what’s going on in your codebase) is everything *ON TOP OF* JUCE’s problems. Yes, I’m sure you’ve got some rather specific and detailed context in your mind about your own codebase, and where you can improve on your end of the bargain, but that’s just your efforts to try to get Max5 to be as fast as it can possibly be *given the baseline of JUCE’s maximal performance*

That doesn’t mean we have an awesome and fast future in store. It means Max5 won’t be "horribly slow", just "slow" when you fix it.


October 21, 2008 | 10:55 pm

I do appreciate you admitting Max 5 performance is a car-wreck, though…


October 21, 2008 | 10:59 pm

max5pariah,

Where in my original post did you see anything about JUCE? You are attempting to hijack this thread for your own purposes. I’m trying to provide a forum that might just begin to scratch the surface of doing what we can to help c74 identify the problem, and you’re just confusing the issue and pissing off c74 with meaningless drivel. The creation of this thread was precisely for the purpose of preventing posts like yours. None of your claims are verifiable, remotely helpful, or relevant to this topic of discussion. Please take jerzy’s advice and start a new thread.

David,

I hope you can ignore max5pariah’s posts and take the remaining members of this forum seriously. When you said that the speculation about the source of the performance problems was wrong, did you mean speculation about JUCE or speculation about the repetitive patch recompiling during object moving (or both)?

On the one hand, I agree with you that peak performance when dragging hundreds of objects around is a low priority, and it is not a problem that is significantly affecting me at the moment. However, on the other hand, it does seem like a legitimate performance issue that could have unknown implications in areas other than 100+ object dragging.


October 21, 2008 | 11:04 pm

Quote: max5pariah wrote on Tue, 21 October 2008 16:55
—————————————————-
> I do appreciate you admitting Max 5 performance is a car-wreck, though…
—————————————————-

You are a complete idiot. With a personality like yours, I can’t imagine you have many friends left in your life.

If you don’t like Max 5, then why don’t you just continue to use Max 4 and stop posting about Max 5? By this point, you can’t possibly believe that you’re helping the situation in any way, can you?

We’ll let you know when Max 5 is ready to meet your exacting professional standards. In the meantime, leave us alone.


October 22, 2008 | 1:50 pm

If max’s recalculations of object order while dragging is slowing the program down considerably, can I suggest that a feature be included to allow users to disable this feature? I’m thinking something along the line of a toggled menu option that would be on at default, but could be bypassed at the user’s will.


October 22, 2008 | 3:40 pm

Real time order calculation is what allows it to dynamically
renumber inlets and outlets when you delete them. As well
as maintain wire connections when an inlet is deleted.
Why would you want to disable that?

I don’t know why such a fuss is made of performance in
edit mode. I really don’t need to move 256 objects around
and maintain high frame rates. If you are really doing that
then you need to redesign your patch. Granted Max5′s UI
may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.

What is more important to me is how it preformes when I am
doing a performance. I don’t edit things while I perform.
The whole argument seems silly to me.


October 22, 2008 | 5:07 pm

> If max’s recalculations of object order while dragging is slowing the program down considerably

As I said before, outlet sorting is not the source of performance problems when dragging large numbers of objects.

David Z.


October 22, 2008 | 9:51 pm

Quote: Anthony Palomba wrote on Wed, 22 October 2008 09:40
—————————————————-
> Real time order calculation is what allows it to dynamically
> renumber inlets and outlets when you delete them. As well
> as maintain wire connections when an inlet is deleted.
> Why would you want to disable that?
>
> I don’t know why such a fuss is made of performance in
> edit mode. I really don’t need to move 256 objects around
> and maintain high frame rates. If you are really doing that
> then you need to redesign your patch. Granted Max5′s UI
> may not be as snappy as Max4, but the patching work flow improvements far out weigh the negatives.
>
> What is more important to me is how it preformes when I am
> doing a performance. I don’t edit things while I perform.
> The whole argument seems silly to me.
>
—————————————————-

On Max 4 the graph isn’t rebuilt, on 5 it is, while dragging things around that is.

I wouldn’t want it disabled, I would want it shut off while I dragged things around because no new outlets are going to be made, and any implicit right-to-left ordering could be done after the user lets go of the mouse.


October 22, 2008 | 9:56 pm

Quote: max5pariah wrote on Tue, 21 October 2008 15:14
—————————————————-
> If Cycling is interested in some CPP code to show how ridiculous JUCE is, I’ll provide it, but this is trivial for them to whip up.
—————————————————-

Man, why would you even debate this? Whip it up already. David’s already stating that constant reinterpretation isn’t at the heart of the issue, so it really leaves only JUCE.

I’m afraid you’re gonna have to open whatever coder it is you use and write one up, not just for Cycling, but for anyone with a complier/IDE setup that is interested in benchmarking JUCE.


October 22, 2008 | 10:25 pm

Baseless speculation. Technical blather. More assumption. ignoring of stated facts from expert sources. Faulty conclusion. Personal attack.


October 22, 2008 | 10:36 pm

Eh,

If the problem is JUCE, and, if Zola can make a case against JUCE with real benchmarks… I can put a bullet in the head of Max 5 forever.

Despite my desire to just move on I am still clinging onto a hope that there’s more of an interest in this topic from Cycling. David has just reiterated what Bernstein said 4 months ago. The graphical issue could be optimized, but it’s not a big concern.

If the problem is JUCE, and JUCE is here to stay, then I’ll feel completely fine with moving onto another platform, despite the 42 trillion hours Ive invested in building things in Max… give or take 2 trillion.

@Zola,

For your own sanity, post some benchmarks of your findings. Quit assuming that Cycling knows about JUCE’s dirty secret and bring it all to light. You are being somewhat difficult in that you’re making it sound like this is just some big cover-up operation. If JUCE sucks as hard as you’ve stated, we’d all like to know.


October 22, 2008 | 11:19 pm

"I can put a bullet in the head of Max 5 forever."

I mean, really, do you hear yourself?

I sincerely hope you were wearing black leather pants and a jacket, no shirt, and a red bandana all while fondling a switchblade in one hand while polishing the silencer for your fully automatic sub machine gun in the other. Motorcycle parked out back, in a dusty motel room somewhere in the Mexican desert. Dusty boots on a table next to a carton of cigarettes and a few bottles of tequila, with a guitar case full of grenades to your side. You grimace, and log onto the cycling 74 forum to taunt your prey. Your stolen military spec satellite uplink renders you untraceable. You are killing machine!

Just a few more posts, and your target is yours! Swoop in for the kill!

I cant wait to see the juicy fragments of skull and brain matter to fall to the ground, finally putting Max 5 out of its misery…

You step back from the shadows, your gun still smoking. You light a cigarette and breathe deeply.

All is well in the world. Your job here is done.


October 22, 2008 | 11:24 pm

Quote: vade wrote on Wed, 22 October 2008 18:19
—————————————————-
> "I can put a bullet in the head of Max 5 forever."
>
> I mean, really, do you hear yourself?
>
> I sincerely hope you were wearing black leather pants and a jacket, no shirt, and a red bandana all while fondling a switchblade in one hand while polishing the silencer for your fully automatic sub machine gun in the other. Motorcycle parked out back, in a dusty motel room somewhere in the Mexican desert. Dusty boots on a table next to a carton of cigarettes and a few bottles of tequila, with a guitar case full of grenades to your side. You grimace, and log onto the cycling 74 forum to taunt your prey. Your stolen military spec satellite uplink renders you untraceable. You are killing machine!
>
> Just a few more posts, and your target is yours! Swoop in for the kill!
>
> I cant wait to see the juicy fragments of skull and brain matter to fall to the ground, finally putting Max 5 out of its misery…
>
> You step back from the shadows, your gun still smoking. You light a cigarette and breathe deeply.
>
> All is well in the world. Your job here is done.
—————————————————-

Holy crap I’m not sure I’ve ever laughed so much at anything I’ve read on the internet! Bravo!


October 23, 2008 | 12:07 am

I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max’s head" is putting an end to any sort of hope I have of ever using it.

So, let’s get some benchmarks. Fair enough, right? We don’t have to use our feelings to gauge Max 5′s worth, but raw data could support that the things I value in a program will never be a reality for Max. I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.

Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that’s left on the stack, unless someone else has a better theory?

Max 5 feels hopeless. All I want is to move on from it. Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don’t wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won’t accept anything less.

Benchmarks!


October 23, 2008 | 12:10 am

Vade, you are my favorite poster on the internet.

As to some useful comments – I’ve never run into TOO much of a problem dragging things around in max. However, many of my interface elements involve numerous objects (a single slider is about 11-12 objects, for various reasons – settings saving, linking to an editbox, etc) and every couple of weeks the thing I"m working on grows out of hand and I need to rearrange it a bit. This issue of dragging lots of objects becomes a problem here, because these aren’t elements I can easily encapsulate, and I get a lot of slow down.

Honestly though, I come across it so rarely that it doesn’t bother me much at all.


October 23, 2008 | 12:44 am

A Question to Everyone:

Should David Z. post a technically detailed explanation of why there
is latency at his convenience? Do we have "a right to know"?

Reply with +1 for Yes, -1 for no, 0 for don’t care.

Please stop speculating on this problem and let’s get productive. He
may refuse to do this, but this would stop people complaining about
juice with ZERO proof.

thanks for keeping it professional,
-Jerzy

PS Zola, I’m still waiting for the code sample that proves your
accusations. Hmm, and you were so quick to reply before…

On Wed, Oct 22, 2008 at 8:07 PM, vuxivl wrote:
>
> I want to know, based on data, that Max is in non-salvageable for my standards. Hence, "putting a bullet in Max’s head" is putting an end to any sort of hope I have of ever using it.
>
> So, let’s get some benchmarks. Fair enough, right? We don’t have to use our feelings to gauge Max 5′s worth, but raw data could support that the things I value in a program will never be a reality for Max. I wanna know if JUCE is really as bad as Zola said. I dont wanna base that on merely my making observations that every JUCE app Ive ever used is complete latent crap, but based on vector performance graphs.
>
> Since David has rebuked my one hope for the easy fix, my reinterpretation speculation, pinpointing/exposing JUCE is all that’s left on the stack, unless someone else has a better theory?
>
> Max 5 feels hopeless. All I want is to move on from it. Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don’t wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won’t accept anything less.
>
> Benchmarks!
> –
> Max 5: Looks like OSX, performs like Vista.
>
>


October 23, 2008 | 12:46 am

fine, jesus x christ, just fricking move on already. go use
solidworks or something.

all together now: 1 2 3 PLONK!

On Oct 22, 2008, at 8:07 PM, vuxivl wrote:

>
> I want to know, based on data, that Max is in non-salvageable for my
> standards. Hence, "putting a bullet in Max’s head" is putting an end
> to any sort of hope I have of ever using it.
>
> So, let’s get some benchmarks. Fair enough, right? We don’t have
> to use our feelings to gauge Max 5′s worth, but raw data could
> support that the things I value in a program will never be a reality
> for Max. I wanna know if JUCE is really as bad as Zola said. I dont
> wanna base that on merely my making observations that every JUCE app
> Ive ever used is complete latent crap, but based on vector
> performance graphs.
>
> Since David has rebuked my one hope for the easy fix, my
> reinterpretation speculation, pinpointing/exposing JUCE is all
> that’s left on the stack, unless someone else has a better theory?
>
> Max 5 feels hopeless. All I want is to move on from it. Benchmarks
> are the foundation for objectivity here, a middle ground we can all
> observe, and without them, what hope is there for finalization? I
> don’t wanna sit around thinking version 5.x.x will fix this. As Zola
> stated, "really slow" would only become "slow" under his assessment.
> I want blazing fast, and won’t accept anything less.
>
> Benchmarks!
> –
> Max 5: Looks like OSX, performs like Vista.
>



kjg
October 23, 2008 | 1:23 am

Exactly. This is getting completely idiotic.
David Z doesn’t owe you anything.

-1, get a grip, move on, let go, breathe out, and relax.

*plonk*


October 23, 2008 | 1:31 am

LMFAO @ vade!! I’m literally on the floor crying… It’s funny because it’s so true.

Quote: vuxivil wrote on Wed, 22 October 2008 18:07
—————————————————-
> Max 5 feels hopeless. All I want is to move on from it. Benchmarks are the foundation for objectivity here, a middle ground we can all observe, and without them, what hope is there for finalization? I don’t wanna sit around thinking version 5.x.x will fix this. As Zola stated, "really slow" would only become "slow" under his assessment. I want blazing fast, and won’t accept anything less.
—————————————————-

Vuxivil, nobody gives a shit about your standards. Please, I beg you, move on from Max 5. I think c74 would encourage you to do the same. Your quest to put Max 5 to the test is interesting to no one but yourself. It’s obvious that David Z. does not have a priority structure that is up to your standards, therefore Max 5 will not come up to meet your rigorous standards in a timely fashion, if ever. Please please please please please move on.

I find it almost irresistible to respond to these people’s posts, just because it is so easy to point out their shortcomings. But, this will be my last post on the topic, since I’m fully aware that I’m just feeding the troll(s).


October 23, 2008 | 1:51 am

-1, too. Sitting around waiting for David to really benchmark JUCE is a waste of time. I mean, this is the guy that brought us Max 5, lol.

I want Zola to come back and show us what he’s got. If he doesn’t, well, I’m 99% sold on the idea that Max will be crap for "the next 20 years", so, that small area of doubt will just have to live alongside an overall conviction that I’ve been robbed of a great future using Max because of some poor managerial decisions.

Zola anticipated this, what a year ago? I went through and read his posts, and he was critical of JUCE from the start, before Max5 was even out. People flipped out and accused him of all sorts of trolling. He was spot on with his prediction. The guys a prophet as far as I’m concerned.

Later others joined ship and slandered JUCE, but definitely not under Zola’s flag. He’s a complete outsider with zero friends. His complete nihilism and lack of empathy I find to be absolutely essential for these sorts of matters. He cuts right through the hierarchy and attacks Max at it’s core. He doesn’t care about your feelings, nor should he. He’s here to do one thing: point out Max 5′s flaws. I see no better person equipped to end this flame war than someone who has no interest in being friends or amicable with the denizens here, but who is willing to stand up in his belief that Max should be _much_ better than it is in canvas performance.

If I find out it’s a hard coded failure, I’ll leave. If I find out it’s fixable, I’ll leave, too. I’m only here because there’s no god damn answer in sight. I’m not settling for anything but a fast, respectable canvas. I don’t care about anything else.

He’s stated that he’s tested JUCE and that Cycling should just have already performed these tests. So, +1 to Zola. Let’s hope he comes through.


October 23, 2008 | 2:03 am

"If I find out it’s a hard coded failure, I’ll leave. If I find out it’s fixable, I’ll leave, too. I’m only here because there’s no god damn answer in sight. I’m not settling for anything but a fast, respectable canvas. I don’t care about anything else."

Wait.

If its fixable, you’ll leave, and if its not, you’ll leave too? Is that some sort of reverse psychology tactic they taught you at assassin school??


October 23, 2008 | 2:17 am

If it’s fixable, ie, the canvas can achieve fast speeds, and will at some point in the future, I’ll leave.

My sole reason for creating this account is to address my performance issues in Max 5. I don’t care about anything else. So, on the flipside, if it’s gonna stay slow forever, my job here is done, I’ll leave under that revelation, too.

Right now, we don’t know if speeding things up significantly is possible. We are in the dark about the matter. Zola’s assessment of JUCE seems to point that it’s borderline impossible, ie, it’ll only turn "very slow" to "slow", and not fast.

That’s what I want to know. That’s why we need JUCE benchmarks. That’s all that matters to me.


October 23, 2008 | 3:05 am

Quote:Zola
> "Some months back I was learning more about vector and wanted a firm grasp of all the operations, and so I put together a quick benchmark that runs through all of my documented vector operations in Qt and JUCE. Spitting all manner of shapes on screen, stacking xparent stuff up, spinning stuff around while zooming, messing with pens, etc. It was just a big ugly benchmark. But the results were astounding. In the best case scenarios– a few tests, JUCE was only 15 times slower than Qt. But commonly JUCE was 100 times slower than Qt. 40 times slower was a good average. The varied numbers were also influenced by flipping Qt between software, opengl, and direct3d modes. But all in all, JUCE’s performance couldn’t be taken seriously. Measurement in CPU usage rather than framerates was equally horrid. With OpenGL, Qt would use 6% CPU for awesome vector stuff, effectively making my GPU do all the work, whereas JUCE doing the same thing would peg my core to 95%. Qt’s software rendering of vector is also devastatingly faster than JUCE."

———————————————————————-

I mean, this statement could be an exaggeration. Zola might just want QT because he has an allegiance to it; it happens. There’s been a QT vs GTK war forever now.

Statistics wins the day.

This is really important.


October 23, 2008 | 9:00 am

I have to have a performance prepared for monday and so I’m too stressed this weekend. After then I’m free to do this work.

For illustrating JUCE’s benchmarks, people’d to need to be able to understand, verify, and compile the code themselves. So if the purpose here is to "show everyone" (regardless of if they’re a coder or not)

- Providing a binary doesn’t help.
- They’ll need usable project files for a certain platform (which? Somebody suggested XCode, I don’t use macs.)
- Qt isn’t going to work with VS Express (well maybe, I don’t know, I use QMake.. qt has been switching back and fourth between supporting vs express or not)
- You’re going to have to use the same compiler and same switches to compare, and so just loading one the project files that comes with JUCE isn’t enough. I’ll have to write a set of guidelines
- … i could set you up a Codeblocks project for JUCE
- After you download Qt, you’ll have to know how to modify Qt’s QMAKE platform files to setup all the flags, I’ll have to write about how to do that
- You’ll need to spend an hour compiling Qt, and you’ll need to compile JUCE and setup the lib files properly, and link it with my code
- I’ll have to go through stuff and make the code undebatable 1 to 1 compare or people will fuss.

After all this, are 2 people going to download the thing and even care or figure out how to set it up?

That’s why I recommended that CYCLING investigates the performance in a way which makes sense to them. JUCE is slow, and they can see for themselves. That’s what really matters.


October 23, 2008 | 9:49 am

Hola Zola,

Glad you showed, I was getting worried! I think you raise a really valid point saying you’re worried no one would test it. I’m not much of a coder, but I certainly will give it a shot. I also am concerned that others might not give a damn to the degree we do, seems to be that a lot of people are just fine with plain, ole, sluggish, mediocre Max 5.

I think what would be better is… create the project, and send it to Cycling. Don’t expect a reply though. Simultaneously, you could draw up a benchmark graph of sorts in some app with whatever fps or what not that you get per test, and that’ll be that. Like the link you posted:

http://zrusin.blogspot.com/2006/10/benchmarks.html

You have to understand that this very well will not change anything. I doubt Cycling will read the benchmarks and say "Damn, we gotta rewrite the whole thing now"… I’m sure they’d be just thrilled to know their beloved Max is 40 times slower on JUCE than QT. And, with the amount of denial we’ve both observed over Max 5 here from it’s users, I doubt many users wanna know their hard earned money was dished out on a lemon.

Still — I think you could put an end to all this once and for all. You’re 1 for 2.. Your Bill Gates email was a fantastic win for defending your value system. Now, this will could put you at 2/2.

What Cycling does with the data will be anyone’s guess. They may just ignore you to spite you simply for the fact that they hate you for having no respect for the hierarchy that governs this forum. Let’s not forget, that you were very adamant about your disdain for javascript, and that had plenty of benchmarks (which are slowly being reversed with the new JIT’s)… And Cycling turned a deaf ear to what I thought was an excellent case for the inefficiency of javascript as the de facto language in Max.

It’s up to you at this point. If it’s too much of a hassle to get it all together, don’t bother. For me, it would be great to nail the coffin shut on Max 5 — and having that data available would help finalize anyone’s decision whose had serious reservations and complaints up to this point. I know I’m sick of the whole god damn thing. I want to move on. I’m completely wore out. The program stinks. No one truly cares about that to actually take an offensive stance about it. Cycling won’t tell me if they’re gonna fix it. It’s the worst worst case scenario for Max 5 I could have imagined a year ago, lol. Everything is ass backwards. I am ashamed to have ever called myself a Maxer.

Just think, after you post your findings, we might hear the end of this issue once and for all. No more waiting til Max 5.x.x for a fix, no more sitting around wondering why Cycling just doesn’t understand that speed, above all else, is a great thing.

I hope your benchmarks are right. I’d really like to get back at Cycling for ruining such a great thing. I say, expose JUCE as a joke. Why the hell not?

All the best,
vux


October 23, 2008 | 11:39 am

Quote: vuxivil wrote on Thu, 23 October 2008 05:49
—————————————————-

> Still — I think you could put an end to all this once and for all. You’re 1 for 2.. Your Bill Gates email was a fantastic win for defending your value system. Now, this will could put you at 2/2.

> I hope your benchmarks are right. I’d really like to get back at Cycling for ruining such a great thing. I say, expose JUCE as a joke. Why the hell not?

—————————————————-

You seem to have an awfully adversarial relationship with c74. Let me ask you: do you treat any other companies this way?

Operator: Thanks for calling the phone company, how can I help you?

vuxivil: First of all, let me just tell you that your company is full of morons. You are probably an idiot too. There is a big problem with the way your shitty phone system works, and none of your engineers know how to fix it. My friend and I have benchmarked the shit out of your crappy phones, and we’re the only ones who are smart enough to fix it. So, why don’t you…

Operator: *click*

(vux calls back…)

Operator: Thanks for calling the phone company, how can I…

vuxivil: Don’t you dare hang up on me, you senile idiot! Do you know who you’re talking to? I’m the only guy in the world that can fix your phone system. Look, here’s the problem: when I pick my phone up off the handset, it takes a full 500 milliseconds for the dial tone to start. That is absolutely unacceptable and I won’t stand for it! I mean, 500 milliseconds? I’ve already dialed two numbers by the time I realize the dial tone hasn’t kicked in yet. Now listen, you retarded piece of shit, my friend and I have tried 52 phones in 14 states and the results are conclusive…

Operator: *click*

From reading your posts, I get the feeling that you’re probably about 16 or 17 years old, because you talk about things in such a way which implies that you don’t understand how things work in the real world. Even if max5pariah is right about JUCE, it’s too bad that he and you are such assholes, because if you were actually respectful, professional, and intelligent, somebody might have actually listened to you.

(Flashback to 1 year ago…)

Max5pariah: David Z., I have found a problem with the way you’re going about coding Max 5. Well, let me first say that the real problem is that you’re a senile retard. No, but really, here’s the benchmarks that I’ve…

David Z.: *click*

"If I find out it’s a hard coded failure, I’ll leave. If I find out it’s fixable, I’ll leave, too."

Uhh… why don’t you just leave then? If this thing could fall one way or another, but in both cases you’re going to leave, then why wait? Why waste precious seconds of your life if you know what you’re going to do anyway? Besides, you should be concentrating on your high school homework assignments, so that one day you can grow up to be a wicked cool and smart hacker, like max5pariah.


October 23, 2008 | 12:01 pm

SHUT UP AND GET A LIFE!

thanks.



Viewing 32 posts - 1 through 32 (of 32 total)