Slashdot Mirror
Intel, Google Team To Optimize Android For Smartphones
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."
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)
Shouldn't they be optimising the chips to run Android, instead of the other way around?
Dropbox drops it like it's hot.
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.
Learning HOW to think is more important than learning WHAT to think.
There are some really fast ARM based CPUs, like nVidia's Tegras, out there, as well as some ARMs that are fast enough to be used as GPUs. Also, does Corei7 give the power savings that are needed? Because now, both performance and power consumption are important, and ARM has always trumped x86 in power consumption. Heck, even the new MIPS platform is competitive w/ ARM on power consumption, and competitive w/ x64 on performance. I don't see what this deal would have for Android.
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.
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.
Yes. Because linux loves us, every one.
The summary is talking about optimization for "smartphones and other mobile devices using Intel chips". Totally not what you read into it.
It's proven, it's developing and has no legacy dragging it back.
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.
so Intel is also in the posse chasing the cutting edge ;-/
I guess in a very loose way it's kind of based on Gentoo (using ebuilds), but it's more of a from-scratch kind of thing.
With an x86 port of Android, it won't need to be emulated on x86 platforms - it could just run it in a sandbox.
Desktops against Smartphones. It's like your comparing Apples and Oranges.
LFS.
Isn't that a Java app?
It was supposed to be su; ls; kill, but there was a typo.
Do you even lift?
These aren't the 'roids you're looking for.
You are deluded if you think a Core i7 is going to come remotely close to touching an ARM in low power usage.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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.
No kidding!!! What do you say at this point?
Of course not, but there is plenty of software that doesn't deal directly with the user.
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.
That would be 'ARM Mac' retard - one who'd make iOS applications available on Macs by basing it on the same CPU
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.
Thankyou for finally speaking the truth. I recognize that ARM is good for mobile phones because of it's cycles/watts, but either I am seriously missing something or people are nutters for not thinking that a modern chip architected to run something as bulky as windows and it's countless applications of bloat will easily smear ARMs face in the mud when it comes to performance.
The only real question now is, does intel stand a bloody chance at lowering the power cost of their architecture? If they can do it, I am on board immediately. I do realize they and AMD have both failed to show any ability to get down to the power efficiency of ARM in the past, I'm still rooting for the chip powering my HTPC to run at a power efficiency to run my phone.
I'm not sure much of that software could be used as a selling point for a phone.
No kidding!!! What do you say at this point?
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.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
Why does it need to be an application ? How about an optimized codec written in x86 assembly ?
Applications are mostly Java, so that shouldn't be a problem either.
The Native code library (NaCl) will be unportable currently. However, they plan to base the next version on LLVM making that too platform independent.
In a strange reversion of normal slashdot operating procedure, I read the summary, but not the title.
http://www.android-x86.org/
Ironically, ARM's strengths may actually reduce the chance of the "ARM PC" ever showing up(in any quantity: various ODMs have slapped smartphones into netbook chassis and then failed to ever do anything with them already...).
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 style, and paint to some or all of the graphics output of the device. It wouldn't be totally trivial; but you could get a full x86 laptop that can also run an embedded ARM simultaneously or by itself in some sort of low-power mode for not a huge cost and board-space premium over a conventional unit. That strikes me as much less of an uphill battle than trying to adjust customer expectations for something that looks like a laptop but acts sort of like a tablet...
Or?
-- Linux user #369862
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...)
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
either I am seriously missing something or people are nutters for not thinking that a modern chip architected to run something as bulky as windows and it's countless applications of bloat will easily smear ARMs face in the mud when it comes to performance.
Performance as in bigger numbers on the box? Sure, x86 is always going to win that. But what can I actually do with an x86 that I can't do with my tegra 2? If it can play HD video (and it already can) then what else do I want performance for?
I am trolling
They sold most of that to Marvell. They retained a few bits, some hardware RAID chips and maybe NIC TCP offload; but all the general-purpose PXA* stuff is no more. I haven't kept up with Marvell's use of what they bought, so I don't know if they just changed the model numbers and kept on shipping, or whether all the old lines are dead and the just bought it for some design features/IP for their future cores...
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.. well what codecs do you really need on a phone? h.264, webm, divx, xvid, mpeg for video? mp3, ogg, gsm, aac for audio? those already exist for ARM, and in source code form so they can easily be ported to other architectures. Anything else would be very niche, and probably still exist in source code form anyway... Worst case for anything else you could transcode.
Encryption/decryption - multiple encryption libraries exist in source code form, e.g. OpenSSL... Any sensible algorithm you would care to use is already available for ARM, and in source code form for easy porting to any other architecture.
Device drivers - phones already have device drivers available, they generally have custom hardware in them which require specific drivers anyway, so existing drivers would be of little or no use, especially without source code.
File systems - linux already has drivers available for virtually any filesystem you're likely to encounter, and in source code form which already compile for ARM...
Network stack - a number of network stacks already exist in ARM platforms, and most come with source code so could be easily ported.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
In addition to the relatively low cost of supporting Android on x86(it already works, albeit not necessarily 100% optimally or with the mothership's blessing outside of Google TVs), and hedging their bets as to whether Intel ever gets it right on truly "mobile" stuff, it could also be that Google is happy enough to go along with Intel's aspirational blather about finally getting into products without fans; but figures that whether or not they manage that, there is still a lot of "embedded" territory to cover.
The world is absolutely infested with "embedded" systems that are x86 based and more or less massively overpowered; but either need to support some legacy application, or are fairly low volume and time-to-market sensitive, so it makes more sense to just buy an industrial-rated single board PC, with a normal BIOS, and just dump WinCE, WinXP embedded, or Linux on there and let your coders get to slapping together the application-specific interface, rather than spend time fucking around with whatever weirdo boot setup and peripheral layout the ARM SoC of the day is pushing in order to save a few bucks or a few watts per unit. Most of these systems are deeply unsexy, and not really offered in the consumer channel; but there are a lot of them. It certainly wouldn't hurt Team Google if, for a minimal investment on the off chance that Intel finally manages to ship tablet/phone silicon, they also get to make inroads into the higher power embedded markets.
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 up to v7 now). Big/little endian variations, and there's the ARM/Thumb/Thumb-2 and Jazelle instruction sets. This doesn't make it a very pleasant target, since you have to maintain several different versions of all your libraries. It especially sucks for optimized assembly code.
Whether ARM will always be lower power depends. ARM is getting to the point where they have to move into higher-performance arena, and they'll run into problems that Intel has already solved.
I can't wait for the fans in my phone to start howling.
Beats the fanboys howling.
Fandroids hate facts.
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.
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...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
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?
So, you'd be happy with a phone running unoptimised desktop software, in other words? Do you enjoy carrying bags of batteries with you?
No kidding!!! What do you say at this point?
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 adding lead weights to it in order to reduce its overall efficiency to that of a normal car. If Intel were to keep one step ahead on fab process and then produce ARM, or even a new architecture specifically designed for low power use, they would have a huge advantage over the competition.
They can also try to reduce power consumption by sacrificing performance (e.g. atom removed the out of order execution capability, which both reduced performance and requires existing code to be reoptimized for the new processor), but then they lose the performance lead over ARM.
"legacy" has both negative and positive connotations, negative being the power consumption as a result of complexity, and positive being the ability to run existing code...
However the fact that a lot of that existing code is also available with source code and can thus be recompiled for another architecture...
And the fact that a lot of the existing code is simply not relevant in the context of a mobile phone...
Means that the negative connotations of "legacy" massively outweigh any positive ones, leading to a net negative overall.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If it can play HD video (and it already can) then what else do I want performance for?
By the same logic 40 years ago people could have been told about the internet and said what do they want that for? They already had all they needed.
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.
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 optimisation criteria in a desktop, power consumption is of minimal importance, there is usually plenty of memory available etc... On a mobile platform, you will have less memory, less backing storage, possibly slower memory etc, all of these things seriously affect compiler design.
Aside from ARM, it's also worth considering MIPS... There are plenty of low power MIPS designs which are capable of competing with ARM, but MIPS is already available in a 64bit variant and was previously available in high performance variants (in the 90s, MIPS was massively ahead of x86 for performance).
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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. The x86 instruction decoding is a solved problem, and it's not significantly harder than Cortex decoding taking into account the overall complexity of the whole chip. Beyond the x86 decoding, there's not much in the Intel core that needs to be kept as legacy. Everything else can be redesigned for lower power, and it's the same stuff that ARM is going to have to add to their new designs.
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.
Now it's the time of Medfield, and while I haven't spotted any smartphone running on it yet, I already hear Intel talking about its successor.
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.
Join the Slashcott! Feb 10 thru Feb 17!
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.
No kidding!!! What do you say at this point?
I don't have those problems, could it be that you may be the reason that your phone is doing all that?
Don't know something? Look it up. Still don't know? Then ask.
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 incompatible versions in both core and SoC design, which would require the distributor to recompile for a bunch of targets, and running them all through QA.
It has already been written in a portable manner, it's Linux FFS!
Linux uses exactly the same file system drivers when it's running on s390, x86 and ARM.
Mplayer and ffdshow can be compiled on about 24 different architectures!
I'd suggest lowering the intake of Microsoft marketing department sewage and their idea of "portability".
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.
No kidding!!! What do you say at this point?
I'm sure OP is devastated by the loss of your respect...
Probably.
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.
The Tegra parts are pretty much stock ARM Cortex A9 cores, minus NEON, pretty much exactly the same CPU power as any other Cortex A9 part. The only real difference is that they have an integrated GPU derived from Nvidia's full fledged laptop and desktop design history, rather than one of the (historically pretty dire, probably improving quickly now that demand for 3D punch in ARM SoCs is abundantly obvious) embedded graphics cores.
For power reasons, of course, the Tegra GPU is still a pretty wimpy Nvidia GPU(I don't know exactly which desktop/laptop GeForce it can be most closely compared to; but the high end "Tegra 2" has 4 pixel and 4 vertex shaders at 400MHz, claiming 6.4GFLOPs. The nastiest Geforce 200m chip available has 16 shaders at 1.6GHz, claiming 72GFLOPs. Of course, the latter also consumes 14 watts all by itself, so it isn't exactly going to make it into your phone in the near future.)
Given that many GPU tasks parallelize pretty nicely, and Nvidia doesn't exactly have super secret mobile sauce that they wouldn't also use to boost performance and reduce draw on high end parts, the Tegra can't help but be pretty anemic against even the integrated GPUs of today(though the Intel Xtremes of yesteryear are definitely targets...). You just can't avoid the fact that a chip with the die and power budget to run far more compute units, at a much higher clock rate, with a wider bus to faster RAM, are going to stomp on some teeny little sliver of silicon talking to LVDDR over some parsimonious little mobile bus.
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 supposed to be a bit faster per clock, so it's probably close, although still a lot worse for things that are floating point intensive. The fastest multicore Tegras are probably just about competitive with the slowest i3 in terms of performance. They won't come close to touching an i7.
For smartphones, that's not an issue, but it will be a little while before Apple will be able to seriously consider replacing Intel with ARM in the MacBook Pro, for example.
I am TheRaven on Soylent News
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...
I am TheRaven on Soylent News
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 resemble one another, but actually got there by completely separate evolutionary tracks (possibly, after diverging from some common ancestor millions of years earlier). Zebras-vs-Horses, maybe? Eels vs water snakes?
> 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 device intended to do absolutely nothing besides make phone calls as simply as possible, with long battery life and minimal scope creep), ARM is absolutely the best architecture to use for the job. On the other hand, if your phone has mutated into a de-facto pocket laptop driving an external display via wireless HDMI and running browser-based Flash applications, some future Franken-ARM architecture isn't necessarily the best choice.
> 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 for updates every 3 seconds, keeping your Twitter timeline up to the second, and editing 3 ~4000x3000 HDR pics you took with the camera in its highest-resolution mode in Gimp. And somehow, manage to not crash or choke when somebody calls you, and it has to gracefully notify you about the incoming voice call and somehow allow you to answer it without seriously interrupting everything else you're trying to do with your phone at that moment.
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-life) because of its *scandalously poor* battery life -- fully-charged, it could barely make it through eighteen hours with the non-extended battery. Today's iPhone and Android owners would *kill* for that kind of battery life, but the fashionistas who dream of credit-card thickness phones won't let us have it.
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 forward-looking or the cost difference wasn't significant. I want to use it for AES crunching for encrypted storage, but it looks like that's still an available project.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
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? No, it cannot. ARM can become compeititive with Intel in desktop, but only by becoming more like Intel. Those extra transistors? They add die size (i.e. cost), and they add drain (i.e., reduce battery life).
Now Intel, can it produce a super low power chip, running the x86 instruction set, that is usable in smartphones, etc? Yes, but if it wants to do this, it will have to shred transistors, and shredding transistors means shedding performance and features. In other words, it will no longer offer any specific performance advantages.
It is *possible* that Intel's process technology lead means that it can produce a competitve mobile chip before ARM produces a competitive laptop/desktop chip. But it's also largely a moot point. Unless there is a compelling reason for handset manufacturers to choose Intel, then it will be an irrelevent share of the market.
The same is true for Windows 8 on ARM. No legacy software support, and no meaningful cost advantage (Intel Atoms start at $20/chip, about the same as a Tegra 2.) Plus, of course, the architecture of the box around ARM (on the PC side) is not set in place yet.
Unless something very surprising happens, we will see ARM taking overall share, because smartphones and tablets are growing as a percentage of the computing market, at the expense of desktops and laptops. But it is unlikely that ARM will take a meaningful share of the PC market or Intel of the smartphone one.
--- My dad's political betting
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.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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 drop functionality) Or will some other factor make it all moot? (battery tech, market change)
So far you haven't made much of an argument for ARM being more incompatible than various versions of x86. - ie. I can't run AES instructions on anything but the 2nd Gen Nehelem. Not only that (and this may be true for ARM but I don't code in that much) but there are lots of contradictory optimizations in x86. For example just taking block moves what is optimal for 286 (Unrolled loop if move can fit in cache or REP MOV), is suboptimal for 386-486 (unrolled loop for in cache move otherwise REP MOVS - for blocks aligned on word or double word boundaries) which is suboptimal for Pentium (MMX), etc.. this isn't even counting dealing with the wide variety of cache sizes.
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 REALLY well at it (so much so, that it's able to do 1.5x performance over the Atom at clock-for-clock and consume the same power profile as the earlier devices while doing it. X86's the minefield with all the old legacy calls, screwy memory access methods (unaligned reads/writes allowed, for example...) and the like. It's as much all the old stuff from X86 as what you mention (both combined, really) that makes an X86 a complex processor.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
You watch videos while taking other videos and editing 3 photos at the same time? Often enough that you'd pay more for a processor that lets you do that?
I am trolling
Nonsense, you could immediately tell them useful things they could do with it - send letters to friends across the ocean that arrive instantly (or indeed videochat with them), have a map that would speak and guide them around a strange town, have an encyclopedia in their pocket, order any piece of shopping without having to leave their home or office, ask for music or books or videos and retrieve them instantly. Things like social networks might take a little more effort to explain, but fundamentally they improve your life in ways that you could explain to anyone. What I'm saying is not that life is perfect right now, but that I don't see how a faster processor is going to make it any better - what can I do with a faster processor?
I am trolling
HIGH FIVE!
I still have a working GPS 12 in my box of goodies too. They did switch to ARM though...
Mmmmm. Copypasta astroturf. Yum.
...the future crusty old bastards are already drinking the Kool-Aid.
In fairness, he did warn you that he was trolling...
...the future crusty old bastards are already drinking the Kool-Aid.
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 hardware-assisted decoding).
The problem with predictions that future computers will be more power-efficient is the reality that users and programmers inevitably find creative ways to soak up 150% of any improvement to processor speed. On one hand, we all bitch about 3GHz quadcore PCs that feel slower than a 400 MHz Pentium 3 did running Windows 98... but none of us could stand using Windows 98 anymore, because it would feel almost like a toy compared to anything modern. And before anyone brings it up, fully tricked-out Linux is every bit as bad as Windows -- maybe even a little worse. Hell, look how long 1.6GHz Atom chips lasted before Intel had to boost the cores, clock speed, and cache enough to run Vista acceptably fast. Any long-term strategy that depends upon reducing speed for the sake of power savings is doomed, because mainstream software and consumer expectations will outstrip it and render it obsolete long before it hits the store shelves.
Perfect example: Pentile RGBW. On paper, it's awesome... good black & white text, great battery life. Put any Pentile RGBW display next to Super AmoLED+, and it's going to look like total crap and leave its owner feeling shortchanged because it just doesn't have the searing "snap" and saturation. It might not look as good for black & white text, and might not last as long battery-wise, but it's like the "Pepsi Challenge" from the 70s and 80s -- put the two side by side, and people will always make the impulse decision to grab the pretty one, regardless of intellectual arguments and pragmatism.
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.
Hmm. Point, I guess, I've just never seen it used that way - even on beefy office desktops people tend to go to full screen desktop when sharing it rather than keep the video chat running at the same time. I really think we have hit a plateau in performance requirements - video rendering has traditionally been the biggest user of increasing CPU power, but nowadays it's at or nearly at the point where the detail on the artist's models is far more of a limiting factor than the software side. I'm sure we'll keep getting more and more efficient video codecs, but as bandwidth increases they become less relevant (I don't even bother encoding my audio any more, the space it takes up is so minimal)
Any long-term strategy that depends upon reducing speed for the sake of power savings is doomed, because mainstream software and consumer expectations will outstrip it and render it obsolete long before it hits the store shelves.
Yes and no; the low-power machines being made today are selling well enough. Five years ago I wouldn't have considered buying anything less than the fastest x86 on the market. But a few weeks ago I bought the aforementioned tegra 2 device (an eee transformer) because 16 hours of battery life is more valuable to me than the few things an x86 could do that it can't. At some point processing power becomes good enough, because there's really only so much you want to do with it.
I am trolling
so far Intel has managed to cut the power usage in half from less optimized x86 Android! now you get a full 10 minutes!
Anons need not reply. Questions end with a question mark.
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.
I'm a little skeptical of the "1.5x performance over the Atom clock-for-clock" claim. The Atom has a much broader vector instruction set, and ARM FPU's aren't exactly known for their record-setting performance. Take this with a grain of salt, but Intel claims some fairly impressive spec_cpu2000 performance numbers:
http://top500.org/files/Moorestown-Performance.PNG
whales vs fishes?
You probably don't want to do AES on NEON if you've got an OMAP. The C64x DSP that most OMAP chips include will be much faster. The problem with the Marvell chips is that they don't include a DSP or an FPU. Oh, I think the OMAP also includes vFP, which is largely going away but still has a couple of advantages over NEON in some situations.
I am TheRaven on Soylent News
Those are merely a subclass of the ARM PC retards. They're in the Linux community, too. Had one recently griping that the Straberry Pi didn't have a PCI Express slot. While I think it would be cool to have an ARM CPU with a PC I/O system, most ARM are SoC and even when they have external Flash and SDRAM interfaces, they still don't have a general FSB. When they do have a PCI interface, the general intent is for them to be on a daughtercard.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
it would likely be easier to bodge one on to an x86 motherboard
Sure, if you could find one with a proper FSB to interface with the bridge chips, instead of the vendor-specific SoC garbage you usually get. Your I/O bandwidth wouldn't be great (like Apple in the G3/G4 era when Motorola/Freescale couldn't do better than 133-166MHz FSB), but performance wouldn't really be a goal.
a full x86 laptop that can also run an embedded ARM simultaneously
Now there's a losing bet. Never in the history of personal computing has a hybrid-processor system had any long-term success*, only in video game consoles where the manufacturer forced it on developers (with the promise of manufacturing that identical system for multiple years).
However, I will admit that there has been some minor success with a hybrid GPU system. A friend of mine has a Dell laptop that can automatically switch between on-board Intel graphics and a proper GPU. But GPU stuff goes through enough abstraction layers that it basically doesn't matter what GPU you use.
*FWIW, I once worked with an Ohio Scientific C3P that was only used to run 6502 BASIC for two users.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
It's not much problem to get any reasonably decent source to just work on ARM with a recompile. ARM provides a decently powerful CPU that has low power consumption (and the low heat to go with it) at a good price.
It also has a proven track record in the smartphone.
The upcoming Atoms might be in the running, but we'll have to wait till 2013 to find out.
Isn't that the point?
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe