Shark Messages

[Nick]

I'm confused by this message in Shark when debugging my program:


This function has a large number of samples in its function prologue and epilogue, and/or the function is relatively short. Therefore, this function is a good candidate for inlining.

This load is probably in the same PPC970 dispatch group as a previous store to the same address. This causes a dispatch group rejection and flush on PPC970. To avoid this performance problem, you should move the load into a later dispatch group by inserting instructions (possibly no-ops) between the store and load. With gcc, try using -mtune=G5 or -fast to get better scheduling. With xlc/f, try using -qtune=g5.


The function it is referring to is:
void CallList() { glCallList(list); }

Can anyone tell me what this means and possibly how to remedy this in Xcode?

[OneSadCookie]

firstly, each paragraph is a separate message.

The first paragraph means that the function is too small, and suggests you inline it to improve performance. The improvement can be dramatic if you're calling it a lot, and it's a nice and easy one to implement.

For the second, you'll have to look at the assembly to know precisely what it's talking about, but it might well be fixed (or at least improved in many cases) by the inlining. Start there.

[Nick]

Well I tried inlining the function but I still get the same messages and slow frame rates as before. I tried the compiler flags the message listed but none worked to increase my frame rate. Any other suggestions? The assembly isn't helping me much right now, either so I'm at a slight loss.

I assumed the second message meant two things were trying to use the same space in memory but none of the addresses are the same as far as I can see.

If anyone would like to help me out and needs to see what I'm seeing, you can download my current build from my website.

[wadesworld]

I'm not promising I'll have time to help, but I'll take a look.

Give me a link to the project.

Wade

[TomorrowPlusX]

Well I tried inlining the function but I still get the same messages and slow frame rates as before.

Actually, this always concerned be -- and it probably shows that I don't really grok shark well enough -- but as far as I can tell if you want to see detailed information in shark you've got to have debug build enabled, which as far as I know prevents inlining and a lot of other optimizations from occurring.

So, you may inline the function, and it may be a big boost for your deployment build, but when you shark you'll still have to run the development build.

So, I'm wondering, can you build will full optimizations but still have debug symbols?

[arekkusu]

Yes, you can make a fully optimized Deployment build with the debug symbols left in.

Nick, the second message only applies to code running on a G5.

[OneSadCookie]

nick, your attempt at inlining clearly failed, if you're still getting the same message; either that or you're running a debug build...

[aarku]

Add -O3 and -finline-limit=99999 to your GCC flags and that'll inline the 'mutha. . . and almost surely slow everything down . . . ;-) . . . but that better make that particular message go away.

-Jon

[aarku]

Yes, you can make a fully optimized Deployment build with the debug symbols left in.

Nick, the second message only applies to code running on a G5.

Just a note that leaving debug symbols in -g , and profiling -pg in can have a small performance hit.

-Jon

[OneSadCookie]

-pg is a substantial performance hit, -g shouldn't be a big one. Basically, there's no reason ever to use -pg on the Mac, we have Shark and Sampler which do a much better job.