4 ms·

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 qui

by 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.

by SeoxyS 14y ago

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.