Cocoa speeds

DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #16
Quote:Originally posted by Damian
Doubtless you know, but for any newbies reading this thread, you can of course use Carbon functions in a Cocoa app.

Cocoa is great for GUI-intensive games (e.g. turn-based strategy or cards) which by their nature don't have to run fast anyway. For intensely graphical games, what matters is the centre of the loops, which will be calling the same OpenGL, QuickDraw or QuickTime code no matter what language the app is written in.

You can use NSQuickDrawViews in a Cocoa GUI, getting the best of both worlds if you want. Games generally run faster under OS 9 because of co-operative multitasking. A high performance game can simply not co-operate, hogging the CPU. OS X's pre-emptive multitasking doesn't let you get away with that. Thus even Carbon games can be faster under OS 9 vs X.


You are blaming pre-emptive multitasking for too much. It is not taking away more than a few percent performance when the game is the only thing running. The fact that some games are more than 50% slower on X is because certain OS calls hog the CPU more because of the UNIX part of the OS (safer but slower), or are really poorly optimzed, or both.

- D.G
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #17
I agree, quartz is painfully slow.
I found OpenGL and now Cocoa with fast graphics is very easy to realize.

I ported CocoaSpriteKit's examples to my CocoaBlitz framework and they ran more than 600% faster. I think Quartz graphics are the biggest hangup for Cocoa games. Go OpenGL.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #18
Quote:Originally posted by DoooG
And it is hell slower for OpenGL, too! I can play war3 in OS 9 1024x768 full detail, but it is already barely playable on 800x600 lowest detail in X. The same goes for all other games, where q3a seems to be the least affected, though it still is.

- D.G


Warcraft3 is carbon. I'm not sure what you are trying to say. OS X is slower than OS 9? carbon slower that cocoa? opengl slower than.... opengl?
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #19
Quote:Originally posted by skyhawk
Warcraft3 is carbon. I'm not sure what you are trying to say. OS X is slower than OS 9? carbon slower that cocoa? opengl slower than.... opengl?


Yes/no/yes. I don't know how to explain, but OS X does a lot of things behind the curtains which OS 9 just didn't. It's unix, so I am not saying what it does is bad, its just bad for games, it seems.

The hardware is more abstracted under X than 9, so any "direct" hardware calls have some kind of performance penalty, because of the needed book-keeping, which simply wasn't there before. This leads to better fault tolerance in the OS, but also incurs some performance penalty. So, in fact, most OpenGL calls are most likely to be slower on X than 9.

- D.G
Quote this message in a reply
Jens
Unregistered
 
Post: #20
Quote:Originally posted by OneSadCookie
That's what they'd like to make you think...

The truth is that object-oriented design has significant overhead. I wouldn't make a Vector3D class (for a 3D game) in C++ any more than I would in Objective C (although it would be faster in C++).


I certainly would make a Vector3D class in C++. I don't know how much overhead you get in Obj-C, but in theory C++ should give you pretty much zero. Having no virtual functions and using only inlined functions for critical operations should give you, as a programmer, just an abstraction layer. When compiling, all this abstraction will be expanded, leaving only highly efficient code.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #21
There is an article on http://www.flipcode.com about a vector class optimized throught the use of templates and how it affects the assembly code. It seems you can get a gain in execution speed, but the amount of work really doesn't justify the gain in my opinion.

Time is running out!
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #22
and a bloated program, you can(should) not inline every function. if there is a speed problem, you should perhaps think of a better way to write your code and not rely on "inlining" or "using <<1 instead of *2 Those are really insignificant speed boost. Restructuring code and using better data structures is where you get 5-10x speed boost.
Quote this message in a reply
Jens
Unregistered
 
Post: #23
Quote:Originally posted by skyhawk
and a bloated program, you can(should) not inline every function. if there is a speed problem, you should perhaps think of a better way to write your code and not rely on "inlining" or "using <<1 instead of *2 Those are really insignificant speed boost. Restructuring code and using better data structures is where you get 5-10x speed boost.


I think vectors is a very good example on when you should use templates and inlining. It will not bloat your code the least. All it does is that is wraps up the operations you would perform anyway, in a nice package.

A can agree that using "<<1 instead of *2" is a really silly thing to do since it makes the code harder to read, and simply does the job any decent compiler would do for you anyway.

I also agree that restructuring code and using better data structures is where you can get real speed boosts, but I would really consider a vector class to belong to those.
Quote this message in a reply
Member
Posts: 104
Joined: 2002.04
Post: #24
On modern (read Mac OS X) operating systems, you should always optimize for object size, not speed. In most cases, the real bottleneck in any good sized app is related to memory locality. By inlining all of your functions, you grow the object size. So, you may reduce a function call which can save you 10 cycles, but because of code bloat, you need to page in the next set of memory for a 10,000 cycle wait... oops.

This also goes for unrolling loops. In some (I would argue pathological) cases, unrolling a tight loop that is run through many, many times can give you a slight performance gain. But in those cases, you are better off spending your time doing AltiVec optimizations.

I guess what I'm trying to say, is try not to outclever the compiler, add the -Os flag to your compiles (same as -O2, but doesn't optimize if object size would grow) and don't sweat the small stuff
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #25
-O3 -funroll-loops is almost always faster than -Os, despite (because of) automatically inlining functions and unrolling loops. For the performance-critical parts of your code, the overhead of the loop condition testing and backward branches will usually overshadow the work done in the loop. For infrequently-called code, -Os is better.

