Intel, Google Team To Optimize Android For Smartphones 187
angry tapir writes "Intel and Google announced on Tuesday that they would partner to optimize future versions of the Android OS for smartphones and other mobile devices using Intel chips. Intel CEO Paul Otellini demonstrated a smartphone with the upcoming Medfield chip running on Android during a keynote at the Intel Developer Conference being held in San Francisco. However, Otellini didn't mention the version of Android running on the smartphone. Intel wants to make x86 the architecture of choice for smartphones, and porting Android will provide a larger opportunity to the chip maker in the smartphone market, Otellini said."
Should be relatively platform agnostic already (Score:3)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I take it you haven't heard of the Android NDK. You can compile native code - not everything has to run in the virtual machine environment.
I guess the devs that chose to use the NDK will soon suffer in the form of a reduced audience; assuming Intel's plans work out, that is.
Re: (Score:2)
You can even compile multiple targets at the same time and include them all in the same .apk file in the same fashion as Apples Universal Binaries.
Re: (Score:2)
Which is pretty much anyone who wanted to write a cross-platform app. The defacto standard for that is still write in C or C++ and port only the UI. Otherwise you end up completely rewriting your application 3-6 times, and fixing every bug 3-6 times.
Re: (Score:2)
Re:Should be relatively platform agnostic already (Score:4, Interesting)
There are Android-specific patches to the kernel, including an extensive security model, custom locking mechanism, and different frame buffer support among others. A lot of this code may have some ARM-only trickery. Add to that the library of redundant device drivers that phone companies write and discard (that may or may not work) and you have yourself a chunk of work there.
It doesn't help that Google has no interest whatsoever in getting their code merged into the Linux kernel properly. In fact, that's the main problem with Android. If their patches were merged and properly supported, device drivers would be better and it would be easier to do an x86 (or ppc or what have you) port. It's too bad since userspace is basically all java- the apps should just work on a new arch, but that benefit is torpedoed by Google's lack of follow-through in working with the community to get stuff merged.
In other news, Meego certainly seems doomed to hacker-land.
Re: (Score:2)
"Platform agnostic" would be great if "Platform" would also include the one you can sync the phone with.
I am running Linux on the desktop and would be willing to purchase any phone (be it Android, iOS or even Windows-based) that can reliably sync with Linux and I am also willing to pay a few hundred $ more for it, if necessary. I don't really care about what the phone itself is running.
All I can find on the Internet about Linux-sync is either horribly complicated (setting up your own sync-server, etc.), c
Re: (Score:3)
The Native code library (NaCl) will be unportable currently.
Native code is not NaCl. NaCl is an entirely different beast, x86 in a browser, in theory sandboxed.
However, they plan to base the next version on LLVM making that too platform independent.
LLVM won't help anything be platform independent. Native code is platform specific, thats why its called native. Using LLVM to produce byte code that runs in an interpreter like Dalvik is not making native code platform independent.
Re: (Score:2)
The nice thing with LLVM is it can produce native and bytecode. The bytecode version has the advantage of being able to be natively compiled into a binary at runtime.
Apple does this with their GPGPU and OpenCL stuff - the code's compiled with LLVM and OS X figures out if it's mor
Re: (Score:2)
Actually, what LLVM brings to the table is final code delivery. If you've got a common intermediate code generator that produces fairly to really good native code (LLVM...) you can submit the intermediate code as part of an installer and as part of the process spin out a final binary. In theory, of course. So far, nobody's actually DONE something like that- but it's been more to the lack of someone seriously attempting it than other reasons at this time.
Re: (Score:2)
Irrelevant. Open source projects like this don't go upstream for Android because they're made by "the community" and not some large partner corporation.
Bye, Bye Meego (Score:3, Insightful)
Well, if you were delusional enough to hold out hope for Meego after it was dropped by Nokia and then "development hold" by Intel, this is your wake-up call.
Re: (Score:3)
It's not dead, it's pining for the fjords!
Re: (Score:2)
Yeah, I'm so stupid for wanting a FOSS Linux distribution to succeed in the face of a pseudo-Open and a pile of totally closed platforms.
Go Google! Way to undermine actual FOSS projects!
Re: (Score:2)
Here: http://www.gsmarena.com/rumor_intel_to_discontinue_meego_development_temporarily-news-3087.php [gsmarena.com]
and here: http://arstechnica.com/open-source/news/2011/09/intel-denies-giving-up-on-meego-but-it-doesnt-mean-much.ars [arstechnica.com]
Re: (Score:2)
Look who's trolling now. Stay at zero, anonymous shit.
Re: (Score:2)
Re: (Score:2)
Something tells me you know less than you think you do.
Oh you mean MAEMO. Yes, MAEMO. Not MeeGo.
Thank you for your highly opinionated... opinion. Your experience (except for Hildon Application Manager) runs completely counter to mine.
x86? (Score:5, Insightful)
Re: (Score:2)
I don't even have to mention incidents, just company names: IBM, MicroSoft, Oracle, Cisco, Apple, Rambus.
Remember, a lot of the time they get away with it (Windows Office, Powerpoint). Even though they are pushing an aging and ill suited CPU, t
Re: (Score:2)
I'm just surprised Google would go along with this.. but I guess the tech will speak for itself in the end.
Re:x86? (Score:4, Interesting)
I'd be a bit shocked if the next Nexus whatever phone happens to have Intel inside, Intel just hasn't cracked the low power problem very well; but they move Atoms like crazy for slightly higher powered applications. It isn't make-or-break; but I doubt that Google would mind displacing WinCE in a few of the ubiquitous-but-wastefully-overpowered Kiosk/Signage/etc. applications that are typically intel/WinCE or intel/XP-embedded powered today.
Plus, while it isn't officially blessed and released at present, Android already runs on x86. The "GoogleTV" products are all Android running on an Atom-based STB SoC(the CE1400 if memory serves.)
Re: (Score:2)
Monopolists are incapable fundamental change. They will do everything within their power to alter anything except their core monopoly. This includes lawsuits, buying legislation, corporate espionage, smear campaigns, defamation, etc. Whatever they can get away with. ... Even though they are pushing an aging and ill suited CPU, through shear muscle (overt Mafia reference) they just might succeed.
Everyone always seems to forget that, at the same time Intel was rolling out the 80486, it also rolled out its next-generation RISC-based i860. Fast as hell (for the time). There was a huge push by Microsoft, which at the time was trying to be platform-agnostic (this was circa 1989; Windows NT was being developed on the i860, and NT 3.51 (1995) and NT 4.0 (1996) were released for the x86, MIPS, Alpha, and PowerPC architectures).
Even with the two market 'monopolists' (not entirely accurate; IBM OS/2 (althoug
Re:x86? (Score:5, Funny)
All six in order of appearance; Mainframes, OS, Databases, Routers, Fanboys, RAM.
Re: (Score:2)
Because with Intel's record, we can expect massive improvements in power in the coming years, and because having more than one available architecture is a good thing for many reasons.
Re: (Score:2)
The API is a cruft ridden, legacy interface to a very modern up to date set of chips that are held back by having to support this API
If they could bin the x86 API then the chips would be able to show their true capabilities...they have been many Chips that various x86 based chips could not hope to compete with, but since they were not x86 they could not run Windows and standard Windows apps and so were instantly dead in the water ...
Go to a field where a GP CPU is needed and Windows compatibility is not an
Re: (Score:2)
ARM's one insurmountable advantage over x86 in the embedded realm is deterministic execution. x86 is now optimized for out-of-order and speculative execution, which makes multitasking applications "just work" better, at the cost of more complex silicon logic. The problem is, if you're doing something realtime ("realtime" != "responsive" or "fast" or "multitasking; it has a very specific meaning in embedded development) where you literally have to have an ironclad guarantee that a given block of code will ex
Re: (Score:2)
It all depends on how you measure. If you measure raw CPU power, then x86 is quite good. If you measure CPU power per Watt then ARM blows your mind compared to x86. (And the MPC860 even more, but that's a whole different puppy) It all depends on what you need. And I don't need a power hungry CPU in my phone.
Re: (Score:2)
WTF? ARM is the best architecture for smartphones (Score:2)
Re: (Score:2)
x86 legacy means large amounts of existing software that can now be easily ported to the phone. It's an advantage.
The only advantage for ARM is the lower power requirement, so if Intel can make their chips less power hungry, they can take over some of the market.
Re: (Score:3)
What phones need is more software designed for the mouse and keyboard.
Re: (Score:2)
Of course not, but there is plenty of software that doesn't deal directly with the user.
Re: (Score:2)
I'm not sure much of that software could be used as a selling point for a phone.
Re: (Score:2)
Operating systems, optimized multimedia libraries, codecs, encryption/decryption, device drivers for all the hardware, file systems, network stack. There's plenty of stuff that doesn't deal directly with the user interface, but you'd still find in a phone.
Re: (Score:2)
An OS which is not designed for a phone would be a very poor choice for use on a phone, why would you want to run such an OS when multiple systems specifically designed for phones already exist?
Optimized multimedia libraries would become somewhat less optimal if you ran binaries designed for a full power x86 chip on a stripped down low power variant, libraries optimised specifically for the low power variant would perform considerably better and if your reoptimising anyway, why not do it for arm.
Codecs.. we
Re: (Score:2)
Of course, if you're unlucky to have some optimized ARM code that you're porting to Cortex, you'll basically have to rewrite the whole thing again.
My point was that the word "legacy" was used by GP as a disadvantage. I'm saying that it's actually an advantage. Of course, you may argue exactly how big the advantage is, but it's certainly positive.
The only problem is the power consumption, and if Intel can solve that, they may end up with a superior platform.
Re: (Score:2)
Intel cannot "solve" it, due to the shear complexity and legacy cruft of the x86 architecture...
They can try to mask it by moving to ever smaller fabbing processes, but then they will still be beaten by an ARM chip fabbed on the same process (a while ago intel were talking about trying to stay one step ahead on the fabbing front in order to retain parity with arm - thus effectively wasting their technological advances by holding them back on x86)... That's like building a more fuel efficient car, and then a
Re: (Score:2)
ARM is working very hard to add shear complexity to their devices. In order to get high performance, they'll be forced to. Deep pipelines, speculative branching, complex instruction decoding, re-ordering, parallelizing, register renaming. It's all stuff that wasn't present in early ARM chips we all know and love for their simplicity.
The performance requirements on phones only go up, and as ARM will have to make their cores more complex, the disadvantage of a little bit of x86-specific cruft will be minor. T
Re: (Score:2)
I'm sorry, this is simply not true.
Both ARM and Intel are hostages to their history.
If ARM is to produce a chip that is competitive with Intel in desktop applications, then it will need to (a) improve its performance at native multi-tasking, (b) improve its FPU, (c) develope hyperthreading, out-of-order execution, speculative branchong, (d) add support for things such as virtualisation extensions.
Can it do these things? Yes, of course it can. Can it do these things without adding complexity and transistors?
Re: (Score:2)
So, you'd be happy with a phone running unoptimised desktop software, in other words? Do you enjoy carrying bags of batteries with you?
Re: (Score:2)
An Android phone is already running a lot of "unoptimized" desktop software, such as the Linux kernel and all related libraries. Of course, I wouldn't call that unoptimized either.
You seem to be missing the point that Intel is planning to make a lower power version, so you can run all your desktop software without draining the battery, just like you can do now with an ARM core.
Re: (Score:2)
My point is that there's more to creating a power-efficient mobile platform than picking a power-sipping CPU and running the same old crap on it. Even in its battery-huzzling adolescence, Android's Linux component was heavily rewritten to be suitable for mobile use.
Re: (Score:2)
Most of Android Linux is also the same old crap. Google only rewrote a small portion of it, and that already runs on x86 anyway.
Once Intel succeeds in creating a low power x86, it will take very little effort to turn it into a mobile platform, but with all the advantages of a standard and well-supported architecture.
For instance, having a x86 on your phone means that it's a lot easier to distribute native code apps in a single binary format. One of the problems with ARM is that there are so many incompatibl
Re: (Score:2)
While I don't contest that it's an issue, I don't think that going to x86 is a good solution. I think you'll lose too much in inefficiencies of the architecture to make it worthwhile. If Intel can fix that, then more power to them, but I'm not sure how they can without completely overhaulting x86.
Re: (Score:2)
The question isn't when will Intel create a power efficient CPU (as you could argue that they have - such as the Atom Z series) but what will it take them to match ARM's performance per watt. In other words once we have a 1W Atom - which is probably pretty close to the consumption of the A8. What did Intel give up to close that gap? Die shrink? Die size? (aka
Re: (Score:2)
Of course, programs such as mplayer have plenty of hand optimized assembly code. The point is that if you take a random program like that, it will likely have a good optimized x86 port already, and a lesser optimized ARM version.
And that doesn't just apply to the application itself, but also any of the libraries that it uses.
Re: (Score:2)
Name 1 useful, headless, x86, binary-only linux application, that does not have a viable alternative that can be easily ported to ARM...
You say 'plenty of software' and 'large amounts of software that can now be easily ported', but I'm genuinely hard-pressed for even a single example that proves you right.
Re: (Score:2)
Why does it need to be an application ? How about an optimized codec written in x86 assembly ?
Re: (Score:2)
If your porting software and have the source code then underlying architecture makes little difference...
If you don't have the source, then chances are the binaries require windows or dos, and probably have interfaces that would be utterly unsuitable for use on a phone...
In a phone, lower power is more important than being able to run desktop binaries, and arm will always be lower power than x86 due to carrying around a lot less legacy cruft (although it does have some...)
Re: (Score:2)
For instance, a x86 JIT compiler doesn't require windows, dos, or a user interface, but is still tied very much to the target platform. Good compilers for the x86 already exist, and keep getting improved for the desktop platform.
The legacy cruft in a x86 that is actually not useful is very small, while other legacy cruft is actually working very well.
Actually, one of the disadvantages of ARM is that there's not enough legacy cruft. There are a bunch of different, incompatible architectures (I think they're
Re: (Score:2)
ARM architectures are generally backwards compatible, as are the instruction sets which makes the situation not too dissimilar to x86, where you also have multiple revisions and multiple instruction set addons...
A JIT compiler is probably one of the few pieces of code that could be useful, only you would still need to modify it in order to produce efficient code for a low power x86 variant, for instance a JIT engine targeting a core2 doesn't run as well on an Atom...
Also there are a whole different set of o
Re: (Score:2)
Why should I throw out my existing smartphone software created for ARM to get "legacy" software for x86?
Even if they can catch up with ARM on power usage (which is far from certain, and probably at least a couple years off) Intel will have a really difficult time convincing smart phone makers to abandon all their old ARM software.
Intel should focus on making smart phones better for smart phone buyers rather than making smart phones better for Intel.
Re: (Score:2)
Excuse me... Large amounts of existing software would be easily ported over to the phone with or without X86. Code that couldn't be just simply recompiled is probably NOT something you want roaming loose on an embedded platform.
Re: (Score:2)
> If it can play HD video (and it already can) then what else do I want performance for?
Play HD video on the screen while capturing and encoding realtime 720p60 from the camera, streaming it in realtime through a software firewall and VPN while using BGP to negotiate a multilink connection via EVDO/UMTS, LTE/Wimax, and/or Wi-Fi (depending on which one(s) are the best-available network link at that instant in time), and juggling your antivirus suite, anti-rootkit scanner, checking your IMAP mail server fo
Re: (Score:2)
It's called two-way HD video chat with realtime collaborative desktop sharing. Incoming video from the other guy? Check. Video-capture and encoding to send him? Check. RDP, VNC, or some comparable protocol? Check. Gimp? Check.
It's kind of an extreme example by current phone standards, but not much beyond what you could do today with a fairly high-end laptop from Dell (or a fairly run-of-the-mill one, if you have dedicated hardware to handle the h.264 realtime capture and encoding, and a video chipset with h
Re: (Score:2)
In fairness, he did warn you that he was trolling...
Re: (Score:2)
> It's proven, it's developing and has no legacy dragging it back.
Yes. Until you try and turn it into a multi-core architecture with parallel branches, speculative & out-of-order execution, and all the other things x86 does in its sleep that are virgin territory with ARM. At that point, it's no longer proven and mature -- it's Internet Explorer 6 with lots of band-aids and a few upgrades pigtailed on & held in place with lots of duct tape.
If you're making the 2.0 version of "John's Phone" (a devi
Re: (Score:2)
Might be new territory for ARM, but it seems like that they're managing it pretty well within the context of their IA- A9's do
Re: (Score:2)
Re: (Score:2)
What we really need is a new architecture specifically designed for low power... Both ARM and x86 have legacy cruft holding them back, although x86 has considerably more...
linke M$ running after OSS and OSX ideas (Score:2)
And why is this on slashdot? (Score:3)
No shit? Intel is going to work with OS vendor to make OS run better on their chips ...
Are we going to have headlines that read 'Intel does research into making microprocessors!' next?
This is not news, this is SOP at any business like this.
Another nail in Meegos coffin? (Score:2)
yeah because x86 is _so_ much better (Score:2)
x86 and uses less power, has more efficient floating point operation and CPU instructions 0_o
No way would I want an x86 chip on my mobile device. The power consumption alone is going to require a ton more battery. Beside, Intel already has a near monopoly on the windows desktop why give them another arena.
Re: (Score:2)
Optimising an x86 chip?
Re: (Score:2)
Intel should just throw an arm core in there with the x86 core.
Re: (Score:2)
And add a Space Core for good measure.
Re: (Score:2)
Better yet, a marine core, which supports everything from C to EEE. And it has built-in water cooling.
Found every everywhere: from the halls of Montezuma to the shores of Tripoli.
Re: (Score:2)
Intel should just throw an arm core in there with the x86 core.
Sure, and then a leg core. But that would make the cost prohibitive.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Marvell is the only ARM manufacturer who is still under the impression that a chip with no FPU is competitive. Deluded people keep buying computers with their chips and wondering why they're so slow...
How much cheaper are they?
I was looking yesterday to see whether my Nook Color (A8-based, IIRC) has a SIMD unit (supposedly called NEON according to the scarce docs I found online) and I was pleased to find that it probably does. The OMAP part is available without the SIMD unit, but it looks like B&N was
Re: (Score:2)
Re: (Score:2)
HA - Windows support is not enough for this ancient architecture?
Well Windows is branching out to supporting ARM in the mainstream with the new version so it makes sense for Intel to get serious about other operating systems too.
Re: (Score:2)
Re: (Score:2)
Are the Tegras really all that fast? I keep seeing complaints from people using the dual core 1 GHz plus versions that they can't decode 1080p h.264 video unless it's of some specific format that hardly anyone uses. I think AMD's Brazos platform can do that.
Re: (Score:2)
For power reasons, of course, the Tegra GPU is still a pretty wimpy Nvidia
Re: (Score:2)
No, Tegras are pretty slow on the CPU side. As the other poster said, they're basically stock Cortex A9 parts without the vector unit. Tegras speed comes entirely from the GPU, so if you have something that's compute-bound and doesn't run on the GPU then they'll be slow.
As to overall performance, my Cortex A8 machine compiles code about as fast per clock as my Core 2 Duo machine. That's a very unscientific benchmark, since they run different operating systems, but it's a rough ballpark. The A9 is sup
Re: (Score:2)
You are deluded if you think an ARM processor is going to come remotely close to touching a Core i7 in performance.
Does it have to? How many applications actually need top of the line Core i7 performance? The majority of applications will be able to get by with significantly less. However, I agree that the GP is deluded to think that Apple will replace the Intel processors in the product line up with ARM chips any time soon.
Re: (Score:2)
You are also deluded if you think mobile intel processors will be as powerful as a Core i7. Intel won't magically develop a new tech that will be orders of magnitude more efficient than what ARM has been doing for years. They also won't be able to magically solder an i7 to a SoC and expect it to have decent consumption levels.
Point is, if ARM can't do something that is remotely close to an i7, then intel can't for the very same reason.
Your comparison is simply out of proportion.
Re: (Score:2)
Of course, intel engineers have a lot more experience in high performance design. It's probably easier to take existing high performance circuits, and make them run at lower power, than it is to design high-performance/low power circuits from scratch.
Re: (Score:2)
People following computer architecture classes have produced mostly stuff that didn't work very well in the real world. Alpha, MIPS, HPPA, Itanium... nice on paper, but x86 beat them all.
Even ARM is now moving away from the nice clean architecture they had. Have you looked at Cortex ? It's a mess. But that mess is exactly what allows it to perform well.
Re: (Score:2)
Since they are comparatively small, comparatively cheap, and comparatively low power; but persistently weak compared to x86s, it would likely be easier to bodge one on to an x86 motherboard(with mechanisms for it to steal an adjustable amount of system RAM, if activated, embedded GPU
Re: (Score:2)
The summary is talking about optimization for "smartphones and other mobile devices using Intel chips". Totally not what you read into it.
Re: (Score:2)
In a strange reversion of normal slashdot operating procedure, I read the summary, but not the title.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
None. It's a parallel evolutionary track. Start with Linus' kernel, throw out 99% of everything else that ends up in a modern Linux distro, then write your own windowing system that does the same job as x11, but does it in a way that's completely different and is mostly inseparable from the Java-like abstraction layer sitting between the kernel and userspace applications.
I'm struggling here to think of an Animal analogy,but I know there are at least a few cases where you have two species that superficially
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I can't wait for the fans in my phone to start howling.
Beats the fanboys howling.
Re: (Score:2)
I, for one have had an intel x86 in my pocket for well over a decade.
Garmin GPS-12, based on the intel 386ex.
Lasts for 12h on 4AA batteries.
I forget the exact date this came out - 96?
Re: (Score:2)
HIGH FIVE!
I still have a working GPS 12 in my box of goodies too. They did switch to ARM though...
Re: (Score:2)
I don't have those problems, could it be that you may be the reason that your phone is doing all that?
Re: (Score:2)
We can't get through an entire day on a single battery because every manufacturer feels compelled to make its new phone thinner than last year's iPhone. If companies like HTC/Samsung/Motorola would just bite the bullet and add a millimeter of extra thickness, we could have 4000mAH batteries that could make it through a day of active use & still be alive the next morning when somebody calls to wake you up.
~6 years ago, Samsung felt compelled to give every SPH-i500 owner two free batteries (one extended-l
Re: (Score:2)
Mmmmm. Copypasta astroturf. Yum.