[DaGuy]

From what I can gather, Obj-C can handle dynamic binding by means of a runtime. I can understand a virtual machine and what it does, a runtime is a "bit" different. Is it just a background process that acts as a traffic cop for object messaging? Is it one runtime per application? How can I see what is doing? For example measure its performance.

Thanks,




[ 03-04-2002: Message edited by: DaGuy ]

[sadie]

*bump*

I don't know the answer for sure, but nobody else has bothered to give you a reply so there's no harm in giving you my .02 (unlike my .22, which is very harmful) (that was a joke, you morons!).

As far as I remember, the ObjC runtime is incredibly simple when compared to something like a VM, or even C++'s runtime. It has a separate copy of it for each program. Why?

• Every Objective-C program is really just a C program. It should run happily on a computer that's never even heard of ObjC before. So it needs to bring its runtime with it, not count on the computer having one. Kinda like a Hermit Crab.
• In theory, you could have different versions of the runtime for different programs. I heard it was even possible, somehow, to make the language garbage-collected.
• Since the data kept by the runtime is basically about your program, there's nothing much to be gained by keeping the data elsewhere.
• If the runtime crashes, how much of your system do you want to crash? At most, the one program that caused the crash, not all of Cocoa.

Does that help?

[DaGuy]

Thanks Sadie, it does help. It also brought up some new questions -don't you hate it when that happens?

Firstly, I didn't know C++ had a runtime. I always thought it was statically typed i.e. had no equivalent of Obj-C's Id type. So that got my head spinning. Lastly, do you know of way to guage the overhead incurred in using the runtime?

Thanks again!

[larkost]

A couple of notes:

C++ does sort of have a runtime, it is the set of instructions that allows for Objects in the first place, it is a bit more restrictive, so you don't hear about it much. If you were to compile the same C code as both a C and then a C++ app the difference in the code size would be the equivalent of the runtime. I think some of this also has crept into the C++ dynamic libraries on some platforms... but I am not sure about that.

And the second note is that it is really hard to gauge the penalty of runtimes, since the whole idea is that they allow simpler structures in programs, thus saving some time (sometimes coder time, sometime run time... complex issue). You would have to create the same program in C and then in Obj-C or C++ and make comparisons there, and I would be willing to bet that your results would be complex and change massively depending on what you are doing (and the relevant skills of the programmer(s)).

[sadie]

