[Motley Fool]Intel is still a PC-dependent company, whether we like it or not

[NTMBK]

While the 70% number might make it seem as though Intel has effectively diversified away from the PC market, the company's client computing group alone still brought in 55.3% of the company's operating profits in the quarter. The reason for these weird numbers is, once again, the fact that there is an "all other" segment that is losing money, which inflates the percentage of the total profit pool to which the other segments appear to contribute.

It gets even better, though. If we assume Intel's former mobile and communications group lost about $1 billion in the quarter (this is just a ballpark estimate), then this would mean the former PC client group brought in about $2.6 billion in operating profit.

That's still more than any other of the company's operating segments.

http://www.fool.com/investing/gener...ricked-by-intel-corporations-financial-s.aspx

Nice dig into the numbers by Ashraf.

 

[know of fence]

To be fair it's PC and Mac.

 

[Fjodor2001]

Mac is a PC. PC does not imply Windows if that was what you meant.

 

[dark zero]

Actually this is the paradigm of Intel. Forcing to use Windows, a keyboard and a mouse.
They didn't.manage to use Android efectively, still some Apps doesn't work on x86 as expecting. That's why they are heavily promoting the use of Windows on tablets.... With a keyboard and mouse.

While AMD and Nvidia managed to go to the console world, Intel is still on the PC world dominating, but near all the incursions to the Mobile World ended to be a dissaster. Billion lost only to get up to 30% of the quote and that is thanks to Microsoft instead of Android

 

[dahorns]

Actually this is the paradigm of Intel. Forcing to use Windows, a keyboard and a mouse.
They didn't.manage to use Android efectively, still some Apps doesn't work on x86 as expecting. That's why they are heavily promoting the use of Windows on tablets.... With a keyboard and mouse.

While AMD and Nvidia managed to go to the console world, Intel is still on the PC world dominating, but near all the incursions to the Mobile World ended to be a dissaster. Billion lost only to get up to 30% of the quote and that is thanks to Microsoft instead of Android

What? Intel works fine on Android. I should know, I use an Intel powered Android phone. I haven't found an app that doesn't work.

 

[Fjodor2001]

What? Intel works fine on Android. I should know, I use an Intel powered Android phone. I haven't found an app that doesn't work.

Yes, in that is correct in general. However Android allows the possibility of adding native libraries to an App. That brakes cross ISA compatibility. So if you're unlucky you'll run into an App with an ARM-only native library, which will not run properly on an x86 device.

 

[dahorns]

Yes, in that is correct in general. However Android allows the possibility of adding native libraries to an App. That brakes cross ISA compatibility. So if you're unlucky you'll run into an App with an ARM-only native library, which will not run properly on an x86 device.

It is technically possible to run across a non-functional app. It isn't very likely. I haven't seen one.

 

[MarkLuvsCS]

Yes, in that is correct in general. However Android allows the possibility of adding native libraries to an App. That brakes cross ISA compatibility. So if you're unlucky you'll run into an App with an ARM-only native library, which will not run properly on an x86 device.

Isn't it just as likely an x86 library gets implemented and breaks on ARM?

 

[monstercameron]

Yes, in that is correct in general. However Android allows the possibility of adding native libraries to an App. That brakes cross ISA compatibility. So if you're unlucky you'll run into an App with an ARM-only native library, which will not run properly on an x86 device.

This is false, Intel has a piece of software that translate arm native binaries for their hardware.

 

[Fjodor2001]

Isn't it just as likely an x86 library gets implemented and breaks on ARM?

Possible, but probably not as likely, since ARM is the "de facto standard" for Android.

 

[Fjodor2001]

This is false, Intel has a piece of software that translate arm native binaries for their hardware.

Ok, that was interesting. I hadn't heard about that. Care to share some details? Is it something the user has to actively install, or does it come installed by default on some or all x86 Android devices?

And is the translation done at App install-time or at run-time?

 

[Lil'John]

This is false, Intel has a piece of software that translate arm native binaries for their hardware.

Actually, it is true but the chances of finding such an application is very low.

It is the same issue as if I coded directly against AVX 512 with no checks and tried to use the program on a Sandy Bridge computer.

 

[lamedude]

Its called libhoudini. Google not very helpful (just brings up Android-x86 pages) so I guess it comes preinstalled.

 

[kimmel]

Possible, but probably not as likely, since ARM is the "de facto standard" for Android.

Yet my ARM Nexus Android phone still has apps from time to time that don't work. Some apps just have crap compatibility across android versions and it's not always the underlying architecture causing compatibility issues. Intel Android devices don't really have any more issues than ARM chips. That is to say they both have issues.

 

[monstercameron]

Ok, that was interesting. I hadn't heard about that. Care to share some details? Is it something the user has to actively install, or does it come installed by default on some or all x86 Android devices?

And is the translation done at App install-time or at run-time?

Check libhoudini, and maybe @exophase could say something about this.

 

[Red Hawk]

[Motley Fool]

Why are you reposting clickbait?

 

[NTMBK]

Why are you reposting clickbait?

Why are you threadcrapping?

 

[dark zero]

Why are you reposting clickbait?

Actually they are saying something everyone we know. Intel doesn't know how to invade the mobile area. Is somewhat nerfing the Android performance in favor to Windows.

 

[Fjodor2001]

Yet my ARM Nexus Android phone still has apps from time to time that don't work. Some apps just have crap compatibility across android versions and it's not always the underlying architecture causing compatibility issues. Intel Android devices don't really have any more issues than ARM chips. That is to say they both have issues.

Sure but that's not due to the ARM hardware. It's simply crappy SW.

There's no hardware that can protect against poorly written SW yet unfortunately...

(Actually there is to a certain degree with MMUs preventing processes from writing outside their memory boundary and so on, but I think you get the point.)

 

[Fjodor2001]

Check libhoudini, and maybe @exophase could say something about this.

Ok, I just checked it out. Looks cool! But as I understand it libhoudini is optional, so it may not be installed on all x86 Android devices and I don't know how common it is (do phone manufacturers even install it by default?). Also, apparently the code will execute slower compared to native ARM (e.g. one test suite ran three times slower), so there's a performance penalty too.

 

[Exophase]

Check libhoudini, and maybe @exophase could say something about this.

You read my mind..

I doubt you'll find an x86 Android device that doesn't have libhoudini installed. It's closed source and I don't think it's part of Android proper (OEMs would instead normally get it from Intel, I presume) but there isn't anything that needs to be done to get it working on a particular device. It's possible to have an unofficial x86 Android platform where you just copy the libraries to get it working. For instance see here:

http://pilcrowpipe.blogspot.com/2014/03/running-arm-apps-on-android-x86.html

But libhoudini is a compromise. Last I heard, it was compatible with about 90% of Android apps that require ARM code. I don't know if this has been improved or not. The bigger problem is that, as is often the case with binary translation, there's a big overhead. From Intel's own papers, the average performance with SPECInt2k (I think is what they used) is well under 50% native (what you'd get with binaries compiled for x86). On real world programs the result may be worse because they have bigger icache footprints than SPECInt2k and translation exasperates icache pressure because it makes all of the code bigger.

