Slashdot Mirror
Intel Confronts a Big Mobile Challenge: Native Compatibility
smaxp writes: "Intel has solved the problem of ARM-native incompatibility. But will developers bite? App developers now frequently bypass Android's Dalvik VM for some parts of their apps in favor of the faster native C language. According to Intel, two thirds of the top 2,000 apps in the Google Play Store use natively compiled C code, the same language in which Android, the Dalvik VM, and the Android libraries are mostly written.
The natively compiled apps run faster and more efficiently, but at the cost of compatibility. The compiled code is targeted to a particular processor core's instruction set. In the Android universe, this instruction set is almost always the ARM instruction set. This is a compatibility problem for Intel because its Atom mobile processors use its X86 instruction set."
The natively compiled apps run faster and more efficiently, but at the cost of compatibility. The compiled code is targeted to a particular processor core's instruction set. In the Android universe, this instruction set is almost always the ARM instruction set. This is a compatibility problem for Intel because its Atom mobile processors use its X86 instruction set."
Can I just say that I remember people moaning about the ARM not being x86 compatible when it came out in '87 or thereabouts.
(Yes, am I that old.)
So the core of the app, the 'engine', is in C++ and must be natively compiled, while the UI and such is in Java. Naturally, the binary's compiled for ARM first. This actually runs on a lot of Intel Android tablets because they have ARM emulators. But, thanks to a user finally asking, I put in some time and now I can make an Intel version. (Heck, the original source was written for Intel anyway, so it wasn't a big stretch.) The existing tools are sufficient for my purposes. And it runs dramatically faster now on Intel.
However, for the developer it's mildly painful. The main issue is that you have a choice to make, with drawbacks no matter which way you go. You can include native libraries for multiple platforms, but that makes the APK larger - and according to a Google dev video I saw, users tend to uninstall larger apps first. In my case, it'd nearly double the size. So instead I'm putting together multiple APKs, so that ARM users get the ARM version and Intel users get the Intel version - but only Google Play supports that, not third-party app stores. I haven't looked into other app stores, and now it's less likely I will.
Note that native development can be important to apps for a non-technical reason: preventing piracy. An app written purely in Java is relatively easy to decompile and analyze, and pirates have a lot of techniques for removing or disabling licensing code. Adding a native component makes the app much harder to reverse-engineer, at least delaying the day that your app appears on pirate sites.
PHEM - party like it's 1997-2003!
They had fat binaries for apps compiled to both PPC and x86, but that wasn't the only solution, since with just that you wouldn't be able to run apps until the developer recompiled and shipped a new version. They also had a binary translator to run unmodified PPC binaries on x86.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I still don't understand why APKs are not just pure LLVM byte code, and either the store or the phone completes the byte code to native compile, including the final optimization passes...
Regards,
-Jeremy
x86 is good in the same way that a modern police baton is good - its still a stick you hit people with, and serves its purpose. But there are better weapons available.
So saying that x86 is great because technology has had to improve to make up for its deficiencies is just stupid. x86 isn't some wonderful architecture, putting 4 cores on a single die isn't anything that x86 made happen that others couldn't do, fabrication techniques that shrunk the die size isn't anything to do with x86 either.
Think that a motorola 68000, way back in the day was better than the old 286s it compared to. Imagine that the 68000 took off instead of the 286 - if MS and IBM had built DOS for 68000 instead of x86... today we'd be in pretty much the same position but with a different chipset. But it would be faster and cheaper and more efficient.
BTW x86 32-bit doesn't run on x86_64 either. The software and chips have emulation routines that allow it to happen. The same as happens with A64 that allows old A32 and T32 instructions to still run on the same chip.
You figured that out...how exactly? It's a RISC, RISCs have historically scaled very, very well.
What does that even mean any more? Visibly-CISC processors are now internally-RISCy (All of them since Am586) and there is actually a benefit to be derived from variable-length instructions and the x86 decoder is a small portion of the modern CPU. But ARM cores have never gotten up into the big, big clock rates because they've never been designed for them, instead targeting efficiency. That's a much easier goal to reach than bigger shinier if you're on a constrained budget, and it certainly has paid off for them now that we care about power budgets, but they're still having trouble scaling.
I'd sure like to hear anything insightful anyone has to say about XScale. It was the fastest ARM implementation of its day, but it was also the most power-hungry, and AFAICT Intel never really managed to scale either performance up or power consumption down after their initial release, and then dropped it. Is that how it played out?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
First of all, at this point, it is misguided to talk about x86 as an architecture; there is generally little or no architectural overlap between two x86 processors that are a few generation apart. x86 is an instruction set, or even more correct, a family of instruction sets. The distinction is important, especially in the age of complex instruction decoders; a lot of the more complex x86 instructions are internally decoded into smaller pieces, and one could say that the CPU internally runs its own, different instruction set. The fact of supporting a certain instruction set nowadays says almost nothing about the underlying architecture.
So we're talking about an instruction set. One that was conceived in an age where manual coding in machine language was far more common than it is today; the original x86 instruction set was designed to be easy for a human bitpusher to handle, whereas newer instruction sets like ARM are more geared to get the most out of a decent optimizing compiler. What followed for x86 was extension upon extension, and the instruction set is now so byzantine that x86 is a very difficult market to break into; the design complexity of the decoder can probably be overcome, but all the cross-licensing between Intel and AMD cannot. The complex, organically-grown instruction set also leads to some waste of silicon in having to support all those instructions, and waste of performance/energy efficiency in that the instruction set is not designed from the ground up towards efficiency. People on the x86 side make a compelling argument that this has become negligible, but the fact remains that I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.
My first computer contained a Z80, a true 8-bit processor (your claim that x86 has 8-bit mode is false; the lowest common denominator for x86 is the 16-bit 8086, which you're probably confusing with the 8-bit 8080 which is not x86 compatible). More relevantly, I also have experience running scientific workloads on a whole zoo of processors. I have particularly fond memories of the later Alphas, which wiped the floor with everything up until and including the Pentium 4, and were very competitive even against Athlon 64 and Core2 performance-wise (but not price-wise). Repeat after me: x86 has zero inherent architectural advantage!!! The big advantages it has is (1) economies of scale and (2) the higher profits of a mass market that generate more revenue to be pumped into R&D. There hasn't been a kid on the block that could compete on these fronts - not until ARM came around.
While Intel is sitting on an impressive pile of cash and R&D potential, their attempts to match ARM in performance/W are so far unsuccessful when looking at non-biased benchmark results, and ARM has profited from this in establishing a mass market of its own. Things are about to get interesting from here onwards. I can't predict whether x86 or ARM will win. The outcome might be coexistence, with x86 keeping its dominance in the server room, workstation, office and hard-core gaming, and everything else becoming ARM. Whatever the outcome might be, I am firmly rooting for ARM, though. Technically, it's leaner, more rationally designed instruction set that is more frugal with resources (die size, cache & memory usage) and better reflects present-day usage cases. And the fact that it's relatively straightforward for a newcomer to license it and start making chips will bring some healthy competition onto the stage.
First of all, at this point, it is misguided to talk about x86 as an architecture;
Thank you. I got a raft of shit when I argued that there was no such thing as an x86 instruction set architecture any more just recently, and hasn't been since the Am586 took x86 into RISC-land.
I'm still not seeing any x86 processor getting (unbiased) performance/W scores that are close to common ARM processors.
On the other hand, I'm seeing a pretty massive gap between the high-end in x86 (really, amd64) processors and in ARM processors. This doesn't mean ARM can't be scaled up, but I think it's worth remembering what x86 went through in being scaled up. It didn't happen overnight. It may well be that x86-compatible processors embrace low power consumption before the ARM-compatible processors scale up to the high end.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
They both shifted from a proprietary processor and chipset to a more common and popular platform. Both platforms had specific benefits over x86 until x86 scaled far and beyond what they both offered.
In my opinion, Apple shifted to x86 mainly for logistical reasons not architectural reasons. The problem with staying with PPC was two fold: 1) Intel offered better laptop chips and 2) Apple was going to have problems with PPC supplies.
The first one is fairly self-evident. Intel laptop chips were being updated all the time and they were better at power efficiency than the PPC4 based chips Apple was getting from Motorola. IBM never manufactured a mobile PPC5 chip probably because of the heat dissipation problems. If Apple stuck with IBM and PPC then they would have to be further behind Intel based mobile chips.
The second one is more complicated. Motorola then IBM supplied Apple with chips but even with millions of chips a year, Apple would be a small customer to either company. Compounding this is that Apple's chip was heavily customized so that it was costly to maintain and develop for any chip maker. Apple needed those customizations as other PPC chips by Motorola and IBM were not designed to be used for consumers in computers. For example IBM's chips for servers do not need any multimedia processing capabilities as they were designed for servers not desktops.
As such it was burden for Motorola and IBM to make changes to any supply schedules. If Apple got a sudden upswing in orders, IBM wouldn't be able to keep up. Also IBM would have to dedicate more and more resources to develop newer generations with Apple's changes and IBM was reluctant to spend possibly billions in research for one small customer.
Intel on the other hand was better logistically. Any development Intel did for Apple could be used for other customers. In fact, the ultrabook specifications came out of Intel's work with Apple on the MacBook Air.
Well, there's spam egg sausage and spam, that's not got much spam in it.