From what I know (with the same disclaimer that I don't know Jack)...

C++'s runtime is just the set of functions it needs to execute its object-stuff - so it just translates your code into static C. And, of course, all the other stuff C++ adds.

ObjC's runtime keeps a proper dynamic table of what-have-yous, supporting all the dynamic lookups and stuff. It probably looks very similar to SmallTalk's runtime. It's a fully dynamic language written on top of C. Even Java isn't quite as dynamic as ObjC - to its benefit.

[DaGuy]

it just translates your code into static C

ObjC's runtime keeps a proper dynamic table

Aha! That makes sense. The more I dig into Obj-C the more I like it. You get SmallTalkesh dynamics but without the additional virtual machine overhead. I wonder what other languages offer this kind of behavior?

[sadie]

Originally posted by DaGuy:
<STRONG>

Aha! That makes sense. The more I dig into Obj-C the more I like it. You get SmallTalkesh dynamics but without the additional virtual machine overhead. I wonder what other languages offer this kind of behavior?</STRONG>

How much overhead is a virtual machine?

There was a research project at Hewlett Packard a while ago that was looking to emulate one chip on top of another. Just for practise, to make sure they knew what they were doing, they took one of their favourite chips and used it to emulate itself. This involved a small program that translated machine code into machine code. They then added to this program a few 'standard' runtime optimizations. With these optimisations, they expected the emulated code to be only a little bit slower than the original. Imagine their shock when the results came out... faster.

Modern languages generate code that is, by its nature, very dynamic and generic. You never know at compile-time exactly what will be calling what. But at run-time, you do - things run along well-known paths that repeat in predictable ways. So however much a compiler can do to speed up code, can be doubled by optimizing at run-time.

C, C++, ObjC, Pascal etc are compiled straight to the 'expected' CPU - which on the PC generally means 386 - and unless the CPU itself has a good internal optimizer they are executed straight. A virtual machine, however, has ample chance to optimize for a specific CPU. So depending on what you're doing, Java code can come out faster than C++.

If you're looking for dynamic OO languages, you'll find quite a lot of them built on top of the Java VM. If you're just looking for interesting ones, have a look at Eiffel and Beta.

All this stuff can be found on sites like Ars Technica.

[Wixar]

I'd like to add that the Objective-C runtime is implemented in straight C (with some assembly for the function that maps message-&gt;method) and can be freely downloaded from the Darwin project.

-Peter

[SoClose]

One of the nice thing about Objective-C, which I just now dipping my toes into, is that you can forgo typing everything as id (for all of the dynamic typing stuff) and use a more static typing. The compiler can catch more errors at build time rather than at run time and your app should be faster, in theory, because there's less dispatching related to object type. Of course, you then lose some of the nice runtime dynamicism that makes Objective-C so cool, but there's a happy medium for everyone.

The thing that I didn't know is that your Objective-C application gets faster as it's run since the dispatch tables build up a nice cache in memory. Of course, the app then uses more memory but with our nice VM subsystem it shouldn't be an issue. It would be very cool if the state of the app, as it gets optimized, could somehow be saved. A long time ago, when DEC developed the Alpha chip, they had some really cool software for running Win32 binaries under some UNIX-variant that would actually dynamically recompile the app the more you ran it so it would perform better on the Alpha (x86 to Alpha instruction translation). Apple did this to some extent with the Dynamic Recompiling Emulator built into Mac OS 7.5 and greater (and only enabled on PCI Macs) which let older 68K-based app run better over time on the PowerPC chips (but it only worked during the apps current session).

[mlaster]

Originally posted by SoClose:
<STRONG>One of the nice thing about Objective-C, which I just now dipping my toes into, is that you can forgo typing everything as id (for all of the dynamic typing stuff) and use a more static typing. The compiler can catch more errors at build time rather than at run time and your app should be faster, in theory, because there's less dispatching related to object type. Of course, you then lose some of the nice runtime dynamicism that makes Objective-C so cool, but there's a happy medium for everyone.
</STRONG>

Actually there is no performance change whether you use id or typed variables. The runtime goes through the same steps. Typing just allows the compiler to generate warnings at build time so you don't have to wait for a runtime crash to realize that you mis-typed a variable.

For example, I could have a variable defined:

NSArray *myArray = [NSDictionary dictionary];

if I assign an instance of an NSDictionary to it, then

[myArray objectForKey:@"foo"] will execute properly, even though the compiler will generate a warning that NSArray doesn't respond to objectForKey:

So, the only difference between 'NSArray *myArray' and 'id myArray'
is that in the latter you won't get a warning, and in the former you
will.

[Kickaha]

Eiffel and Beta? Gawrsh, now yer getting into my research area.

Wow, never thought I'd see *BETA* mentioned on these forums...

Just to tease the new kids: go dive into Eiffel and Beta, and come back with a 2 page synopsis of the tradeoffs involved in contravariant vs covariant method passing. (E & B have a very different approach to the subtyping allowed with overridden methods - it's very intuitive, but less type safe than the alternative.)

And, since we're on the subject, can anyone point me to a meaningful use of Beta's inner construct? Except as a shorthand for implementing a Template Method design pattern without adding a second method, I can't see an effective application.

[DaGuy]

I'm completely hooked! How about including some links to aid the discussion? For example, where is and how to install and configure Beta or Eiffel for OS X. This would be really useful, it would allow for some hands on. Perhaps then we can then begin to understand "covariant" and "contravariant" in a different context other than tensors.

[Kickaha]

Re: inner, nevermind, I got it. Duh. The original item I saw on it was severely lacking in a meaningful definition. Neat way to enforce and require that subclass methods truly are isA, but doesn't offer a nice way that I can see to offer multiple extension points within a single method - could lead to annoying explosion of classes, unless a traits based system were introduced.

*ahem*

Sorry...

Er...
www.eiffel.com is the 'official' Eiffel site, run by ISE, the company that Bertrand Meyer (creator of Eiffel) started. (Interesting guy - his cell phone rings the French national anthem.) They sell a package (EiffelStudio) for Wintel, and Linux. Lots of stuff on there, but nothing MacOS X ready, that I could find.

However: http://smalleiffel.loria.fr/ is a GNU Eiffel compiler. Does Eiffel -&gt; C and Eiffel -&gt; Java. Includes a fairly large library as well. No IDE, as with ISE's offering, but at least it can be compiled.

Still looking for a Beta dev kit...

Ah, here we go:

The FAQ: http://www.daimi.au.dk/~beta/doc/faq...guage-faq.html

Which leads you to: http://www.mjolner.com which is the one and only source for BETA (yes, it's all caps, I've learned, according to them at least - the other references I've seen don't style it that way, but oh well...) compilers... which is fine, since they're free.

[ 03-06-2002: Message edited by: Kickaha ]

[sadie]

Can you tell us something useful about BETA? I've had a quick look at the pages a while ago, and they looked... weird, frankly. Interesting but wierd.

I think I'm addicted to C-based syntax... it's a real flaw.

[sadie]

Originally posted by Kickaha:
<STRONG>Eiffel and Beta? Gawrsh, now yer getting into my research area. </STRONG>

What are you researching? Doing anything interesting?

You're not gonna escape now, you know...

[theolein]

One thing that seems very good in BETA is the assignment syntax, finally someone realised that it would be more consistent to go from left to right instead of right to left, so instead of this:

x = y;

you have this:

y -&gt; x;

(of course this will give C programmers a headache)