macOS Can Cocoa overhead be circumvented?

[StudSinister]

I'm not a Mac developer. In fact, one could consider me "the enemy" as I've been doing .NET development on Windows for the past 5 years.

Nevertheless, I have no loyalty to any particular platform; they are tools, not religions. And I do concede that Mac OS X is superior (in many ways) to the Windows OS.

I've been tinkering around with Cocoa and, well, I have some questions. I've looked around on the internet and haven't had much luck with them.

1. Why did Apple choose to go with Objective-C as opposed to Objective-C++? Although I haven't programmed in it much, isn't Carbon based on C++? That seems like a bizarre migration path.

2. Is the difference between Cocoa and Carbon in any way analogous to the difference between the unmanaged and managed environments in .NET?

I'm guessing since most Mac programmers consider anything Microsoft-centric to be deleterious, an explanation is in order. Of the .NET languages that are bundled with Visual Studio, only Visual C++ can (easily) use the unmanaged memory. Being a bit of a performance junkie, the "messaging" aspect (which seems like forced late-binding on every function call and object invocation) seems a bit much -- especially if you can't easily circumvent it. For most applications, it wouldn't make much of a difference, but for something like games, it could make a difference.
When I look at sites like http://www.clanmacgaming.com/macosx.php and see how few games are written in Cocoa, it makes me wonder.

That does seem to be an old list, though.

3. Can Objective-C have anywhere near the performance (when using the Foundation libraries) that a regular C program could? Is it possible to use malloc or 'new' for classes written using the Objective-C/Objective-C++ notiation (@implementation, @interface, etc.)?


Thanks in advance

 

[Sun Baked]

You have to remember that OS X was kickstarted by NeXT in the 1980s ... so some of the choices (like Objective-C) were simply due to timing.

Edit...

Cocoa is the modern version of the old NeXT tools, with the Mac stuff bolted on.

Carbon is a migration of the old Mac Toolbox APIs, which let people migrate their old legacy codebase over to OS X.

 

[StudSinister]

You have to remember that OS X was kickstarted by NeXT in the 1980s ... so some of the choices (like Objective-C) were simply due to timing.

Edit...

Cocoa is the modern version of the old NeXT tools, with the Mac stuff bolted on.

Carbon is a migration of the old Mac Toolbox APIs, which let people migrate their old legacy codebase over to OS X.

Ok, I guess my main question is can I circumvent any of the overhead that seems intrinsic with Objective-C? Can your program be compiled a certain way to use early-binding?

 

[Fukui]

I'm not a Mac developer. In fact, one could consider me "the enemy" as I've been doing .NET development on Windows for the past 5 years.

1. Why did Apple choose to go with Objective-C as opposed to Objective-C++? Although I haven't programmed in it much, isn't Carbon based on C++? That seems like a bizarre migration path.

2. Is the difference between Cocoa and Carbon in any way analogous to the difference between the unmanaged and managed environments in .NET?

3. Can Objective-C have anywhere near the performance (when using the Foundation libraries) that a regular C program could? Is it possible to use malloc or 'new' for classes written using the Objective-C/Objective-C++ notiation (@implementation, @interface, etc.)?

Thanks in advance

1: Objective C can do many things extremely easily that C++ (in the language itself) cannot do such as message forwarding and loose typing (no typing at all as far as objects are concerned) and its implemented in C, unlike C++ wich adds C compatibility, Obj-C is the other way around. One thing Obj-C does not have is multiple inheritence, but I consider this an advantage. That and Obj-C is very very simple extention to C; C++ is very complicated.

2:Carbon is the old mac os API's from OS9 and OS8 and earlier (toolbox) that are largely procedural, what Carbon does though is mix Core Foundation and base extentions to this old toolbox API on Corefoundation wich uses Opaque objects in a procedural way. Both Cocoa and Carbon (not older API's from before OS9) are largely based on Core Foundation Objects.

3:Objective C itself, yes can get close to C performance by caching a pointer to the method (wich is actually just a C function anyways) and calling that directly instead of using the messaging system. But if your code calls library code, it may not be worth it. In tight loops you can use just plain C anyways if you need to...

