[ElReg] ARM tests: Intel flops on Android compatibility, Windows power

[Vesku]

So Google didn't retain the main advantage of using a VM front end (Java in this case)? Allowed bare to the metal code for performance gains?

Wonder why Intel isn't more closely working with Google to provide blanket x86 Android compatibility. Dislike the idea of AMD benefiting or is Google just not interested?

 

[witeken]

Relevant or not, history unfortunately shows that binary translators are not the panacea of opening a market to an otherwise outsider.

I wish Intel the best, but they have to do something "more than..." if they want to crack this nut.

ARM knows and is counting on this, FUD is their first and best card to play at this time.

Intel released Silvermont and it destroyed ARM's ISA efficiency FUD campaigns by making ARM's efficiency look like utter [trash]. They will do the same with all other BS that comes out of ARM's marketing team, desperately trying to stop Intel marching into smartphone territory.

But one has to wonder, with Intel's top-notch crack design teams, wouldn't a custom designed ARM chip (ala AMD's goal) developed by Intel's design team for Intel's world-class process nodes be the bomb in the world of anything ARM?

Intel is trying their best to make a square peg fit into a round hole, but they'd do so much better developing a world-class round peg to fit into that round hole. So why not?

Why would they do that if "IA" works just as good. And if they made an ARM core, they'd have to pay the competitor for every chip they sell. Intel building ARM cores has only disadvantages.

No profanity in the tech forums, please
-ViRGE

 

[monstercameron]

Intel released Silvermont and it destroyed ARM's ISA efficiency FUD campaigns by making ARM's efficiency look like utter [trash]. They will do the same with all other BS that comes out of ARM's marketing team, desperately trying to stop Intel marching into smartphone territory.



Why would they do that if "IA" works just as good. And if they made an ARM core, they'd have to pay the competitor for every chip they sell. Intel building ARM cores has only disadvantages.

no flame intended huh. Max power and idle power are different things. Sure max power is similar but intel still cannot reach the idle power of arm.

 

[witeken]

Intel's definitely not going to break into the Android market any time soon by trying to shoehorn X86 on it, even at 14nm. Binary translation is simply not an elegant solution and developers really don't need to care about supporting X86 in the tablet / smartphone market to make money.

Intel's only chance here is if someone like Apple abandons ARM for X86 for iOS but I doubt this will happen considering the resources they've dumped into their own custom ARM development. Microsoft has a compelling phone OS now but the public has pretty much written them off like they did with BlackBerry / BB10 so I don't see X86 making inroads there either.

Companies like Qualcomm in the west are doing are doing a great job cornering the tablet and smart phone market while companies like Mediatek is handling the developing countries.

No room for X86 in this game.

Of course there is room for x86. I will tell you how it will roughly go: Intel releases 14nm Broxton and crushes the competition. Some company like Samsung will obviously use this chip because it will demolish the competition in all benchmarks. The other players can't just stand there and ignore Intel, they will also have to go to Intel because else they will fall behind with midrange performing ARM cores. Prices won't be an issue, since Intel has a tremendous transistor cost lead, and market share for them is the higher priority, which we see in their contra-revenue to sell 40M tablets this year.

At the low-end, things are similar. Intel won't use a miserable architecture and put 8 of those on the chip, but instead 2 of their Silvermont cores will eat those in-order cores for breakfast.

 

[witeken]

no flame intended huh. Max power and idle power are different things. Sure max power is similar but intel still cannot reach the idle power of arm.

"Are they [Intel] ever going to be the leaders in power efficiency? No, of course not." - Former ARM CEO Warren East

Also, this was ARM's rebuttal of an Intel slide, published in June when ARM obviously didn't have any Silvermont product available to measure power consumption to determine efficiency (just like TSMC's rebuttal of Intel's infamous transistor slide):

 

[AtenRa]

Of course there is room for x86. I will tell you how it will roughly go: Intel releases 14nm Broxton and crushes the competition.

What competition ?? Broxton is H2 2015

Some company like Samsung will obviously use this chip because it will demolish the competition in all benchmarks.

Again, what competition ??? H2 2015 all big ARM players will be at 20nm for over half a year.

The other players can't just stand there and ignore Intel, they will also have to go to Intel because else they will fall behind with midrange performing ARM cores.

What other players ??? the cheap China manufacturers than doesn't care about High-End but low cost products ??? Intel cannot compete in that low margin game.

Prices won't be an issue, since Intel has a tremendous transistor cost lead, and market share for them is the higher priority, which we see in their contra-revenue to sell 40M tablets this year.

Samsung alone sold 120M phones in Q3 2013, Intel is way off its league here.

Sorry but reality is not the way you describe it.

 

[Revolution 11]

Intel is trying their best to make a square peg fit into a round hole, but they'd do so much better developing a world-class round peg to fit into that round hole. So why not?

You have a very good point, IDC, but consider this. If Intel were to create a ARM chip on their 14nm process, what happens if it was a hit? All this would do is to prove that ARM has staying power, and the case for x86 would become weaker.

Consider why x86 is still relevant. There are two factors, program/OS compatibility and good enough performance at the desktop and server levels. The first reason is slowly but surely crumbling as ARM gains ground and experience with higher-power chips. The second reason is based on Intel's process lead over competitors, about 2 or 3 years ahead. That will also reverse as ARM creeps up the power envelope.

The catch-22 for Intel is that if they keep the door closed on ARM, they will slowly get weaker and weaker. But if they embrace ARM, it will hasten the death of x86 that much faster. The revenue growth of Intel in the ARM market will surely be slower than the decline of revenues from the shrinking ARM in this case.

The future is too open for Intel to not lose its power in the transition period. I am sure that we will continue to get good products from Intel but the writing is on the wall.

 

[witeken]

What competition ?? Broxton is H2 2015

I dunno, but it's obvious that if Broxton delivers on its promises, no 20nm planar design is going to come close to 14nm in terms of efficiency.

Again, what competition ??? H2 2015 all big ARM players will be at 20nm for over half a year.

And Intel at second generation Tri-Gate.

What other players ??? the cheap China manufacturers than doesn't care about High-End but low cost products ??? Intel cannot compete in that low margin game.

Of course it can. Intel's cost per transistor is vastly superior since it can take the foundry margin unlike Qualcomm and MediaTek and has a node advantage.

Samsung alone sold 120M phones in Q3 2013, Intel is way off its league here.

Sorry but reality is not the way you describe it.

Sure, it will take a few years. I foresee that 10nm Si/Ge vs. 20nm FinFET in 2016 should really be the tipping point for final ARM mass extinction. ARM has the same fate as AMD; inferior products won't really sell much.

 

[Exophase]

So Google didn't retain the main advantage of using a VM front end (Java in this case)? Allowed bare to the metal code for performance gains?

Yes, they made the NDK for running native code years ago, and if they hadn't I don't think Android would have taken off the way it had.

Think about it this way - if you're porting an app originally developed for another platform like PCs or a console it's probably not Java. And Java isn't going to run on iOS. If you want any semblance of sharing a code base between platforms doing your entire app in Java is not viable. It's enough of a pain to have to do any part of it in Java at all.

It doesn't really help either that for a while Android's Dalvik VM didn't even have a JIT, and the performance was still lacking enough that they moved to using AOT in ART.

Wonder why Intel isn't more closely working with Google to provide blanket x86 Android compatibility. Dislike the idea of AMD benefiting or is Google just not interested?

I think Intel is doing everything they can, including reaching out to big app developers to try to get them to optimize for x86. But they can't make people target x86, and Google isn't going to do more than make it a default in the toolchain.

 

[Exophase]

Intel released Silvermont and it destroyed ARM's ISA efficiency FUD campaigns by making ARM's efficiency look like utter shit. They will do the same with all other BS that comes out of ARM's marketing team, desperately trying to stop Intel marching into smartphone territory.

Let's put aside any conclusions and look at the factual content contained in this so-called FUD. Unless the research was done wrong (and it's actually easy to get this check right, you just have to look in the libs directory of the APK, I doubt they screwed up) 44% of the top 100 apps on Android contain compulsory ARM code. Code that will run at roughly ~60% the speed it would run at if it were compiled natively for x86.

