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

[Exophase]

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.

There's at least enough workable hardware that you can test your app on x86 if you want to. We have a Venue 8 for example. On the other hand, we're getting reports that performance of our app on Galaxy Tab 3 10.1 is dramatically slower than on Venue 8, which is disturbing and we have no idea why. Sadly that's kind of the nature of Android, it's a nightmare trying to get things working like you think they should work across a wide variety of devices :/

Or by hardware out there did you mean the userbase? Then yeah, that's a problem and catch 22.

This is where Intel should whip out the old checkbook and start paying developers to port. Otherwise, Intel should just build a custom ARM core and call it a day if they're not willing to do what is necessary to establish X86.

Well yeah, you have to wonder where that $100 million actually has been going. Maybe they have been paying people. I have a good feeling they did pay AnTuTu (and tailored ICC to give better results for it). Which - depressingly - seems to have been a lot more effective than paying off app developers because until now almost no one cared to look. And yet benchmark results get plastered everywhere.

I think people by and large still won't care about this. But OEMs probably do, and that could have been a big contributor in making them mostly reluctant to use Intel's SoCs so far.

 

[ninaholic37]

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/

Heh. Funny how it says "Need proof?", then doesn't give any proof (the word "apparently" is their proof?). When did Intel start contributing code? Number two could mean Google did 99.9%, and Intel threw in 0.1% of code last minute and that the code was specifically made to tailor/fix something with Baytrail (assuming they did "apparently" contribute anything at all). Chrome OS isn't really much of anything to begin with, since you need to have Google Chrome to do anything in it, which works fine on Android/Windows/Linux/etc. already. :sneaky:

 

[beginner99]

I owned a RAZR I (single core Atom SOC) for about 2 month. Then it was stolen...I then bought the LG Optimus G (which is very similar to the nexus 4 but has double the internal flash at the same price...).

I never had any problems with compatibility on the RAZOR I but some Apps do load A LOT quicker on the LG (eg. ARM) phone. Battery life however was way, way better on the RAZR I (but smaller, lower res screen) and also the form factor and build.

Conclusion: The ARM phone sure performs better but then it was also more expensive.

 

[teejee]

.

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



.

This is wrong, a common misconception though. This is basic finance theory. Remember that it is profitability measured in % that is important for a company.
If you outsource your production then you share the profitability measured in $ with the production company but you maintain the same profitability in %.

Of course there are other pros and cons by not owning your production though.

 

[NTMBK]

No wonder ARM is afraid.



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

That's not a sign of strength. Intel needs to pour resources into software development for Android and ChromeOS, because nobody else will. Intel have basically done the entire Android port, the binary translator, porting core libraries etc by themselves, with all the cost that entails. No ARM vendors need to foot costs like that, because Android is built for ARM by default.

 

[SammichPG]

The main factor is what OEMs want to avoid: playing the script of the perconal computer market all over again with Intel taking a big % of the bom.

It'll take several iterations of Intel subsidizing their socs while providing software support and utter technical domination using the most expensive productive processes to gain significant market in the mobile.

All that ARM has to do is provide competitive archs that work well on cheaper foundries.

ARM socs are already good enough for most people and most of the posters here have a skewed market perception by the subsidized high end smartphones while in the rest of the world most people pay upfront for their phone making the decision to spend 800$ on a phone a rather tough sell.

Arm thrives with the socs powering the lumia 520s and the mediatek socs in chinese smartphones, does Intel really want to compete there?

It's a lose lose situation for Intel.

 

[Galatian]

And the question still remains if x86 can actually scale down enough to be on performance per watt parity with ARM. I mean with all their "baggage" they've been carrying around since the invention.

 

[TreVader]

ARM doesn't need FUD to outperform and outsell intels mobile offerings, ARM is already far more power efficient on a much older process.



I see no reason anybody would consider an intel processor for Android, and its not like Bay Trail is fast enough to run windows well.



ARMv8 is the future of mobile. x86 has more to fear from ARM than the other way around.

 

[Mondozei]

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.

There is always room in the game, but you have to have a comparable advantage. Everyone said Intel's node advantage would allow them to crush Qualcomm a few years back as they were entering the SoC arena in a serious way. Well, that didn't happen.

Qualcomm has done very well. Intel's only recourse for now is lower cost, which they are now doing ("contra revenue"). Until Intel has a strong integrated LTE solution, they will need to be cheaper. But of course x86 can make non-trivial inroads into the Android space over the next few years, but unlike many here I neither count them out nor say it is a done deal because of their node advantage.

 

[TreVader]

The main factor is what OEMs want to avoid: playing the script of the perconal computer market all over again with Intel taking a big % of the bom.

It'll take several iterations of Intel subsidizing their socs while providing software support and utter technical domination using the most expensive productive processes to gain significant market in the mobile.

All that ARM has to do is provide competitive archs that work well on cheaper foundries.

ARM socs are already good enough for most people and most of the posters here have a skewed market perception by the subsidized high end smartphones while in the rest of the world most people pay upfront for their phone making the decision to spend 800$ on a phone a rather tough sell.