In my experience that kind of optimization is a waste of time becuase unless your working on something that has no solution in cocoa the API's can do it for you in say one line of code. If you really need performance in one specific part of your own code, you can just make a C-callback or an inline function just fine.

If you wanna see the diff between cocoa and .Net just look at Core Image, Core Data, Cocoa Bindings, and NSView/Appkit. Apple doesn't have retained vector graphics yet like Avalon, but they have had vector drawing since 1988 in NextStep!

If your interested in hard-core optimization:Look Here its very interesting

 

[GeeYouEye]

I'm not a Mac developer. In fact, one could consider me "the enemy" as I've been doing .NET development on Windows for the past 5 years.

Nevertheless, I have no loyalty to any particular platform; they are tools, not religions. And I do concede that Mac OS X is superior (in many ways) to the Windows OS.

I've been tinkering around with Cocoa and, well, I have some questions. I've looked around on the internet and haven't had much luck with them.

1. Why did Apple choose to go with Objective-C as opposed to Objective-C++? Although I haven't programmed in it much, isn't Carbon based on C++? That seems like a bizarre migration path.

Carbon is a library of C functions, often used in C++ programs, which provides access to Macintosh legacy API's. That said, it's not inherently any less native than Cocoa. Cocoa is Objective-C because it's descended from OpenStep which is descended from NeXT, which picked Objective-C 20 years ago. Which doesn't stop you from using Objective-C++ in programming, but the way you ask the question, I have to wonder if you know exactly what Objective-C++ is. Objective-C++ is not a language itself per se, but it's a way to use both languages in in the same program with a limited amount of class-level integration. The runtimes are completely separate.

2. Is the difference between Cocoa and Carbon in any way analogous to the difference between the unmanaged and managed environments in .NET?

AFAIK, no. It's closer to the difference between .NET and the Win32 API (but Carbon is procedural C, not C++).

I'm guessing since most Mac programmers consider anything Microsoft-centric to be deleterious, an explanation is in order. Of the .NET languages that are bundled with Visual Studio, only Visual C++ can (easily) use the unmanaged memory. Being a bit of a performance junkie, the "messaging" aspect (which seems like forced late-binding on every function call and object invocation) seems a bit much -- especially if you can't easily circumvent it. For most applications, it wouldn't make much of a difference, but for something like games, it could make a difference.
When I look at sites like http://www.clanmacgaming.com/macosx.php and see how few games are written in Cocoa, it makes me wonder.

That does seem to be an old list, though.

The right tools for the right job. You're most likely to see games written in straight C and/or OpenGL, and given a wrapper in Cocoa. Objective-C was originally used for simulations (although the first web browser was written in it), not games. Actually though, the main reason for not using Objective-C in games is because the Cocoa API simply wasn't designed with games in mind. Foundation and AppKit. Not Foundation and GameKit . You would have little difficultly in adapting the Foundation framework to any non-graphical aspects of the game, but I'd hate to write the graphics for a game using NSImage and NSAnimation.

3. Can Objective-C have anywhere near the performance (when using the Foundation libraries) that a regular C program could? Is it possible to use malloc or 'new' for classes written using the Objective-C/Objective-C++ notiation (@implementation, @interface, etc.)?


Thanks in advance

For C++ classes, in or out of Objective-C++, new is just fine. As something of a convenience, there's also the +new message that you can send to a Class object that is basically a shortcut for alloc/init (and is probably implemented as as such: +new { return [[NS<whatever> alloc] init]; } )

As for performance, there actually are ways of killing the runtime dynamism through manual IMP caching. I don't offhand know quite enough about the runtime to tell you how to do it, but the folks over at cocoadev.com probably do. Long story short, it strips away the Objective- part of it and lets you invoke an object's method implementation directly.

That said, it's not diminishing returns to do it, but close. The overhead of a message send vs. a function call is only 2-3x (after the first few seconds of the program running, almost always 2x). Given that you can write an Obj-C program in 50 to 10% of the time and lines of code, and that there's relatively easy multithreading built in to Foundation... it just doesn't usually matter so much.

 

[broken_keyboard]

Objective-C is very lightweight compared to .NET or Java.

It just consists of a precompiler which translates the Objective-C source in to plain old C, but including some calls to it's own runtime support library. This library keeps track of what objects you create and handles message passing.

