Native code is important

[edepot]

One of the lessons not learned by many people dealing with operating systems is that native code is important.

It is so important that it can make or break acceptance of the device for software developers, and sometimes eventual success of the product. If anything, the old way of adding more features over layers and layers of code via interpretation or virtualization is out. Thin layers that allows developers full access to the hardware is the way to go. When mobile devices are becoming more popular, it is important that direct access to the hardware is not hampered because battery life will be reduced through wasted cpu cycles on the interpretation or virtualization. Wasted CPU cycles means reduced speed, and reduced speed means certain applications will not work on the device (notably power hungry games). It is not a secret that games drives sales of many devices. In fact, it is this reason that game consoles became so successful. Interpreted code also prevents cycle counting for very high performance applications (games notwithstanding), and this leads to unpredictable behavior unsuitable for real time OS and high framerate dependent games. For example, certain interpreted languages have garbage collectors and "hotspot" compiling that can kick in or be working in uncertain time periods, which will affect the timing and cpu cycle counting. It can also affect smoothness of user interfaces and quick feedback.

If you look at mobile technology (especially cell phones), the games were nothing to talk about. There are two factors, speed (the slow java), and the screen (small size and low resolution). Apple got lucky with the iphone (took some hackers to let them realize the profit potential for native apps on the device) and they ended up creating a new segment of low cost games and applications. Piggybacking on this concept will solve the other missing piece of the equation for a popular device... big size and high resolution in a touch tablet.