I don't see how anyone can say that Intel will leave OEMs with no choice but to use their SoCs on merits of perf/W and perf alone, then pretend like this is a total non-issue and call it FUD.

 

[Homeles]

Why are people so confused about the meaning of FUD?

 

[erunion]

This thread is relevant to my interests.

Compare what ARM is saying here to what they were saying 2-3 years ago.

 

[Exophase]

Why are people so confused about the meaning of FUD?

Because sometimes terms allude to more than the basic definition of the constituent words in a phrase. You're not one of those people who thinks Super Mario Bros is an RPG because you play the role of Mario, are you? Historical context matters, and that context shows the word FUD being used to suggest spread of disinformation.

 

[Rezist]

I highly doubt Samsung/Apple will use x86 in there devices. So unless Google gets android running on x86 they really have no way in.

 

[Phynaz]

No wonder ARM is afraid.

Intel likes Chrome OS. Need proof? The company is apparently the number-two contributor to the operating system's code after Google itself. Intel and Google also co-hosted a small event in San Francisco today, intended to highlight Intel's commitment to Chrome OS and the number of PC OEMs that are shipping Intel-equipped Chromebooks.

http://arstechnica.com/gadgets/2014...-hour-battery-life-with-upcoming-chromebooks/

 

[crashtech]

I thought this issue had been solved long ago in PC space with improved HALs and APIs. Maybe mobile is not to the point where resources can be expended on such things and the code needs to be closer to the metal.

 

[Exophase]

I thought this issue had been solved long ago in PC space with improved HALs and APIs. Maybe mobile is not to the point where resources can be expended on such things and the code needs to be closer to the metal.

PCs have never at any point been anything but x86. They've never had the challenge of running code written for two different instruction sets. That's not something you can hide with HALs and APIs.

Apple had this issue and they solved it the same way the issue with Android is - by using fat binaries that have both PowerPC and x86 code for new binaries, and by using binary translation from PowerPC to x86 for old binaries. But the situation was ultimately a lot different because the ecosystem was more constrained and more influence by Apple, who had more of a direct interest than Google in making this work. The x86 CPUs were also getting a lot faster than their PowerPC predecessors, PowerPC was purely a legacy issue, and power efficiency wasn't a big issue.

No wonder ARM is afraid.

Yeah, $350 Chromebooks, terrifying.

Funny how when Intel writes about how much better they are than ARM - which they do all the time - you guys don't talk about how afraid they are.

Mind you, I don't think ARM is pulling this out of nowhere. It's definitely a calculated preemptive strike against the BayTrail Android tablets that are about to be released, as well as any Merrifield products (assuming those even really happen...) The focus here is entirely on Android apps for a reason.

You guys who are rooting for Intel to make it big in this space should take this more seriously, this many Android apps failing to support x86 is a big problem. And I say this as someone who is utterly shocked to see how bad the situation is, I would have never guessed it would be like this in 2014. When information on Silvermont first came out I was sure it was going to hit Android tablets and possibly even phones big this year, and that if my team's app didn't have proper support for it we'd be flooded with angry e-mails. Looks like a lot of other app developers didn't feel the same way, and at this rate they may not need to for a while.

 

[crashtech]

PCs have never at any point been anything but x86. They've never had the challenge of running code written for two different instruction sets. That's not something you can hide with HALs and APIs.

Apple had this issue and they solved it the same way the issue with Android is - by using fat binaries that have both PowerPC and x86 code for new binaries, and by using binary translation from PowerPC to x86 for old binaries. But the situation was ultimately a lot different because the ecosystem was more constrained and more influence by Apple, who had more of a direct interest than Google in making this work. The x86 CPUs were also getting a lot faster than their PowerPC predecessors, PowerPC was purely a legacy issue, and power efficiency wasn't a big issue.

Thanks for the nutshell explanation. It makes me wonder why Intel didn't get decent x86 Android implementation going long ago. They sure are late to the party.

 

[Exophase]

Thanks for the nutshell explanation. It makes me wonder why Intel didn't get decent x86 Android implementation going long ago. They sure are late to the party.

Android on x86 is fine, exactly what it needs to be and has been more or less since Medfield (although there's some claims floating around that it needed work for BayTrail, I really have no idea how that happened but it's probably not so much a CPU/x86 thing)

