Why go native...?

BJG · February 2013

I've been looking at TNT Collision Engine (nice one @GregBUG). Can someone explain the performance advantage of using C++...? The Android NDK documentation says that "using native code on Android generally does not result in a noticable performance improvement".

http://developer.android.com/tools/sdk/ndk/index.html

I don't really understand how this whole system works. I gather that Android apps run as Dalvik Bytecode. So does that mean that Gideros and Eclipse convert your Lua program into Dalvik Bytecode...? And if you add your own C++ library does that also run as Dalvik Bytecode...?

GregBUG · February 2013

i think that native code is *always* faster than bytecode....
especially for game projects where even a single cicle of your cpu time is important...
in my tnt collision c++ code run much faster that lua code... (especially for complex computation like rotated box).

Gideros runtime is coded in c++ (i think) and run as is (native) in iOS and Android Devices your code instead is lua bytecode and executed as interpreted bytecode by gideros runtime.

so if you code your library in c++ this run as native code (like TNT Collision does)

BTW Gideros is really fast.

BJG · February 2013

Cheers @GregBUG. I've just found another source which says the exact opposite of the quote above, which is that "The main motivation for developing parts of your app in native code is performance".

http://ofps.oreilly.com/titles/9781449390501/NDK.html

Confusing. Does everything go through Dalvik, or does "native code" bypass it...? I don't get what is special about C, C++, Objective C that these are called "native". Are you saying that the Lua program is processed by the Gideros runtime during execution in a way that C++ isn't...?

GregBUG · February 2013

c++ bypass Dalvik so it's executed directly no interpreter or byte code. (like lua, java or similar)

when you compile your c++ libs the c++ compiler translate your c++ code in armv6 or v7 (or other cpu) assembly code that will be directly executed by device cpu.

lua code is not executed by Dalvik but by Gideros Lua Interpreter. (@atilim correct?)
similar as Dalvik does for java applications.

summarizing:
c, c++, objective C are directly executed by your CPU (after that your c/c++ compiler has compiled in assembly) and generally is very very fast almost like you write in assembler.

lua, java et similar are interpreted or compiled in intermediate code so no directly executable from your cpu. there is a need for an interpreter or bytecode compiler (like dalvik) and so is slower than c, c++ because there is one ore more "software layer" between your cpu and your code.

PS: i'm not a professional coder so maybe my affirmations may not be entirely accurate.

BJG · February 2013

OK, thanks!

SinisterSoft · February 2013

@GredBUG correct (but not fully - technically)...

"c, c++, objective C are directly executed by your CPU"

The language does not decide if it's interpreted or compiled. You can get interpreted versions of those languages (just like lua and java). Also you can get compilers than compile to bytecode or to real cpu instructions - if byte code then that is usually interpreted again at runtime. There is another factor too - some cpu's (such as some ARM chips) that run java bytecode natively. btw: You can get LUA compilers too than compiler to real processor code, sometimes at runtime (eg LuaJIT).

Also compilers sometimes (always!) don't make the best code - they make assumptions programmed into them by the compilers programmer (compiler programmers are not usually games programmers). Also the free compilers, although good, are not the best - for example ARM and Intel both sell compilers than can produce code that can be an order of magnitude faster than the free compilers available. Some JIT systems that tweek code as it is running can also produce faster results after multiple passes - it depends on the application.

Generally though - compilation is much better than interpretation. Hand assembly tops the lot by far...

I myself prefer assembler code but nowadays it doesn't matter so much as the processor speed, multi-core and things like pixel shaders are so good.

BJG · February 2013

Hand assembly tops the lot by far.

I've just been reading up on Smali files. Crazy, all this Icelandic. If that's what Android assembly looks like you can count me out.

http://code.google.com/p/smali/source/browse/examples/HelloWorld/HelloWorld.smali

SinisterSoft · February 2013

Android assembly tends to be arm assembly, pretty easy to code for.

techdojo · February 2013

Hand assembly tops the lot by far...

Especially when you've got someone like @Scouser writing it, I've done my fair share of assembly in the past but god knows I prefer writing higher level code as it's a shed load faster to code.

john26 · February 2013

Some good descriptions here! Also, if you look at the Android project Gideros creates, you will see that a big chunk of the file size is libgideros.so. These are "shared object" files containing ARM machine code. There are actually two depending on the ARM version. So this is pure native machine code. So even on Android which is based on Java/bytecode, Gideros apps are 90% native machine code. There is a layer of Java on top but just enough to activate the machine code. Unfortunately this means Gideros apps will not run on BlackBerry 10 which runs Android apps only if they are pure Java.

The distinction between interpreted and compiled language is not so important as it was as most programs spend their time calling libraries e.g. to draw something or play a sound. These libraries are always compiled into machine code. If the code spends most of its time in these libraries (drawing thousands of polygons) the theory is it shouldn't matter whether the user code is in an interpreted or compiled language since the user code is trivial anyway and the grunt work is done by the libraries. That's what Android folk mean when they say "using native code may not improve speed". Whether that theory is actually correct depends on what the user code is doing. In some cases there is still benefit to be had from compiling the entire project into machine code. The rise of libraries like OpenGL has made it less crucial to write everything in machine code. In the 80s "golden age" programmers had to write machine code -- interpreted languages were not an option due to their slowness and lack of libraries.

There is a further complication since Java, though not compiled into machine code when you create your project, may be compiled when it starts to run (called "Just in time compilation"). For this reason, Java may nowadays be almost as fast as native code in practice. By contrast, Lua is normally a simple interpreted language and not compiled. However, there have been recent discussions on this forum about LuaJIT so "just in time" compilation is possible for Lua too (though not yet mainstream as it is in Java)

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Why go native...?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Why go native...?

Comments