Paul Greyson

I just started looking at 1.6 and I'm seeing a significant drop in performance relative to 1.5.

e.g., on my Powerbook G4, with the jit.gl.render-over-movie.pat (changed to "metro 5" to test for max performance) I get 90fps with 1.5 compared to only around 50fps with 1.6.

Performance options for the two apps are identical. Any thoughts?

I just started looking at 1.6 and I'm seeing a significant drop in performance relative to 1.5. 

poor-jitter-1-6-ppc-performance

On Sep 7, 2006, at 11:08 AM, Paul Greyson wrote:

> I just started looking at 1.6 and I'm seeing a significant drop in 

If you don't need UB, you might as well just use 1.5.3, which is the 

same codebase as 1.6. Or does 1.5.3 CFM have the same performance issue?

> e.g., on my Powerbook G4, with the jit.gl.render-over-movie.pat 

> (changed to "metro 5" to test for max performance) I get 90fps with 

> 1.5 compared to only around 50fps with 1.6.

> Performance options for the two apps are identical. Any thoughts?

Make sure overdrive setting is the same, and that jit.window @sync is 

disabled. Otherwise, I'd say shark it, and see what the profile looks 

We've found somethings faster and some things slower with XCode 

compiled code. Despite the same source code, there is markedly 

different machine code being generated under the hood.

>
> I just started looking at 1.6 and I'm seeing a significant drop in  
> performance relative to 1.5.

If you don't need UB, you might as well just use 1.5.3, which is the  
same codebase as 1.6. Or does 1.5.3 CFM have the same performance issue?

> e.g., on my Powerbook G4, with the jit.gl.render-over-movie.pat  
> (changed to "metro 5" to test for max performance) I get 90fps with  
> 1.5 compared to only around 50fps with 1.6.
>
> Performance options for the two apps are identical. Any thoughts?

Make sure overdrive setting is the same, and that jit.window @sync is  
disabled. Otherwise, I'd say shark it, and see what the profile looks  
like.

We've found somethings faster and some things slower with XCode  
compiled code. Despite the same source code, there is markedly  
different machine code being generated under the hood.

On Sep 7, 2006, at 1:24 PM, Paul Greyson wrote:

Beta posted here on the Jitter forum a few weeks ago...

https://cycling74.com/forums/index.php?t=msg&goto=78212

I see. I assume there will never be an official 1.5.3 release then?

Also, from your response it seems that I shouldn't expect PPC performance to be a focus for Jitter in future releases?

On Sep 7, 2006, at 1:58 PM, Paul Greyson wrote:

> I see. I assume there will never be an official 1.5.3 release then?

Don't know why you'd make that assumption. It's just in it's beta 

stage. UB was a development priority for us, since MacTel users had 

*no* version to use natively. We're now catching up with XP and CFM 

release. After we feel the CFM and XP versions have been tested 

thoroughly enough, they will be made public. Unless we really screw 

things up, 1.5.3 will be our final CFM release for use with 4.5.X.

> Also, from your response it seems that I shouldn't expect PPC 

> performance to be a focus for Jitter in future releases

This is not true. However, you can definitely assume that we're not 

going to hand code assembly to get the same level of performance in 

all instances that we previously got from Code Warrior. It just 

happens to be that in certain cases CW generates faster PPC code than 

does gcc. I have no idea if that's even the issue with this 

FWIW, there are other places where gcc outperforms CW. I just meant 

to say that we're using a different compiler, so in some 

circumstances performance will be different (even with all the whiz 

bang compiler optimizations) and that's as far as we're going to go 

with it. We're happy to investigate performance discrepancies to 

ensure that we've not screwed things up somewhere, if you can get us 

detailed information. I'll probably test that patch at some point on 

a PPC machine, but let us know anything else you find out.

Don't know why you'd make that assumption. It's just in it's beta  
stage. UB was a development priority for us, since MacTel users had  
*no* version to use natively. We're now catching up with XP and CFM  
release. After we feel the CFM and XP versions have been tested  
thoroughly enough, they will be made public. Unless we really screw  
things up, 1.5.3 will be our final CFM release for use with 4.5.X.

> Also, from your response it seems that I shouldn't expect PPC  
> performance to be a focus for Jitter in future releases

This is not true. However, you can definitely assume that we're not  
going to hand code assembly to get the same level of performance in  
all instances that we previously got from Code Warrior. It just  
happens to be that in certain cases CW generates faster PPC code than  
does gcc. I have no idea if that's even the issue with this  
particular patch or not.

FWIW, there are other places where gcc outperforms CW. I just meant  
to say that we're using a different compiler, so in some  
circumstances performance will be different (even with all the whiz  
bang compiler optimizations) and that's as far as we're going to go  
with it. We're happy to investigate performance discrepancies to  
ensure that we've not screwed things up somewhere, if you can get us  
detailed information. I'll probably test that patch at some point on  
a PPC machine, but let us know anything else you find out.