The key point is: there is no virtual machine or bytecodes etc. What the compiler spits out is no different to what a straight C program would come out as, except it includes calls to this runtime library. So if you ever feel the need for max performance, just stop using objects for a moment and code in plain C right there in the Objective C source.

 

[StudSinister]

The key point is: there is no virtual machine or bytecodes etc. What the compiler spits out is no different to what a straight C program would come out as, except it includes calls to this runtime library. So if you ever feel the need for max performance, just stop using objects for a moment and code in plain C right there in the Objective C source.

That is a good point. Hmmm, I guess I need some practice. I've had "object-oriented design" rammed down my throat so much that I've almost forgot how to program without it.

 

[StudSinister]

Carbon is a library of C functions, often used in C++ programs, which provides access to Macintosh legacy API's. That said, it's not inherently any less native than Cocoa. Cocoa is Objective-C because it's descended from OpenStep which is descended from NeXT, which picked Objective-C 20 years ago. Which doesn't stop you from using Objective-C++ in programming, but the way you ask the question, I have to wonder if you know exactly what Objective-C++ is. Objective-C++ is not a language itself per se, but it's a way to use both languages in in the same program with a limited amount of class-level integration. The runtimes are completely separate.

I do recall reading about how you can't mix the class hierarchies, but I did get the impression it was syntactically different enough from Objective-C that it could be considered another language.

For example, Objective-C++ seems to support name-mangling and namespaces.

AFAIK, no. It's closer to the difference between .NET and the Win32 API (but Carbon is procedural C, not C++).

Intuition tells me you're probably right on this.

The right tools for the right job. You're most likely to see games written in straight C and/or OpenGL, and given a wrapper in Cocoa. Objective-C was originally used for simulations (although the first web browser was written in it), not games. Actually though, the main reason for not using Objective-C in games is because the Cocoa API simply wasn't designed with games in mind. Foundation and AppKit. Not Foundation and GameKit . You would have little difficultly in adapting the Foundation framework to any non-graphical aspects of the game, but I'd hate to write the graphics for a game using NSImage and NSAnimation..

Now if only there were some good Mac OS X specific books that demonstrated how to do this. I know Pangea has a book out, but I don't think it's based on Cocoa at all. I'll probably order it eventually anyway.

As for performance, there actually are ways of killing the runtime dynamism through manual IMP caching. I don't offhand know quite enough about the runtime to tell you how to do it, but the folks over at cocoadev.com probably do. Long story short, it strips away the Objective- part of it and lets you invoke an object's method implementation directly.

That said, it's not diminishing returns to do it, but close. The overhead of a message send vs. a function call is only 2-3x (after the first few seconds of the program running, almost always 2x). Given that you can write an Obj-C program in 50 to 10% of the time and lines of code, and that there's relatively easy multithreading built in to Foundation... it just doesn't usually matter so much.

The IMP caching is demonstrated in a book I read by Scott Anguish. (I can't recall the title, oddly enough. I think it was something bland like Cocoa Programming or something. I read it quite some time ago.) I believe he said that techniques like that should only be used if you're doing a lot of function calls in a tight loop...

Something about this admonishment didn't feel right.

 

[StudSinister]

1: Objective C can do many things extremely easily that C++ (in the language itself) cannot do such as message forwarding and loose typing (no typing at all as far as objects are concerned) and its implemented in C, unlike C++ wich adds C compatibility, Obj-C is the other way around. One thing Obj-C does not have is multiple inheritence, but I consider this an advantage. That and Obj-C is very very simple extention to C; C++ is very complicated.

2:Carbon is the old mac os API's from OS9 and OS8 and earlier (toolbox) that are largely procedural, what Carbon does though is mix Core Foundation and base extentions to this old toolbox API on Corefoundation wich uses Opaque objects in a procedural way. Both Cocoa and Carbon (not older API's from before OS9) are largely based on Core Foundation Objects.

3:Objective C itself, yes can get close to C performance by caching a pointer to the method (wich is actually just a C function anyways) and calling that directly instead of using the messaging system. But if your code calls library code, it may not be worth it. In tight loops you can use just plain C anyways if you need to...