The December Project Builder allows changing compilation flags on a per-file basis. You should be able to use this to set -Os for most of the files in your project, but override with -O3 -funroll-loops for the performance-critical files.
Quote this message in a reply
Member
Posts: 104
Joined: 2002.04
Post: #26
Quote:Originally posted by OneSadCookie
-O3 -funroll-loops is almost always faster than -Os, <snip>


This is true when you measure that one object file compiled with -O3 -funroll-loops. However, with large projects, you will almost always negatively impact overall performance (particularly in the areas of "percieved" performance such as launch time and context switching) by optimizing for "speed" over size.

Now, I agree that with some limited, (almost pathological Wink cases) you can see improvements by changing the optimization flags for particular object files. However, and I believe OSC will back me up on this, if you do this, you must rigorously profile and measure your code performance to justify any increase in object size for "performance"

edit: I should also add that I argued vehemently against this in our company until people much, much smarter than me convinced me otherwise. Now I'm the poster child.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #27
Actually, I'd be inclined just to switch to -O3 -funroll-loops, with a quick test to make sure it does seem faster than -Os. If you can actually tell that some things are slower and some are faster (which I doubt), then you could change the settings per-file.

This isn't simply a pathological case, most games have just such performance-critical areas. For a business application, I agree you'd almost never want anything other than -Os.
Quote this message in a reply
Member
Posts: 75
Joined: 2002.04
Post: #28
Quote:Originally posted by skyhawk
I don't mean to get off on a rant here, but Cocoa is NOT slow. Yes, like ANY programming language, it CAN be slow, but it does not have to be.
Cocoa is not a programming language, dude. I think you are saying that the Cocao framework implementation is fast... maybe that quartz is not slow? Or could you be talking about Objective-C or Java?

Quote:Also, BOB2 got 150fps on a 400MHz G4
"Fast" seems to be relative. Maybe using a different language and framework you could get BOB2 running at 300fps on a 400MHz G4, in which case Cocoa would seem slow. But compared to other implementations it is fast. Unless you have some absolute measure of "fast", you might want to stick to comparitive superlatives (ie: "Cocoa using Objective-C is faster than Carbon using C++ for this specific (or possibly general) task")

Quote:BOB2 does not use sprites
I call those little space-ship things sprites. You might call them OpenGL quads or something else (particles??), but we'd be referring to the same thing.

Quote:Originally posted by DamianDoubtless you know, but for any newbies reading this thread, you can of course use Carbon functions in a Cocoa app.
Say what? Do you mean you can call both the Carbon and Cocoa frameworks from the same program? Yes (in which case, I wouldn't call it a "Cocoa app").

Quote:Originally posted by kelvinI ported CocoaSpriteKit's examples to my CocoaBlitz framework and they ran more than 600% faster. I think Quartz graphics are the biggest hangup for Cocoa games. Go OpenGL.
I agree. Though now with Extreme Quartz, isn't Quartz using OpenGL to render, and therefore should be nearly the same as direct OpenGL calls? I wouldn't know.

Many language specifications are not the cause of that language being inherently slower than others, it is often times the implementation of that language -- how good the compiler is -- which cause the differences. And using a specific or low-level API instead of a general, high-level API, I bet would get you better performance (at the cost of ease of use, of course -- which is why OpenGL may be better suited for games than Quartz).

But, in any case, choose the best existing tool for the job, and if it works then great! And if not, then make yourself a new tool.

Chris Burkhardt
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #29
Every Cocoa app already calls various Carbon functions under the hood... I'd decide which category (Carbon or Cocoa) to put an app in based on what the majority of its event handling/GUI was written in. To stop calling it a Cocoa app simply because it calls FSPathMakeRef() or HideMenubar() seems ridiculous.

Quartz Extreme only accelerates surface composition, not general drawing tasks. Drawing your bezier path is just as much in software as it always was.

I think DoooG meant that the combination of Cocoa/Objective C wasn't slow, but I (and most other people) took that as a given... picking on him for saying "Cocoa" rather than "Cocoa/ObjC" seems rather pedantic.

[edit -- whoops, that should'a been skyhawk. Sorry skyhawk, DoooG Blush ]
Quote this message in a reply
ibullard
Unregistered
 
Post: #30
You know, BASIC on the Commodore 64 isn't slow. I wrote several small games that ran at 30fps on it so I don't know why anyone would say it's slow.

I also don't get why people say Pascal on a 486SX is slow. I wrote several text games with it in high school that ran as fast as you could type.

I know, sarcasm is the last resort of a weak mind but the topic is moot. The basic fact is that any language/computer combination is "fast enough" for some type of game.

However, some languages do tend to make it difficult to implement performance sensitive games. Try to make a 3D engine purely in Obj-C and I'm sure you'll see why people say it's slow.

The best situation I've run across so far is a core engine written in C/C++ that can be called from a higher level scripting language. I'm sure that if you wrote a 3D engine in C++ and then did all your gameplay programming in Obj-C you'd be able to make a fast 3D game and get the benifits of both.
Quote this message in a reply
Post Reply