7 ms·

"It's compiled, not interpreted." The Objective-C calls are not really compiled. They are dynamically dispatched at runtime in a very equivalent manner to an i

"It's compiled, not interpreted." The Objective-C calls are not really compiled. They are dynamically dispatched at runtime in a very equivalent manner to an interpreter or via reflection in Java. You can read about it here: http://www.mulle-kybernetik.com/artikel/Optimization/opti-3.html http://www.mulle-kybernetik.com/artikel/Optimization/opti-3.... Quite far from the compiled C calls also covered in the linked article.

SeoxyS 14y ago
The presence of a runtime doesn't negate the fact that code is compiled to native machine code, and all the benefits that come with that. Execution speed is quite a bit faster than bytecode-interpreted languages such as the JVM, which in turns is orders of magnitude faster than fully interpreted languages such as Ruby. The code is compiled directly for each architecture the binary supports (choices these days being i386, armv6, and armv7). C code in an Obj-C method is compiled to the exact same machine code as it would be, were it in a C function. Constructs such as ifs, loops, return statements etc are no different than their C counterparts, are are just as fast. Obj-C method calls are simply compiled into calls to the ultra-fast runtime C function `objc_msgsend`.
- spullara 14y ago
  Java hasn't been bytecode interpreted in 10 years. The objc_msgsend function is not fast. Measure it and see.
- flatline3 14y ago
  The JVM compiles the bytecode into machine code, and it compiles the hotspots of an application into optimized native machine code. Java execution is split into two pieces. First is the interpeter, which is used to execute bytecode prior to it being compiled. The second is the compiler, which implements runtime optimized compilation of hotspots into native machine code, including the ability to make assumptions regarding types and then uncompile hotspots if those assumptions prove false. Before you say "ah ha, an interpeter!", it's also notable that the JVM's interpreter is not an interpeter in the traditional sense (ala Ruby). Rather, the JVM's interpreter is an architecture-specific interpreter that decodes JVM bytecode and spits out unoptimized direct machine code based on a standard set of machine code templates. This is fast, but there's not optimized compiler, and so it's not nearly as fast as the result of the optimizing compiler that is run over the hotspots. All that said, JIT vs AOT is a technical decision with mixed advantages. In theory, there are optimizations that can only be performed via JIT, based on runtime analysis. The simplicity of AOT can often provide runtime performance gains simply by avoiding the runtime costs of evaluation and compilation. JIT of bytecode allows for binary/library portability across different machines without worrying about rebuilding or shipping multiple binaries. AOT is somewhat more difficult to decompile compared to unoptimized byte code. Mono compiles down AOT for iOS, in theory you could do the same with Java. GCC did so with their optimizing AOT gcj Java compiler.
bronxbomber92 14y ago
To be fair, their still is a difference between Objective-C and C# and Java (which the OP was trying to contrast). Dynamically dispatched (i.e. a table look-up or pointer dereference) doesn't change the fact that the callee (the method to be executed after being found by the runtime) or the caller (code sending the message & perhaps all the runtime doing the lookup) are both compiled into executable code. This is surely different than how Java and C# are compiled/executed (in most cases) -- which I think was the intended point :).
- spullara 14y ago
  Java and C# are compiled into machine code before execution. Also, Objective-C isn't table lookup or pointer dereferenced, it is more akin to a (cached) reflective lookup and dispatch.
  - bronxbomber92 14y ago
    You're right that method invocations aren't simply a table lookup or pointer dereference, but in the end it boils down to a jump to the address of some all ready compiled (machine) code which is what I was trying to make a point of. For C#, the execution process is C# -> compiler -> CIL bytecode at compile time. Then at runtime CIL bytecode -> JIT -> machine code. So sure, C# (and I believe Java is similar to C# in this regard) eventually gets compiled to machine code, but it's vastly different from what I believe to be the accepted usage of being a "compiled language." The exception to this being if you AOT compile your code, but in that case you lose sacrifice some language functionality.
stcredzero 14y ago
Most developers are just interested in the compile-time type verification.
- SeoxyS 14y ago
  The compiler and static analyzer nowadays can do a lot more than that, it can catch typos, dead ends, nonsensical statements, memory management issues (such as leaks or usage of a dangling pointer), unguarded implicit casts or assignments in if clauses, and a lot more. It's saved my ass countless times, catching bugs before they ever hit production.