On my program, DraStic, the performance hit from libhoudini is huge. The x86 native version is 2 to 2.4 times faster than the ARM version. I made a post about this here:

http://forums.anandtech.com/showpost.php?p=36368616&postcount=112

The thing to understand here is that the ARM native vs x86 native comparison isn't apples to apples to begin with, because the ARM native is much better optimized (has a higher quality recompiler and has a bunch of hand-written NEON assembly, while the x86 version relies on the compiler's auto-vectorization). If the x86 version was as optimized as the ARM version the difference would be more like 4x. So when dealing with highly optimized ARM code libhoudini doesn't generate good x86 code at all.

A lot of this could be down to it choking on NEON instructions. But for high performance apps this is a big deal.

Bottom line: if you're an app developer of anything that's even modestly CPU heavy you're really screwing over your (regularly growing) x86 customer base by not including a native build. Even a simple and rushed native build is probably going to be much better than relying on libhoudini.

I would say that at the very least, libhoudini puts perf and perf/W back a few years for Intel. So it's bizarre that their public commentary on it is that it's basically no problem, when they've put so much focus on how much of a perf and perf/W advantage their SoC has over their competitors. I think really this is just assuring would-be customers, while behind the scenes they routinely scramble to get popular app developers to properly support x86.

 

[Lil'John]

<snip>
But libhoudini is a compromise. Last I heard, it was compatible with about 90% of Android apps that require ARM code. I don't know if this has been improved or not. The bigger problem is that, as is often the case with binary translation, there's a big overhead. <snip>

Lots of good info and thank you for the post.

Do you have any info/data on how badly it makes "normal" application use?

The 50% number you mention sounds horrible until you find out that native ARM does a task in 0.5 sec while emulate does it is 0.75 sec.

 

[Exophase]

Lots of good info and thank you for the post.

Do you have any info/data on how badly it makes "normal" application use?

The 50% number you mention sounds horrible until you find out that native ARM does a task in 0.5 sec while emulate does it is 0.75 sec.

When I say 50% I don't mean the native version is 50% faster, I mean the translated version is 50% the speed of the native version. And this is native x86 vs ARM translated to x86 with both using the same compiler, not native ARM (that involves completely different CPUs, it's impossible to isolate that). So it means that if the x86 version does a task in 0.5 sec the ARM version translated to x86 does it in 1 sec.

In reality 50% is generous. I remember the number from the paper being more like 42%. They only got to around 50% by adding special instruction prefixes to x86 that are not part of Atom.

I don't have numbers for other apps, but moreover I don't really know what constitutes as normal for people. You'll have to determine if your workload includes a lot of apps running the CPU hard for long durations. That really varies from person to person. Obviously demanding emulators like mine would qualify, but also some classes of games.

But that's just for apps spending time in NDK code. If an app spends most of its time in Java code (Dalvik or ART compiled) then it won't matter. Or if you don't spend a lot of your phone time using apps (as opposed to builtin software like the phone's web browser) then it's also moot.

 

[Thala]

Bottom line: if you're an app developer of anything that's even modestly CPU heavy you're really screwing over your (regularly growing) x86 customer base by not including a native build. Even a simple and rushed native build is probably going to be much better than relying on libhoudini

The x86 customer base is such small, that i would not bother with x86 compilation at least not for Android. It just increases the verification effort.
It will run on the few x86 devices anyway, albeit quite a bit slower as you pointed out.

The 50% number you mention sounds horrible until you find out that native ARM does a task in 0.5 sec while emulate does it is 0.75 sec.

Were are talking strictly NDK here. So it is games mostly. If you are CPU limited it is the difference of 30fps to 10fps, which is big. In many cases however (causual games) you are not CPU limited at all. In this case you just pay the power penalty.

 

[kimmel]

The x86 customer base is such small, that i would not bother with x86 compilation at least not for Android. It just increases the verification effort.
It will run on the few x86 devices anyway, albeit quite a bit slower as you pointed out.

And that's why Intel needed to subsidize 40 odd million (mostly android) tablets last year. So Google and developers actually care about clicking the box to do the compilation.