The problem is the apps. The ones using NDK - about 80% apparently - need to include ARM and x86 libraries to run natively on both platforms. Google has made this the default in the NDK toolchain. Intel has posted multiple documents about good practices for developing x86 on Android, they've offered help to app developers (they even said they dedicated like $100 million to this), there's even guides for using ICC instead of GCC which could even give x86 an advantage on Android. But they really can't do anything if app developers aren't interested, short of doing their best with a binary translator. Google could require apps that use NDK to support x86, but that's a really unattractive option for them and they have little incentive to do it. Right now there's no automatic regulation of apps at all, I doubt Google would want the added overhead. Nor would they want the backlash from app developers, not to mention the loss in sales and ad revenue. And it sets an ugly precedent - if they require ARM and x86 they'll look like they're playing favorites and MIPS then PowerPC then god knows who else will want to know where their support is.

 

[shady28]

This should be self-evident (x86 being slower on binary translation apps).


Hopefully the TF103C bay trail / android tablet will be out soon, and we should have a much better idea of what Intel's new chips can and can't do in the android space.

 

[Shivansps]

PCs have never at any point been anything but x86. They've never had the challenge of running code written for two different instruction sets. That's not something you can hide with HALs and APIs.

Apple had this issue and they solved it the same way the issue with Android is - by using fat binaries that have both PowerPC and x86 code for new binaries, and by using binary translation from PowerPC to x86 for old binaries. But the situation was ultimately a lot different because the ecosystem was more constrained and more influence by Apple, who had more of a direct interest than Google in making this work. The x86 CPUs were also getting a lot faster than their PowerPC predecessors, PowerPC was purely a legacy issue, and power efficiency wasn't a big issue.



Yeah, $350 Chromebooks, terrifying.

Funny how when Intel writes about how much better they are than ARM - which they do all the time - you guys don't talk about how afraid they are.

Mind you, I don't think ARM is pulling this out of nowhere. It's definitely a calculated preemptive strike against the BayTrail Android tablets that are about to be released, as well as any Merrifield products (assuming those even really happen...) The focus here is entirely on Android apps for a reason.

You guys who are rooting for Intel to make it big in this space should take this more seriously, this many Android apps failing to support x86 is a big problem. And I say this as someone who is utterly shocked to see how bad the situation is, I would have never guessed it would be like this in 2014. When information on Silvermont first came out I was sure it was going to hit Android tablets and possibly even phones big this year, and that if my team's app didn't have proper support for it we'd be flooded with angry e-mails. Looks like a lot of other app developers didn't feel the same way, and at this rate they may not need to for a while.

You whould be suprissed that some devs are actually willing to support if you ask, i did get MX Player to support MIPS JZ4770, by askwing them, the reapplys where all the same by them, if there is a market, they will do it.

 

[Exophase]

You whould be suprissed that some devs are actually willing to support if you ask, i did get MX Player to support MIPS JZ4770, by askwing them, the reapplys where all the same by them, if there is a market, they will do it.

Yeah, if there's a market... kind of a catch 22 there.

Intel has been asking people, trust me.

 

[Shivansps]

But Intel has nothing, Clover Trail was their first attempt, and it was not good, if they can get a $99 BT tablet that is competitive in performance to Allwinners and the like, things gona change, and fast, thats has to be their priority, +$200 tablets are not gona help if they did not archive that.

And remember that free Windows is coming to less than 9" devices, that means, OEM can create cheap BT tablets that dual boot Android and Windows.

 

[Arachnotronic]

Yeah, if there's a market... kind of a catch 22 there.

Intel has been asking people, trust me.

It's kinda hard to get devs on board without hardware out there...and it's hard to get OEMs to use your hardware if software's going to be a problem.

This is where Intel should whip out the old checkbook and start paying developers to port; offer the authors of the top 100 apps on the Google Play list anywhere from $100k - $1 million to port and all of a sudden your problems begin to disappear. Also, begin to offer more aggressive marketing of the apps that are recompiled...if you recompile for X86, you'll get a piece of Intel's marketing dollars. And, FFS, Intel should be liberal about sending developers the latest FFRDs packed with the latest silicon.

There are ways to go about this, but I feel that Intel is too busy with Chromebook BS to do anything about it.

How sad is this...by next year, AMD will be in a far better position to do well on Android with far less effort ;-)

 

[Shivansps]

Yeah thats a nice way to create something that will suck both on x86 and ARM, nah, they just need to let those OEM to make these $99 7" BT tablet that dual boot Android and Windows, there is just no way anything on ARM can do that.