Okay. Thanks Joshua. Sorry if my response seemed a bit despondent. I'd like to switch to 1.6 and get my externals ported to mach-o but this cfm performance problem has me spooked.

I'll see if I can make a stripped down patch that demonstrates the performance difference.

btw, unless I've screwed up somehow, the 1.5.3 beta 2 reports "beta 1" to the Max window on launch.

Assuming I really installed beta 2, then I can confirm that the performance drop is limited to 1.6 and does not occur with 1.5.3.

btw, unless I've screwed up somehow, the 1.5.3 beta 2 reports "beta 1" to the Max window on launch. 

On Sep 7, 2006, at 4:40 PM, Paul Greyson wrote:

> I'll see if I can make a stripped down patch that demonstrates the 

Cool. Don't forget to make sure you have VBL sync off and that your 

> btw, unless I've screwed up somehow, the 1.5.3 beta 2 reports "beta 

> Assuming I really installed beta 2, then I can confirm that the 

> performance drop is limited to 1.6 and does not occur with 1.5.3.

On Sep 7, 2006, at 4:40 PM, Paul Greyson wrote:
> I'll see if I can make a stripped down patch that demonstrates the  
> performance difference.

Cool. Don't forget to make sure you have VBL sync off and that your  
overdrive settings are the same.

> btw, unless I've screwed up somehow, the 1.5.3 beta 2 reports "beta  
> 1" to the Max window on launch.

> Assuming I really installed beta 2, then I can confirm that the  
> performance drop is limited to 1.6 and does not occur with 1.5.3.

Okay. Here's a very simple patch which runs at 200fps under 1.5.3 but only around 100fps under 1.6

I tried your patch with OSX 10.4.7 on a PB 1.67. Here are my results:

I also tried a few variations. If I make the matrix a 4 char 640 480

If I make the matrix 4 char 1024 768 I get this:

Looking at the profiles of both programs running this last test in

Shark provides some interesting insights. First, in both cases the

majority of the program time was spent in Quickdraw with the following

The total time spent in MaxMSP and Jitlib were essentially negligible

and identical. I won't claim to be an expert on profiling here, but

from the looks of it, I don't think the slowdown is in MaxMSP/Jitter.

Now, if I take away the pwindow, I get *both* 1.5.2 and 1.6 to max out

at 200fps (w/ metro 5) and a 4 char 1000 1000 matrix. And since I'm

crazy :) I did metro 1 and got them both to max out at 500fps. I

guess the moral of the story is...don't use pwindows when you don't

have to in 1.6 because the Quickdraw API is slower in macho than in

Here's the patch I used to shark things with. It has a 30 second

cutoff so that the profiles for 1.6 and 1.5.2 are at least measuring

> Okay. Here's a very simple patch which runs at 200fps under 1.5.3 but only around 100fps under 1.6

> #P user jit.fpsgui 134 157 60 196617 0;

> #P user jit.pwindow 32 158 87 14 0 1 0 0 1 0;

Hi Paul,
I tried your patch with OSX 10.4.7 on a PB 1.67.  Here are my results:

I also tried a few variations.  If I make the matrix a 4 char 640 480
matrix, I get this:

Looking at the profiles of both programs running this last test in
Shark provides some interesting insights.  First, in both cases the
majority of the program time was spent in Quickdraw with the following
breakdown:

The total time spent in MaxMSP and Jitlib were essentially negligible
and identical.  I won't claim to be an expert on profiling here, but
from the looks of it, I don't think the slowdown is in MaxMSP/Jitter.

Now, if I take away the pwindow, I get *both* 1.5.2 and 1.6 to max out
at 200fps (w/ metro 5) and a 4 char 1000 1000 matrix.  And since I'm
crazy :) I did metro 1 and got them both to max out at 500fps.  I
guess the moral of the story is...don't use pwindows when you don't
have to in 1.6 because the Quickdraw API is slower in macho than in
PPC.

Here's the patch I used to shark things with.  It has a 30 second
cutoff so that the profiles for 1.6 and 1.5.2 are at least measuring
approximately the same thing.

On 9/8/06, Paul Greyson  wrote:
>
> Okay. Here's a very simple patch which runs at 200fps under 1.5.3 but only around 100fps under 1.6
>
> max v2;
> #N vpatcher 275 103 548 343;
> #P origin 14 0;
> #P window setfont "Sans Serif" 9.;
> #P user jit.fpsgui 134 157 60 196617 0;
> #P toggle 93 44 15 0;
> #P window linecount 1;
> #P newex 92 70 46 196617 metro 5;
> #P newex 92 98 53 196617 jit.matrix;
> #P user jit.pwindow 32 158 87 14 0 1 0 0 1 0;
> #P connect 1 0 0 0;
> #P connect 3 0 2 0;
> #P connect 2 0 1 0;
> #P connect 1 0 4 0;
> #P pop;
>


Poor Jitter 1.6 PPC performance?