Arm thrives with the socs powering the lumia 520s and the mediatek socs in chinese smartphones, does Intel really want to compete there?

It's a lose lose situation for Intel.

Intel can't compete with Apple in mobile, a company that literally designed their first processor last year.


The level of blind faith this forum has in intel is baffling, It wasn't even 10 years ago when intel was almost chased out of x86 by AMD64 and K8. You guys act like intel is somehow necessary to mobile when the question you should be asking is how intel is going to do something they've never come close to doing before: CREATE A GOOD MOBILE SoC.

 

[itsmydamnation]

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?

I know im late to the party, fact is it doesn't matter. Why doesn't it matter? When was the last time Apple, Samsung, Sony looked at acer , lenovo and Co and went we want to be like them. Thats right never! That is why Atom will fail, because Intel are to self absorbed and protective of itself to offer a product the actual names in the actual market would want to build a platform around.

they dont want to be a foot note on intel growth, they want that growth for themselves.

 

[witeken]

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.

Because a smartphone (OS) consists only out of apps?

 

[witeken]

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.

Why, just because it's x86 instead of ARM? BTW, Android is already running on x86, and there are a few phones like Lenovo K900 and Motorola Razr i. And I've never seen any reviews claiming anything like what ARM claims now, so why would I suddenly buy their marketing talk? History clearly suggest they don't hesitate to spread FUD about Intel/x86.

 

[witeken]

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.

Late to the party? Intel has the first and currently still only 64-bit version of Android since January. And it has 64-bit CPUs for many, many years longer than ARM.

 

[SlimFan]

On any given device, what percentage of apps from the Google Play store work? I always thought the app lists were unique per device as some apps are listed as incompatible. For example, on my RAZR I, I can't use any google wallet like apps because the device hasn't been certified. Would that count against my "top 100" incompatibilities? ARM doesn't mention what didn't work, or whether that had anything to do with x86. I can offer my anecdote and say that I can run the apps that I download, and they work. I might have 100 apps that I've downloaded in the 2 years that I've had the device, but I haven't counted.

For the efficiency / overhead of binary translation, it's interesting that the only apps ARM can provide data on are the very ones that are irrelevant. If they have access to an x86 native version, then it's irrelevant what the "overhead" is on that particular app. Geekbench and Epic Citadel are available as a native x86 app, as shown. Therefore the emulation overhead is completely irrelevant in this case. If Intel went off and made sure the apps with significant amounts of NDK were converted, and left the rest, then the average overhead would be irrelevant. The fact that ARM was able to side-load a non-native version doesn't change that.

It's also really neat that ARM is suddenly talking about SOC power instead of CPU power. All of this ARM vs x86 and "x86 tax" suddenly, according to ARM, isn't what we should be talking about.

He chose to test the entire SoC, he said, because power claims for just the CPU, just the GPU, or just the video engine can be misleading, seeing as how it's the entire SoC that needs to be taken into consideration.

In fact, in this case, ARM managed to choose an SOC that has no ARM developed IP in it at all. This isn't Mali graphics, and it's not an A5/A7/A9/A15. Instead it's Adreno + Krait.

"The performance is not as high as we're seeing in the Intel device," Watt admitted, "but again the tests are running under a Windows environment, but you can see in terms of efficiency, we're getting much lower power."

Personally I'd prefer talking about energy when considering efficiency, rather than power, especially if one device is faster than the other. If we really care about the end user, why stop at SOC power? Shouldn't it be platform power? I'd also be curious how this would change with Chrome or Chrome+AdBlock, etc. Oh, yeah, you can't do that on the Windows RT device.

 

[witeken]

Heh. Funny how it says "Need proof?", then doesn't give any proof (the word "apparently" is their proof?). When did Intel start contributing code? Number two could mean Google did 99.9%, and Intel threw in 0.1% of code last minute and that the code was specifically made to tailor/fix something with Baytrail (assuming they did "apparently" contribute anything at all). Chrome OS isn't really much of anything to begin with, since you need to have Google Chrome to do anything in it, which works fine on Android/Windows/Linux/etc. already. :sneaky:

Want to start a semantic discussion?

"Apparently" doesn't necessarily imply uncertainty. You can also use it to say that you didn't know it before, and it kind of surprises you.

I couldn't find a source with Android contributors with a quick Google search, but I found this for Linux:

 

[witeken]

This is wrong, a common misconception though. This is basic finance theory. Remember that it is profitability measured in % that is important for a company.
If you outsource your production then you share the profitability measured in $ with the production company but you maintain the same profitability in %.

Of course there are other pros and cons by not owning your production though.

TSMC and the chip designers both need to survive.

Intel takes a wafer, makes CPUs out of it, and sells them for some money.
AMD, however, takes a TSMC wafer, makes CPUs out if, and on top of that it pays TSMC for TSMC's margin on the wafer, because selling wafers is what TSMC makes its money out. Fabs are expensive, so they obviously need a lot of money to make new fabs and keep up with Moore's law. This directly leads to a higher price per wafer.

