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

[Exophase]

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.

Thanks to Intel's contra revenue program 46 million tablets sold last year have Atom processors, and most of them (AFAIK > 80%) run Android. I'll let you decide if you still think that's a very small customer base. We had an issue with the app not working on x86 Android devices with Lollipop and the volume of mail we got about it did not feel small.

Were are talking strictly NDK here. So it is games mostly.

NDK is very commonly used in the most popular Android apps.

It's not just games. Maintaining your app completely in Java means you either have to have a completely separate codebase for iOS (and various other platforms) or you have to forget about them. It's much easier to just use something you can mostly run on all of them like C++ and therefore rely on the NDK.

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.

Well yeah. You can also go ahead and use a Saltwell over a Baytrail if this is what you run and you don't care. Of course, you don't just mean "not CPU limited" (using < 100% CPU time) here but using < 33% of CPU time, which is quite a gap.

 

[Lil'John]

<snip>
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.

<snip>
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.

Thank you both for explaining this.

When I said "normal" use, I was referring more to "light" gaming, google maps, texting, etc. And not doing a 100k record pivot table in Excel

I'm still in the last century with a flip phone that takes me 5 minutes to text HI

 

[Thala]

Thanks to Intel's contra revenue program 46 million tablets sold last year have Atom processors, and most of them (AFAIK > 80%) run Android. I'll let you decide if you still think that's a very small customer base. We had an issue with the app not working on x86 Android devices with Lollipop and the volume of mail we got about it did not feel small.

If you include phones, it is in the single digit precentage range. Not convinced about the 80% number, but yes, Atom was going into quite a few low cost Android tablets.
But even single digit might feel huge when measured in number of emails

Well yeah. You can also go ahead and use a Saltwell over a Baytrail if this is what you run and you don't care. Of course, you don't just mean "not CPU limited" (using < 100% CPU time) here but using < 33% of CPU time, which is quite a gap.

Precisely, for <33% of CPU time the issue would be completely hidden (assuming 3x penalty for execution of dynamically translated ARM code on x86).
For 66% CPU time on ARM, you would have 200% CPU time on x86 -> framerate goes down by 50% and so on.
Point in case, Intel was demonstrating their ARM code translation technology with Angry Birds, which most likely is v-sync limited and has <33% load on even weaker ARM CPUs.

 

[Idontcare]

If you include phones, it is in the single digit precentage range. Not convinced about the 80% number, but yes, Atom was going into quite a few low cost Android tablets.
But even single digit might feel huge when measured in number of emails



Precisely, for <33% of CPU time the issue would be completely hidden (assuming 3x penalty for execution of dynamically translated ARM code on x86).
For 66% CPU time on ARM, you would have 200% CPU time on x86 -> framerate goes down by 50% and so on.
Point in case, Intel was demonstrating their ARM code translation technology with Angry Birds, which most likely is v-sync limited and has <33% load on even weaker ARM CPUs.

Presumably, in a non-compute bound environment, the only downside would be the elevated power consumption invoked because the processor simply has to do more computing as necessitated by the translation operations themselves.

As a consumer, that may or may not translate into a bulkier form factor (bigger battery) or less battery life...all depends on the computing efficiency of the underlying metal.

 

[Exophase]

If you include phones, it is in the single digit precentage range. Not convinced about the 80% number, but yes, Atom was going into quite a few low cost Android tablets.
But even single digit might feel huge when measured in number of emails

I was saying > 80% of the 46 million tablets with Atom ran Android (as opposed to Windows). So ~37 million Android tablets. I don't know what this is in raw percentage of Android devices currently in use but it's enough to care about. I mean, the most popular individual devices are maybe a few percent of the total for us but it'd be a crisis if the app performed badly on something like Galaxy S5.

Precisely, for <33% of CPU time the issue would be completely hidden (assuming 3x penalty for execution of dynamically translated ARM code on x86).
For 66% CPU time on ARM, you would have 200% CPU time on x86 -> framerate goes down by 50% and so on.
Point in case, Intel was demonstrating their ARM code translation technology with Angry Birds, which most likely is v-sync limited and has <33% load on even weaker ARM CPUs.

Most likely. Angry Birds is really old at this point.

 

[rootheday3]

houdini binary translation isn't continuously "interpreting" the ARM code into x86. It is more like a compiler that transforms the ARM code to x86 once and thereafter its the x86 code that runs. It is actually a bit more complicated than that because it can do a "quick and dirty" version to get the program running more quickly, then watch the program running to see where the hotspots are true and go back and do more optimizing on those.

It is true that the final result is that launching an ARM app will take a little longer and the final x86 code that is generated/executed, as Exophase says, may run slower due to limitations on how effectively houdini can optimize it. The result should be functional - perf/power implications will vary.

I agree with Exophase, the best bet is for app developers who are using NDK to compile to both ARM and x86 targets. My impression is that is happening much more these days than it used to. So owners of x86 Android devices should find that most NDK apps already have native versions of the apps they need.

 

[Spungo]

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

Probably because Google actively discourages people from using NDK.
To reach the largest audience, developers should write in Java. The only things written in a lower language like C are things that absolutely must have every last drop of performance.

It's not just games. Maintaining your app completely in Java means you either have to have a completely separate codebase for iOS (and various other platforms) or you have to forget about them.

They are doing the later. I recently switched to Android after my iphone died, and I was amazed by how much software was available. If something exists, it probably exists on Android. You can do weird stuff like run an HTTP server on your Android phone. The people making these programs don't seem to be porting them to iOS.

As a consumer, that may or may not translate into a bulkier form factor (bigger battery) or less battery life...all depends on the computing efficiency of the underlying metal.

Past Android phones had a terrible reputation for chewing through batteries. Running things through a virtual machine would certainly explain some of that problem. I remember John Carmack saying something like "Java is a great way to make a program run about 50% slower" (or take twice as much energy to do the same work)

 

[jhu]

They are doing the later. I recently switched to Android after my iphone died, and I was amazed by how much software was available. If something exists, it probably exists on Android. You can do weird stuff like run an HTTP server on your Android phone. The people making these programs don't seem to be porting them to iOS.

The Play store has apps that requires phone root access. I don't think the iTunes store has these types of apps. You would need to use a different app store after gaining root on iOS.

 

[Exophase]

They are doing the later. I recently switched to Android after my iphone died, and I was amazed by how much software was available. If something exists, it probably exists on Android. You can do weird stuff like run an HTTP server on your Android phone. The people making these programs don't seem to be porting them to iOS.

I doubt stuff like that is that popular (and like jhu says probably not possible) Other things like emulators are just not allowed on iOS's app store. But for the type of apps that are viable, allowed, monetized in any way whatsoever and even have a spec of general appeal it's pretty likely you'll see them on both iOS and Android, at least eventually.

 

[dark zero]

The problem if Android on x86 is that you can't run games or emulators propperly.
I tested KOF on a Asus Phonepad and performs somewhat laggy in some parts of the battle.

 

[shady28]

Not sure why this is even news, PCs and laptops are where Intel makes its money and everything else (phones, tablets) are markets it was late getting into and hasn't had significant success in penetrating. Ignoring their core market is coming back around to kick them (and MS) in the rear.

Intel and MS just aren't innovating, and MS trying to make desktops look/act like tablets didn't help. Stupid is as stupid does.

All the talk about Android - that's becoming the lowest common denominator in mobile (my phone is an Android phone). With the impending collapse of Qualcomm and the rise of the $99 Android phone I think that space is a financial dead end. Apple is going to eat the profitable portions of the mobile space alive, leaving only scraps for tier 3 chinese SoC makers.

There are some technologies coming that they should have pushed earlier. Like h.265. Half the bandwidth of h.264 at the same resolution. Try playing an h.265 video on a 2 year old laptop. It has 16x the CPU load of h.264 if it doesn't have hardware decode.

Context aware always on voice recognition would be another one. Personal cloud compute, not sticking all your data on MS or Google's cloud but making your own, would be another. Holographic user interfaces, yet another.

And why are LTE enabled laptops premium devices, when we can buy $99 LTE phones?

But no, Intel wants to penetrate the existing Android phone space. Good luck with that.

 

[Exophase]

The problem if Android on x86 is that you can't run games or emulators propperly.
I tested KOF on a Asus Phonepad and performs somewhat laggy in some parts of the battle.

That's just one datapoint.

Some emulators are more optimized for ARM but others come from PC ports that are actually more optimized for x86. Some are pretty evenly optimized for both.