Re: Java vs C/Objective-C performance question
Re: Java vs C/Objective-C performance question
- Subject: Re: Java vs C/Objective-C performance question
- From: Dietmar Planitzer <email@hidden>
- Date: Mon, 17 Mar 2003 10:01:56 +0100
On Monday, March 17, 2003, at 08:34 AM, Sheehan Olver wrote:
I was curious about what the difference between performance of java
and Objective-C was, and I got some weird results in a couple tests I
did. See the bottom of the message for the code. For the first test,
which was really a comparison of java to C, java took 11 seconds while
C took 25 seconds, which makes no sense to me whatsoever, as I don't
understand how java could outperform C. For the second test, which is
more relevant to Objective-C, I got java taking 2 seconds to
Objective-Cs 14 seconds. Again, this just doesn't make much sense. Any
ideas on why I'm getting these results? I ran the tests multiple
times, and the times were similar.
I'm running 10.2.4 on a PowerBook G4 550Mhz, with java 1.4.1
installed. Both tests were done from Project Builder, but as command
line tools (i.e. within the main function).
<snip>
Some things to keep in mind when comparing the performance of Java to
ObjC:
1) Always compile ObjC code with all optimizations turned on. By
default PB compiles the code with all optimizations turned off which
means that gcc will produce horribly bad code.
2) Your example program is actually unconsciously designed in favor of
Java because:
a) Apple ships a JavaVM which supports just in time compilation. This
means that the VM produces optimized machine code from the Java byte
code at runtime for certain methods. Your first example consists of
three simple cascaded loops. This code is a prime candidate for
jitting. One advantage of dynamic code generation compared to
traditional (static) compilation strategies is that it can produce code
which is exactly optimized for a particular runtime scenerio and thus
faster than statically produced code. This is why similar techniques
are often used in graphic libraries like for example OpenGL.
b) Your second example is about object allocation. Here again Java is
by design faster because it uses a garbage collector for memory
management. The advantage of a GC is that allocating memory is much
faster than with traditional allocators like C's malloc(). I.e.
allocating memory in a copying GC scheme is as simple as incrementing a
single pointer. The disadvantage however of such a copying collector is
that it can only use at most 50% of the available address space because
it parts the address space into two halves: the active heap and the
inactive heap. memory is always only allocated from the active heap
until it fills up. Once that has happend it copies all objects which
are still alive (referenced from a live object or the root set) over to
the inactive heap. After that the meaning of both heaps are exchanged
and allocation resumes as before. Another disadvantage of GCs is that
they must hold the execution of the various application threads from
time to time in order to collect dead objects. This happens at
unpredictable times which can be a real problem for apps which need
some form of realtime guarantees.
Anyway, the comparison is also unfair because in the Java case you just
allocate objects, but don't free them (the collector will hardly get a
chance to run because the app runs for such a short time); in the ObjC
case you both allocate and free them.
Summary:
When doing benchmarks, then _always_ use real world code. Don't try to
measure the performance of such simplistic code because it will always
favor one language or the other and thus invalidate the benchmark.
Regards,
Dietmar Planitzer
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.