Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Android Cellphones Google Intel

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."
This discussion has been archived. No new comments can be posted.

Intel, Google Team To Optimize Android For Smartphones

Comments Filter:
  • by walshy007 ( 906710 ) on Wednesday September 14, 2011 @05:18AM (#37396324)
    Linux already runs on x86, and if google played their cards right code quality wise (bit endianness etc) It should all be just a recompile away more or less. (with new peripheral drivers of course... as with any new peripherals on a new device)
    • Of course application developers will also need to compile any native code they have.
    • I am not Android developer, but they probably have, as a part of Android platform, code-generating libraries, like Sun Java Hotspot except that it comes from Google. Porting these to different CPU is obviously very complicated if result suppose to provide good performance. Other x86 code generators like gcc, icc, msvc, JVM, .NET or PathScale had many years to fine-tune their programs. Google must have competitive solution in no time.
    • by Funk_dat69 ( 215898 ) on Wednesday September 14, 2011 @10:03AM (#37398314)

      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.

    • by RoLi ( 141856 )

      "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

  • Bye, Bye Meego (Score:3, Insightful)

    by chill ( 34294 ) on Wednesday September 14, 2011 @05:38AM (#37396422) Journal

    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.

  • x86? (Score:5, Insightful)

    by zrbyte ( 1666979 ) on Wednesday September 14, 2011 @05:45AM (#37396460)
    Why would we want to stick to x86 in the smartphone, portable device world? x86 is an aging architecture, which still pulls back the PC market, granted with PCs we need backwards compatibility. But the smartphone market is new and thus able to adopt new architectures. And the world is seemingly moving in this direction. This is just some wrangling by Intel to try to push into the portable market.
    • 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.

      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

      • 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)

          by fuzzyfuzzyfungus ( 1223518 ) on Wednesday September 14, 2011 @07:16AM (#37396922) Journal
          Why would Google possibly object to Intel adding their pet OS to the list of operating systems that intel pushes along with their embedded CPUs?

          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.)
      • 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

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

  • It's proven, it's developing and has no legacy dragging it back.
    • by Arlet ( 29997 )

      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.

      • What phones need is more software designed for the mouse and keyboard.

        • by Arlet ( 29997 )

          Of course not, but there is plenty of software that doesn't deal directly with the user.

          • I'm not sure much of that software could be used as a selling point for a phone.

            • by Arlet ( 29997 )

              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.

              • by Bert64 ( 520050 )

                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

                • by Arlet ( 29997 )

                  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.

                  • by Bert64 ( 520050 )

                    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

                    • by Arlet ( 29997 )

                      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

                    • by rcs1000 ( 462363 )

                      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?

              • So, you'd be happy with a phone running unoptimised desktop software, in other words? Do you enjoy carrying bags of batteries with you?

                • by Arlet ( 29997 )

                  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.

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

                    • by Arlet ( 29997 )

                      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

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

                    • I don't really see that point of the implication that Android Linux isn't optimized everywhere. It isn't, nothing is, there's no point really.

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

            • by Arlet ( 29997 )

              Why does it need to be an application ? How about an optimized codec written in x86 assembly ?

      • by Bert64 ( 520050 )

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

        • by Arlet ( 29997 )

          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

          • by Bert64 ( 520050 )

            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

      • by Kohath ( 38547 )

        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.

      • by Svartalf ( 2997 )

        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.

    • > 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

      • by Svartalf ( 2997 )

        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.

        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

  • so Intel is also in the posse chasing the cutting edge ;-/
  • by BitZtream ( 692029 ) on Wednesday September 14, 2011 @07:36AM (#37397068)

    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.

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

Can anyone remember when the times were not hard, and money not scarce?