Google's entry into the mobile phone segment will probably be hampered by too many different cpu's that are tied together by an interpreted language (java). Java is an interpreted language and will have the same disadvantage as all interpreted languages (like C# and its .NET libraries). Interpreted languages are good for short programs that run short bursts (like perl programs, which lead to PHP web languages). They may be good for short quick web stuff, but try doing stuff in games with them and they will start to show their disadvantages. Even allowing "hacks" to allow direct access to the cpu via Java is kind of a bad idea. The hack won't work on different CPU's, thus segmenting the market. I think google should just stick with one type of CPU architecture and allow native access to it (like what apple is doing with their iphone and iPod touch).

On consoles, native code is a must. Even adding .NET XNA for developers showed that there is little market for slow unpredictable programs (because of interpretation), which is why on the XBox360, the game sellers are those that don't use it, but access the hardware directly in C or assembly. If the PlayStation brand of consoles started adding layers of interpretation, the console won't last that long (10+ years). Each layer of interpretation or virtualization slows the hardware down, and a hardware device must get as much power as possible throughout its lifetime, which is why newer and newer games go lower and lower to access the hardware in order to get more power (which means going down to assembly level programming). It is this reason that software libraries that add too much indirection or virtualization will end up hurting the device in the long run. Interpreted languages (.NET and it's incarnations) and virtual drivers on the Vista and later operating systems ended up killing most of the productive programs and games on the platform because with each revision of the OS, the hardware needs to be upgraded to basically do the same thing. Upgrading hardware to make up for slowed down operating system (because of the thick layers of interpretation and virtualization) may be good for hardware sales in the short run, but bad for everyone (including developers, hardware manufacturers, and consumers) in the long run when the number of apps and games perform poorly on the majority except for those who upgraded their hardware to the max specs. When this happens there is no market for apps and games, and that is why the consoles and iphones (with their thin layers of OS) started taking over the market previously held by desktop operating systems.

Google will probably find out this eventually when they finally realize chrome is popular because it is fast and accesses the hardware directly, while their mobile phones don't sell that much because of the lack of good games, and UI that is not smooth like native code. Games may have something to do with it, because games just don't work right on interpreted languages, and the mobile phone provided by google require that they be made in Java (an interpreted language) with garbage collection and inability to count cpu-cycles, and lack of direct access to the hardware. Like .NET (yes lack of games using it too), the platform will probably fizz out when the number of exciting games and powerful programs become lacking because developers can't get access to the hardware directly, without going though "hacks" that don't work on all devices. The google phone may save itself if they just emulate the iPhone of keeping to one type of CPU and get rid of virtualization and interpretations and keep the layers as thin as possible to allow programs to shine.

What many don't realize is that powerful software that can do many amazing things is great, but if you stick a middle layer (the operating system and the libraries) that hampers access to the hardware, and enforce a type of language (interpretation), you limit what can be achieved on the hardware. The application decides if it wants to use interpretation. The application decides how much CPU cycles to waste. The OS needs to get out of the way and be as thin as possible. Enforcing too much constraints on the applications (games) will kill the platform. Some vendors go out and even limit who can provide software on a platform, and while this has some benefits, it also reduces the number of channels the platform can succeed. Windows didn't become a monopoly because people can use it to move windows around, it was because of the cheap hardware and games and apps made by the developers that all ran on the same platform. Consoles took over because the hardware was cheap for consumers and you didn't need to keep upgrading hardware to keep up with the slow operating system revisions released each 3-5 years. It got to the point on the desktop where slow operating systems destroyed enough good developers that the limited number of developers on consoles overcame the negative aspects of expensive hardware upgrading, and the consoles took over the gaming market. If this keeps up, apple will also take over the application market because it seems for Microsoft adding features by absorbing more layers (and competitors) is their profit strategy. Soon, Microsoft will have to deal with the situation that developers will find alternative platforms that provides them with access to the hardware directly (which means good for games and powerful apps), and not worry about being swallowed up because the OS just got more bloated because it absorbed another similar feature offering by the developer. Destroy a developer on the platform, destroy future markets on the platform offered by the developer.

So what does this mean? The future device needs to be open to a lot of developers and the OS needs to get out of the way and not enforce a language, type of access to the hardware, and be very powerful and cheap. The PlayStation just happened to fit this description with the exception of the "open to a lot of developers" and that is why the iPhone came to market and absorbed what was left.

http://www.edepot.com/playstation3.html
http://www.edepot.com/iphone.html

[edepot]

One of the things that comes up after discussing performance of interpreted languages versus languages like C and C++ is that in certain cases java or c# can outperform C or C++. For the laymen they will see a small benchmark showing that it was faster and think... yeah, it may be faster in certain cases. But in reality, those cases most likely is a result of utilizing a certain features of the interpreted languages... namely the garbage collector (or lack of using it). In most interpreted languages there is a garbage collector that runs to clear up and release unused memory, and it runs in uncertain times. In C or C++ most programmers will allocate and release objects when needed. But in interpreted languages, the virtual machine takes care of it automatically. In many benchmarks where interpreted languages outperform C or C++, the garbage collector is not even running, or runs when the benchmark has finished running. What this means is that memory is hogged the whole time without releasing them until the program ends. Interpreted languages usually require many many times more memory to run (for the virtual machine and for the large heap). If a C or C++ program is programmed so that it allocates all the memory it needs in the beginning and releases the whole thing with one free() command near the end of the program (instead of doing it during each step of the loop), of course the case where interpreted languages outperform C and C++ would be naught. Then there are cases of certain programs recoded for Java (including games) that ran faster than C or C++. Those cases requires extreme modification of the original code to utilize Java features, but you have to think... what if someone did extreme modification of the original code to utilize C or C++ features (inline, unroll loops, etc), then we would be back to square one. Interpreted slower than native code.

On the touched topic of memory requirements, this is very detrimental for games, especially those that run on tight memory budgets. Besides performance, memory requirements usually is the second factor that prevents interpreted languages from being used for games and high performance applications. There is usually many MANY multiple memory size requirements to run the same code on interpreted languages versus native ones like C and C++. In order to increase speed, the garbage collector usually is turn off and only turned on when there is low memory. However, you can't let the virtual machine eat up the whole memory, so it has to turn on sometimes. When it does, the performance will hit and many times you can see the performance drop visually, which is not very good for games that require flicker free framerate sync'ed to the display.

For those that like benchmarks, visit: http://shootout.alioth.debian.org/u64q/java.php

In the first graph on that page, anything above the line means the first language (java) is that many times slower than the second language (C or Gcc). Note that C# is similar to Java in performance (but on that page C# Mono is extremely slow for some reason). You can play around with the languages and hit "Show" to see the differences in performance. Note that the only case where Java beats C and C++ consistently is code size (below the line), but this is not important because overall memory size interpreted languages requirements are larger. I am hoping that people are not blinded by marketing but stick to common sense and truth. Look for independent validators, not those on some sort of agenda.

For example, on this performance topic, a simple search for counter examples shows:
http://bruscy.republika.pl/pages/przeme ... n_cpp.html

Note that this is not a bash on interpreted languages. Interpreted languages are useful for certain applications. It is when it is forced on developers to solve all problems that problems arise. The developer chooses to use it or not, not the operating system.

[edepot]

Sadly, Google's implementation of Java leaves much to be desired. Unfortunately, Google decided to use Dalvik, a Java Virtual Machine that emphasizes code and memory size rather than performance. So although the code size is smaller than regular Java (although still many many times bigger than C), it is actually SLOWER than Sun's implementation of Java. Apparently, in the desire for small code (and memory size) they totally left out the Just-In-Time compiler. A search around the internet will reveal results like the following:

http://www.mail-archive.com/android-dev ... 73982.html

There is talk about a JIT in new versions of Android, but apparently, they are aiming for regular Java performance when regular Java performance already trails C and C++. While in certain cases regular Java can be more than 20x slower than C, Dalvik in certain cases can be more than 20x slower than regular Java! So given this scenario a Dalvik could be 400x slower than C (20 x 20 = 400). On average the best Sun Java implementation is about 2x to3x slower than C or C++, with most of the garbage collection deferred, chewing up all the memory required for the program to finish. When the coder is not careful, using a different library method call will sometimes slow the program 10x-20x times (compared to C counterpart). A game in a constant loop will usually force the garbage collector to be constantly working and running, thus eating into the performance, plus there is the added memory needed for virtual machine compatibility (with or without the hardware chip).

It is disheartening to see a good company with great products like google put so much emphasis behind a "so so" product. But I guess it is one of their "labs" projects that they are willing to waste and test out (similar to their other projects in "labs" status that don't make the grade). Unfortunately, Microsoft is in worse shape (although they did learn the lesson and got rid of .NET for their mobile phones) and tries to put "managed" code and .NET into more and more pieces of their operation system and products.

It is sad that a basic 2D tile game like Mahjongg (like that one shipped with Windows 7) that would normally run speedily on XP or previous systems, slows to a crawl on Vista and Windows 7 because it is purposely coded to only run fast if you have upgraded to a high performance 3D card (even though the game only manipulates 2D sprites).

At this rate if Microsoft and Google don't wake up, I think it is time for others to take the crown, and Apple and Sony seems fairly capable given their size and experience.

[edepot]

Lessons learned. Right now the Android market is becoming the java market. Originally, phone manufacturers only needed to include a java interpreter to provide value added options of small java programs they can install from the Internet or preinstalled. These programs were mostly slow small games that were nothing to write home about. But because of the simplicity and mostly free cost associated with providing java on these handsets, it proliferated on many devices (although mostly unused), as people uses the devices mainly as phones. Google sort of stepped in and also offerred the whole operating system for free. Whereas before the manufacturers needed to code the OS, provide the mostly free java interpreter, and then bundle the baseband chip (comes with baseband OS)... Now the manufacturer no longer needed to code the OS, as google now handles the Android OS and the free Dalvik interpreter (java). Google's entry into the phone market is to similar to how java got in, by providing a mostly free product that phone manufacturers don't normally spend a lot of money on (software aspect). The phone manufacturers now only need to choose which chip to support (ARM mostly) and bundle the baseband chip (along with it's already programmed baseband OS).

Google's strategy is to get enough users via this method. However, the main question of whether java applications and games will provide a viable market on these devices will probably be in the negative. Corel tried to do the same thing way back in history by trying to recode all their office applications in java. It failed because of performance and memory hog issues. The wordperfect suite just didn't perform right compared to native performance of competitors (MS Word). In fact, the project was dumped and all their applications are now in native code. There is a lesson in here somewhere, but I think google will try to use the free chrome browser and free handset operating system as a way to get into the handset market. The java app market will probably die out, but phone manufacturers probably are already saving on the OS making costs to give it up. It should be noted that chrome on android is not made in java, nor most of the operating system of android because they need performance and run on a tight memory budget. I just don't realize why don't google just allow an option to code in c directly and just tell manufacturers to stick to only one CPU instruction sets. Most phones run on ARM anyways, so the java run everywhere is just java run slower via interpretation on one ARM CPU. Forcing developers to code C via a java layer is just plain stupid, as the developers will need to recode the c for every type of CPU supported by java. If the developer is already handling the different CPU cases they can get performance by coding the rest of the app in c and not worry about the java-c bindings. Java is just a limitation in this case because android is mostly C anyways (linux OS) with a java layer forced on developers, while google gets to use C for chrome and all the android internals.