In my experience that kind of optimization is a waste of time becuase unless your working on something that has no solution in cocoa the API's can do it for you in say one line of code. If you really need performance in one specific part of your own code, you can just make a C-callback or an inline function just fine.

If you wanna see the diff between cocoa and .Net just look at Core Image, Core Data, Cocoa Bindings, and NSView/Appkit. Apple doesn't have retained vector graphics yet like Avalon, but they have had vector drawing since 1988 in NextStep!

If your interested in hard-core optimization:Look Here its very interesting

Thanks for the link.

 

[Sun Baked]

I thought there was a new game tools page up on one of the developer pages, came through MR about a month ago or so.

Looked at... http://developer.apple.com/games/index.html

Couldn't find it, might be worth a search here on MR.

Edit: Found it on MR, wasn't a developer page

Doesn't look like much, just a marketing page.

http://www.apple.com/games/articles/2005/08/gamebuildingtools/

 

[GeeYouEye]

I do recall reading about how you can't mix the class hierarchies, but I did get the impression it was syntactically different enough from Objective-C that it could be considered another language.

For example, Objective-C++ seems to support name-mangling and namespaces.

It supports namespaces, but only for the C++ end of things. if you have a namespace foo, you can't have foo::[object message]; Similarly, while you can declare Obj-C and C++ classes within a namespace, but it only offers namespace protection for the C++ class. Obj-C class names are still global.

The IMP caching is demonstrated in a book I read by Scott Anguish. (I can't recall the title, oddly enough. I think it was something bland like Cocoa Programming or something. I read it quite some time ago.) I believe he said that techniques like that should only be used if you're doing a lot of function calls in a tight loop...

That sounds right. Although I think with GCC 4.0 there's a limited subset of tight loops that get IMP caching done automatically.

 

[savar]

1. Why did Apple choose to go with Objective-C as opposed to Objective-C++? Although I haven't programmed in it much, isn't Carbon based on C++? That seems like a bizarre migration path.

Apple ran with Obj-C because it was already being used on NextStep, the OS which was purchased by Apple in the late 90's in order to jumpstart OS X development.

Carbon in its current form is a strange mix of legacy and new code. A long time ago most of the MacOS was written in Pascal, and there are still plenty of remnants of Pascal still in the Carbon frameworks. Apple supposedly rewrote a bunch of the OS in C++ in the mid 90's, although thats not something I know much about. Anyway, I think the APIs were still exposed in the old Pascal/C hybrid style, even back then.

With OS X, I expect that the OS is mostly written in C (althought I've not confirmed this for myself) since BSD was mostly written in C.

To answer your question directly, you can mix Obj-C with C++ quite easily, but Apple doesn't need Obj-C++ because Obj-C already has object extensions...and C++ is confusing for many programmers.

3. Can Objective-C have anywhere near the performance (when using the Foundation libraries) that a regular C program could? Is it possible to use malloc or 'new' for classes written using the Objective-C/Objective-C++ notiation (@implementation, @interface, etc.)?

It sure can. You can't malloc an Obj-C object, but you can mix C and Obj-C intermittently. I wrote a program that used Cocoa for most of it, but also had some C structs and memory handling for doing some openGL views. So if you're writing a program and need specific areas to be real tight, you can avoid using Obj-C classes/memory management/messaging by using pure C.

You're right about games...I don't see Obj-C making much sense for cutting edge games -- its overhead you don't need. Writing them in Carbon is probably much smarter.

 

[HiRez]

It sure can. You can't malloc an Obj-C object, but you can mix C and Obj-C intermittently. I wrote a program that used Cocoa for most of it, but also had some C structs and memory handling for doing some openGL views. So if you're writing a program and need specific areas to be real tight, you can avoid using Obj-C classes/memory management/messaging by using pure C.

I do this all the time. In fact, I rarely write an app in pure Objective-C. Although I wish Apple would "Cocoaize" more of their APIs, I do think it's nice to have a lot of options for coding in OS X/Xcode, and being able to mix-and-match languages in the same application, object, or even a single method. I use straight C all the time for things where I don't need the Objective-C verbosity, and for accessing legacy APIs (which includes QuickTime), CoreAudio, OpenGL, etc. I've also mixed in Python and Java in my Cocoa apps where it makes sense.