availability of ppc_intrinsics

Sage
Posts: 1,199
Joined: 2004.10
Post: #1
All

I recently optimized some verlet-integration type code *massively* using some ppc intrinsics macros ( specifically, __frsqrtes and __fres ). I gather from the header docs that these calls aren't available on all G4 platforms.

Is there any run-time way to determine availablity? The speedup is significant enough that I don't want to have to give it up entirely -- e.g., my code runs about 50% faster!
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #2
They are available on all G3/G4/G5s. Some aren't available on the PPC 601, but that doesn't matter (601 can't run OS X.)

What does matter is that the estimated accuracy differs, and it is lower on the G5 than the G4 (but G5 has a real sqrt instruction...)
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
I'm just wondering where you do sqrt() and division with Verlet integration?
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #4
DoG Wrote:I'm just wondering where you do sqrt() and division with Verlet integration?

Well, it's not a "real" verlet integration, it just happens that the output looks a lot like VI. I'm doing flocking simulation for a game, and it happens to involve a fair amount of positioning rules for the entities, stuff like "go this way for food, but avoid others, & avoid enemies, can't-pass-through-obstacles etc". When drawn as dots and force-lines, it ends up looking a lot like the diagrams used in VI articles. It also happens to result in "bodies" of entities which act a lot like semi-rigid solid masses ( if you tune the forces to do so -- I don't want the game to act that way, however )

[Image: Hoard2.png]

Anyway, the stepping logic performance doubled when using ppc_intrinsics.

P.S. I know there's ways to balance out the need for sqrt and division in VI. But it's not necessarily applicable where I am.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #5
note: try MenuMeters instead of Activity Monitor.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #6
arekkusu Wrote:note: try MenuMeters instead of Activity Monitor.

Why? I generally keep AM running so I can kill a zombie, even if the dock's foobar'd. And I do my profiling with Shark. AM's just there for safety, and for general observation ( e.g., I can see at a glance that running my game uses about 50% CPU, even at 30fps ) -- but I'd never use AM for profiling Wink

What does MenuMeter's provide?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #7
A CPU history graph in the menu bar. I use it for exactly the same purpose-- see at a glance when something is eating too much CPU, real profiling with Shark:
[Image: menumeters.png]
It also can monitor network, memory, and disk, with various display options.
It's free, and open source. Worth checking out.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #8
I installed it, but I'll confess the "thermometer" CPU bar ( which is the only thing I'd be interested in ) fights with the carefully attained feng-shue ( spelling? ) of my desktop Wink

I think if it proves useful, I may patch it to look a little nicer and see if Alex is interested in some diffs.

These things matter to me! Back when I ran linux, I submitted several patches to KDE to "clean up" the layout ( pixel-alignment for some things, sub-pixel antialiasing in the analog clock, etc ). It's all in the details.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #9
In fact, now that I think about it, the time-graph of CPU usage looks like a really, *really* good thing. But hot damn it's an ugly one. I'll see what I can do.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #10
I've already submitted some patches for the net meter, but yes, there is still much to do.
Quote this message in a reply
Post Reply