- tikhonj 14y ago
  In which case it is no different from Java or C#: both also give you compile-time checks.
  - stcredzero 14y ago
    My comment is more about the programmers than it is about the languages.

SeoxyS 14y ago

The presence of a runtime doesn't negate the fact that code is compiled to native machine code, and all the benefits that come with that. Execution speed is quite a bit faster than bytecode-interpreted languages such as the JVM, which in turns is orders of magnitude faster than fully interpreted languages such as Ruby. The code is compiled directly for each architecture the binary supports (choices these days being i386, armv6, and armv7). C code in an Obj-C method is compiled to the exact same machine code as it would be, were it in a C function. Constructs such as ifs, loops, return statements etc are no different than their C counterparts, are are just as fast. Obj-C method calls are simply compiled into calls to the ultra-fast runtime C function `objc_msgsend`.

spullara 14y ago
Java hasn't been bytecode interpreted in 10 years. The objc_msgsend function is not fast. Measure it and see.
flatline3 14y ago
The JVM compiles the bytecode into machine code, and it compiles the hotspots of an application into optimized native machine code. Java execution is split into two pieces. First is the interpeter, which is used to execute bytecode prior to it being compiled. The second is the compiler, which implements runtime optimized compilation of hotspots into native machine code, including the ability to make assumptions regarding types and then uncompile hotspots if those assumptions prove false. Before you say "ah ha, an interpeter!", it's also notable that the JVM's interpreter is not an interpeter in the traditional sense (ala Ruby). Rather, the JVM's interpreter is an architecture-specific interpreter that decodes JVM bytecode and spits out unoptimized direct machine code based on a standard set of machine code templates. This is fast, but there's not optimized compiler, and so it's not nearly as fast as the result of the optimizing compiler that is run over the hotspots. All that said, JIT vs AOT is a technical decision with mixed advantages. In theory, there are optimizations that can only be performed via JIT, based on runtime analysis. The simplicity of AOT can often provide runtime performance gains simply by avoiding the runtime costs of evaluation and compilation. JIT of bytecode allows for binary/library portability across different machines without worrying about rebuilding or shipping multiple binaries. AOT is somewhat more difficult to decompile compared to unoptimized byte code. Mono compiles down AOT for iOS, in theory you could do the same with Java. GCC did so with their optimizing AOT gcj Java compiler.

bronxbomber92 14y ago

To be fair, their still is a difference between Objective-C and C# and Java (which the OP was trying to contrast). Dynamically dispatched (i.e. a table look-up or pointer dereference) doesn't change the fact that the callee (the method to be executed after being found by the runtime) or the caller (code sending the message & perhaps all the runtime doing the lookup) are both compiled into executable code. This is surely different than how Java and C# are compiled/executed (in most cases) -- which I think was the intended point :).

spullara 14y ago
Java and C# are compiled into machine code before execution. Also, Objective-C isn't table lookup or pointer dereferenced, it is more akin to a (cached) reflective lookup and dispatch.
- bronxbomber92 14y ago
  You're right that method invocations aren't simply a table lookup or pointer dereference, but in the end it boils down to a jump to the address of some all ready compiled (machine) code which is what I was trying to make a point of. For C#, the execution process is C# -> compiler -> CIL bytecode at compile time. Then at runtime CIL bytecode -> JIT -> machine code. So sure, C# (and I believe Java is similar to C# in this regard) eventually gets compiled to machine code, but it's vastly different from what I believe to be the accepted usage of being a "compiled language." The exception to this being if you AOT compile your code, but in that case you lose sacrifice some language functionality.

stcredzero 14y ago

Most developers are just interested in the compile-time type verification.

SeoxyS 14y ago
The compiler and static analyzer nowadays can do a lot more than that, it can catch typos, dead ends, nonsensical statements, memory management issues (such as leaks or usage of a dangling pointer), unguarded implicit casts or assignments in if clauses, and a lot more. It's saved my ass countless times, catching bugs before they ever hit production.
tikhonj 14y ago
In which case it is no different from Java or C#: both also give you compile-time checks.
- stcredzero 14y ago
  My comment is more about the programmers than it is about the languages.