So, because of TSMC, AMD's wafer will have a much higher price. If both Intel and AMD made the same chip on the same process with the same yields, this means they will both get the same output. But because AMD's wafers are more expensive, they make less profit or they need to increase prices.

Higher wafer prices => higher price/transistor. And it is price/transistor that actually determines how far you are on the curve of Moore's law.

Things get even worse when you have a 1 node lead, which would for a fabless company, after paying the foundry tax, equate to a disadvantage of more than 1 node.

 

[AtenRa]

TSMC and the chip designers both need to survive.

Intel takes a wafer, makes CPUs out of it, and sells them for some money.
AMD, however, takes a TSMC wafer, makes CPUs out if, and on top of that it pays TSMC for TSMC's margin on the wafer, because selling wafers is what TSMC makes its money out. Fabs are expensive, so they obviously need a lot of money to make new fabs and keep up with Moore's law. This directly leads to a higher price per wafer.

So, because of TSMC, AMD's wafer will have a much higher price. If both Intel and AMD made the same chip on the same process with the same yields, this means they will both get the same output. But because AMD's wafers are more expensive, they make less profit or they need to increase prices.

Higher wafer prices => higher price/transistor. And it is price/transistor that actually determines how far you are on the curve of Moore's law.

Things get even worse when you have a 1 node lead, which would for a fabless company, after paying the foundry tax, equate to a disadvantage of more than 1 node.

You dont count Intel's R&D cost to make the process available for manufacturing. That cost is added to the final product, TSMCs R&D cost is added in the Wafer.

 

[witeken]

And the question still remains if x86 can actually scale down enough to be on performance per watt parity with ARM. I mean with all their "baggage" they've been carrying around since the invention.

You need to catch up. First, Intel bears said that x86 wasn't efficient enough. With Silvermont, Intel pulled those people back to reality of what a good microarchitecture with a great transistor can do, regardless of ISA. Then, those people said that Intel wouldn't be price competitive, or that they wouldn't make money. The thing that's now being said, however, is that x86 doesn't run Android well.

 

[Galatian]

Hmmm and Silvermont is on 22nm, isn't it? So shouldn't we wait what all the manufactures can pull with ARM on 22 nm?

Don't get me wrong: Intel made huge progress, but I don't think comparisons can yet be made.

 

[witeken]

Intel can't compete with Apple in mobile, a company that literally designed their first processor last year.


The level of blind faith this forum has in intel is baffling, It wasn't even 10 years ago when intel was almost chased out of x86 by AMD64 and K8. You guys act like intel is somehow necessary to mobile when the question you should be asking is how intel is going to do something they've never come close to doing before: CREATE A GOOD MOBILE SoC.

Now that the foundries are falling behind at the end of Moore's law, people are already asking questions if maybe Nvidia will produce their chips at Intel. Because why built a GPU on a 28nm node when another company already has a 14nm Tri-Gate node with much higher performance, density and power consumption? This need for better transistors is exactly why Intel will succeed in their mobile campaign: they're the only one who can offer those.

 

[witeken]

Hmmm and Silvermont is on 22nm, isn't it? So shouldn't we wait what all the manufactures can pull with ARM on 22 nm?

Don't get me wrong: Intel made huge progress, but I don't think comparisons can yet be made.

The problem is that TSMC's 20nm won't be the same as Intel's 22nm. TSMC's 20nm will have higher density, but it won't have FinFETs, for example. Intel's 28nm SoFIA EOY 2014 should be interesting. But if you see that Intel claims 50% lower power with FinFETs and Silvermont has about 2x higher efficiency than Apple's A7, then I think it isn't a big deal. Also, there a scientific study about this, that concluded the same.

 

[Galatian]

The problem is that TSMC's 20nm won't be the same as Intel's 22nm. TSMC's 20nm will have higher density, but it won't have FinFETs, for example. Intel's 28nm SoFIA EOY 2014 should be interesting. But if you see that Intel claims 50% lower power with FinFETs and Silvermont has about 2x higher efficiency than Apple's A7, then I think it isn't a big deal. Also, there a scientific study about this, that concluded the same.

Interesting...can you link to that study? Might be worth the read.

Still bad that Intel got so late into the game. I'm heavily invested in the Apple ecosystem right now, but I would love to have an all x86 system like the Windows + Intel platform now provides.

 

[dahorns]

I see no reason anybody would consider an intel processor for Android, and its not like Bay Trail is fast enough to run windows well.

My Dell Venue 8 Pro would disagree with you. Windows 8 runs very well on it.

 

[witeken]

Interesting...can you link to that study? Might be worth the read.

Sure: Power Struggles: Revisiting the RISC vs. CISC Debate on Contemporary ARM and x86 Architectures.

A related issue is the performance level for which our results hold. Considering very low performance processors, like the RISC ATmega324PA microcontroller with operating frequencies from 1 to 20 MHz and power consumption between 2 and 50mW [3], the overheads of a CISC ISA (specifically the complete x86 ISA) are clearly untenable. In similar domains,
even ARM’s full ISA is too rich; the Cortex-M0, meant for low power embedded markets, includes only a 56 instruction subset of Thumb-2. Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy.