I am a very strong admirer of Apple. And one of the biggest issues that an Apple admirer can face while he interacts online with people is – being constantly bullied by Android fanboys at how he or she is an iDiot. Apple admirers are called iDiots and iSheep for getting attracted to the brand that they prefer/like. My online interactions have been bitter all the while this iPhone 6 mania of bent bodies and broken records was happening.
iDon’t know what makes someone an iSheep. Not really. But as it seems, thinking Apple of a company that makes good products is one of them, or probably the prime reason for being called an iSheep. In here is my attempt to dissolve that argument. I would make 3 points which Android lovers love to fathom about, but only a little deep. But it looks like ‘quoting numbers’ is the something Android users enjoy a lot because in most cases, numbers work out in their favor. The prick point is – the units associated with them. So if a person says ‘I have 3’ and ‘I have 5’, who has more? The answer depends on the unit and item. Like 3 gold is probably better than 5 silver (so that’s item) but 3 tonnes of silver is more costly than 5 milligrams of gold (the unit). This is a humble attempt at making meaning out of some numbers that are quoted all so often on the social media. Let’s begin with the most important one.
Processor – Frequency, Cores, Result and Reality
One of the favorite sentences of a die-hard Android users are along these lines – “Apple is so ancient. How can anyone call them advanced? All these iSheep still buy a dual-core processor for that price”. The sentence gains a swarm of ego-supplement when one sees huge ads hanging over tall shopping malls asking you to upgrade to a new phone which has 4 times the number of processors and thrice the RAM of what is touted as the best smartphone, time and again or full page cover ads at the front of a leading newspaper of the nation (the kind that makes cheap headlines and OMG you won’t believe me if I told you what they are). If the eyes reading this piece of text belong to an Android lover, I urge you to keep reading.
So, as it happens, next generation processors of 8 cores of 2GHz power the android phones of today all the while 1.4GHz dual cores power iPhones. Going by simple mathematics – 8x2 = 16 while 1.4x2 = 2.8. And by that math, the best iPhone is about 5-6 times inferior to a top class Android phone. But there is a glitch with that mathematics – the reality is not that simple. In fact, processor’s frequency is one of the most notoriously insignificant numbers. The frequency itself is dependent on a lot of other stuff that goes into the design of a processor. I would have liked to explain them a little but even a little explanation would make it a very long post. If you are interested to know about the terms I am going to mention, head to this page (it’s a long read and needs patience): (http://www.lighterra.com/papers/modernmicroprocessors/)[http://www.lighterra.com/papers/modernmicroprocessors/](it explains them all). And since an Android lover does not shy away from details, one should go dig a little deeper into the processor’s architecture.
Android apps are written in Java. At the peak of their optimization, only few chunks of the code are produced in true executable binary form. This has some serious issues when concerning the hardware:
- There is always the overhead of converting byte code to binary code. So this process does no productive work for the user but still eats up a lot of energy.
- Results of operations are repeatedly read back by the JVM (Dalvik), interpreted and it might lead the JVM to branch (it would start converting a different set of byte codes into binary). So lots and lots of wastage of CPU power. All that 16 GHz of effective power just got reduced to around 5 (yeah, all this repeated byte-code conversion and execution cycle, even with JIT is about 3 times slower than native code in normal app runs).
- Since CPU does not get the entire instruction queue in binary format and cannot just branch out to any instruction it wants, and rather has to give the result back to the JVM and when doing that, a good number of super advanced algorithms and features built into the processor to improve efficiency are simply wasted and hence put a lot more pressure on the processor. These include:
- Branch prediction built into the processor is of no good use to Android/any JVM implementation to a large extent.
- Utilization of issue width in full capacity cannot be done – this feature is highly dependent on the processor and Android being a flexible platform cannot make a wild guess about it.
- If SMT feature is available, it would be under-utilized at best because the thread that are run are java threads and that again means a lot of JVM calls and that in turn means inefficient usage of cache memory.
- OoO feature mostly would go unused/underused.
- A major one – Microcodes are not known to the JVM and in most cases, direct utilization of microcodes for productive use is a far sighted object.
- Another major one – Microcode Reorder Buffer Size is not used properly
So what does that jargon boil down to? Well, your Android uses your Ferrari like a Prius. And how does that fare against the latest iPhone 6’s A8 processor (and much more importantly, it’s usage)? Let’s see:
- iOS runs on Objective C, one of the fastest known languages in terms of execution speed.
- There is no garbage collection, hence the processor does not do all that work of removing old stuff from memory. More room for actual work!
- The code that it executes is binary instruction by origin. That means branch predictor has got more details about what might come in next. Thus, it can make good use of that reorder buffer.
- The issue-width on A-7 (iPhone 5s’ processor) is 6 micro-ops. So is of A8 (iPhone 6’s processor). This means a lot more instructions per second.
- A-7 (and reading LLVM’s one of the platform target file, one can say even A8) has a 192 micro-ops of reorder buffer. That is huge because that brings down the chances of mis-prediction (and hence the associated penalty with it) and allows a desktop grade instruction pipelining and scheduling (for info – Intel’s haswell chips have the same micro-op buffer size). Then, there is the compiler – LLVM, which is pretty great at producing great code. More so on RISC processors (ARM is RISC design) so, even better resource usage.
- The load latency is 4, so it’s a little higher but with that wide a micro-op reorder pipeline, the efficiency is a lot higher too. So 4 is a good number.
- With 2 direct, 1 indirect branch units and 3 FP units, this is amazing. You can do about 4 integer instructions and 2 floating point instructions (thanks to a issue width of 6) in parallel. Again, having an indirect branch unit is a boost. It would save some time spend in finding that data. With the indirect branch unit on hardware, the branching is faster while the code can get a little more flexible.
If you are not able to understand what I am saying – it just means the processor is damn awesome! With more issue width, a pretty large reorder buffer, doubled ALUs and functional processing units, clever circuitry and even cleverer compiler for the platform, iOS along with the hardware is an amazing feat of engineering. The processing units in iPhones are advanced well beyond what we can intake in a single gulp and are advanced enough to reach the processing achieved by those big chips Intel produces. Most processors that are used in today’s phones by other companies work on the Krait model. A8 is the 2nd generation of Cyclone (A7 was first) which is 2 generations ahead of that (Krait, then Swift, then Cyclone)
Now, I know that if you like Android more, you would say a lot of things, probably research a bit and come up with facts and figures like JIT optimizations, Java memory-model based load/store instructions and so on. But the fact remains – there is no such thing as ‘optimization’ with Java. And if there is, it is very limited. Its bytecode implementation would always be lagging behind variants of C/C++ and cannot make full use of processor features and would be about 3 times slow. So the very language is killing the efficiency designed into the hardware.
RAM
Now, here is the question – why 1 GB RAM only? The real question however, is – why do you want more? Well, because more RAM means more performance! Right?
Wrong. If you have 8 GB of RAM filled with 7.5 GB of garbage, then it is just as good as 512 MB of RAM. With implementations of Java, the garbage collection is a mandatory feature. As it turns out, everything about garbage collection is a problem, especially on a mobile device. If you run it often, that’s a problem. If you don’t run it often, that’s an even bigger problem. Well, why is it so?
Here is the answer: Garbage collection means that Java runtime would go about inspecting the program data in memory to find out the list of objects which need to be cleared. Then it would remove them from memory. This happens from time to time. This is costly when it comes to energy usage. And so is all the tracking and inspection.
The way RAMs of today work is – you start up the machine and from there on, every few microseconds, you send a power signal (like a clock tick) to the RAM or else it will lose the data. However, when you do a memory read/write, you use a lot more power than that.
Garbage collection does a lot of memory operations which means it is wasting your CPU cycles (for the algorithm that actually analyzes and sends the instructions to the processor for clearing memory) and wearing down your memory and the battery with all that read-write operations with no productive use.
Add to this means that Java needs a lot more memory to begin with. So all that 2 GB or 4 GB of RAM that you love talking about is not being used for any productive use at all. In fact, Android needs that much RAM to be at par and hence manufacturers build those specs. Its more of a necessity, less of a feature to boast about.
Again, if you do not run garbage collection, you will fill all that RAM pretty quickly and end up with a phone stuck in the middle of nowhere. That’s what the problem is with ‘not running’ the garbage collector.
With iOS, this is not a problem. There is nothing like garbage collection because there is no Java. On top of that, there is no true-multitasking so your background apps do not keep using all that memory either. Here is the translation of what I just said – RAM efficiency to its maximum. Add to that the way iOS deals with the apps running on it – there are hardly any points where you are going to need more than 1 GB. Yes, it would help if there was more, but that would also mean more power drain. Since iOS apps and iOS itself are very well optimized, there is hardly any reason for the phones to need more.
Graphics
So you have a phone. Large, good display and everything. But do you know that graphics system is probably more important than the processor in day to day usage? All that scrolling up/down, swipes, gestures and typing take a toll on the graphics unit, sometimes more than it takes on the processor itself. On iOS devices, since the OS has got more control over the apps, it can make a lot better use of graphics system built on the chip.
The new iPhones are coming in with one of the best graphics processing units that one can fit on-board and they compete well with the shiny new Nvidia Kepler K1s. That said, once again controlling their software gives them a lot of room for optimizing the usage of the system to the last bit. That is significantly great when compared to the Android side of things where hardware and software are two things that are put together so that they can work. No down-to-the-last-bit optimizations are done (or possible, in some cases) in this universe. It’s a marriage gone sour.
Welcome to 2017
Take the factors:
- Performance gains on hardware level because of more functional-processing units, larger issue width and larger MicroOps reorder buffer.
- Performance optimization on compiler level.
- Efficiency of the OS itself.
- Organization and maintenance of Apps at runtime.
- Memory usage efficiency
- Graphics usage efficiency
Compare that to the hardware used in top Android phones (or Windows too) of today and the way Android works and you would get a fair idea that with the engineering feat that Apple has achieved, it would take another two years (2014 is ending) at the very least for the competition to catch up. Summary Agreed, Apple is having a bad September this year with users complaining about iOS 8 release, bending phones, bad streaming and whatnot. But when it comes to the engineering marvel and the assurance about my device working through and well for years, I can put my hard-earned money on Apple for sure. Devices shouldn’t be just beautiful to look at but work well too. Those iPhones. Well yes. They do.