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)
HA - Windows support is not enough for this ancient architecture? Intel can't even keep alive Linux interest in Itanium, which if they created some low power options for it, they could do a better job than x86.
Apple would do well to replace them w/ A5/A6 CPUs. If memory or 64-bit OS is an issue, consider a 4 core CPU w/ each core having separate memory for each CPU - that would help them break the 4GB limit, albeit being capped @ 8GB. Or Apple could make A7 64-bit, if possible.
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.
I guess it depends on whether he comes across as more like the jazz trumpet sort of a guy, or the Quake deathmatch sort of a guy. I prefer the former.
No kidding!!! What do you say at this point?
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.
Can anyone tell which Linux distro is Android based on? Debian? Fedora? Gentoo? Which?
My android phone is going down the same road my last windows machine did. Constant reboots, apps stop syncing, no network access, dropped calls, freezing apps, inexplicable application behavior, etc... . Maybe someone ought to fix what is in the wild before it causes people to jump ship (iphone 5 anyone?)
The summary is talking about optimization for "smartphones and other mobile devices using Intel chips". Totally not what you read into it.
Please.
It's proven, it's developing and has no legacy dragging it back.
Fucktard. Go shoot yourself you illiterate nigger.
To be honest, I respect illiterate people much more than rude, arrogant and rasistic people.
so Intel is also in the posse chasing the cutting edge ;-/
Intel is therewith becoming the official US carmaker of the semiconductor business. Seriously, it's like putting a V8 into a Mini car.
It works on x86 already. You can download an ISO from http://www.android-x86.org/ already.
'nuf said.
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.
Either one beats "So, u `ls kill`?".
In general, it is safe and legal to kill your children. -- POSIX Programmer's Guide
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.
I also wondered about this. Seems that the race for the best portable chip is not yet over - ARM currently has lowest power consumption but Intel has the better performance.
Google is just making sure its gonna be okay whoever wins.
Great article here:
http://www.brightsideofnews.com/news/2011/5/19/the-coming-war-arm-versus-x86.aspx
Conclusion page here:
http://www.brightsideofnews.com/news/2011/5/19/the-coming-war-arm-versus-x86.aspx?pageid=7
Quote:
The ARM Cortex-A8 appears to use much less power than the Atom, while often delivering comparable integer performance. Nevertheless, the Atom is significantly faster overall when considering holistic system performance, but that performance will be accompanied with a battery life penalty and significantly more heat production
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?
Doesn't Intel still have XScale? What did I miss?
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
I can't wait for the fans in my phone to start howling.
Also, totally not what the story title says.
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/
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
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.
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!
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?
Says the illiterate person using the pseudonym "gaygirlie". I'm sure OP is devastated by the loss of your respect...
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!
This is probably more about Google TV and maybe a little bit about tablets than phones. The talk about smartphones is probably just CEOs trying to create buzz.
*x86 legacy means large amounts of existing software that can now be easily ported to the phone. It's an advantage.*
virtualbox? or otherwise you're just high.
intel wants on the mmooneyy. though, there's no reason why you wouldn't want dalvik on your x86 too.
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.
Title makes little sense as the first platform of Android was Smartphones.
should be "Optimize Android for Intel chips ... on smartphones"
Why does it need to be optimized? Is it not already the GREATEST OPERATING SYSTEM IN THE HISTORY OF EVER that runs flawlessly with no issues at all?
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!
What would be nice is if Google would optimize Android for the current hardware. I know, I know... crazy talk! It would be SO nice to get through an entire day on just one battery. I don't even mind charging it every night, as long as I can get about 20 hours out of a charge. Seriously... what makes Android suck batteries so much more than my wife's iPhone? Is it just that they have removable batteries, so they therefore must have smaller lifespans? Surely not. There has to be something they can do in the code to help make this thing faster and longer-lived. C'mon Google. You're off to a great start.
For the record, I've been with Android since the G1 and will stick with it until they stop development or make it unusable... that doesn't mean I think it's perfect, though.
Why go backwards to CISC when most cell phones are currently based on a RISC architecture. I thought that everyone wanted to get off x86, but now Intel is trying to push it onto a new platform.
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?
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.
Moblin was a desperate plot to get those (relatively) power-hungry Atom-chips some traction on the PDA market. Never got off the ground more than a few beta releases.
Meego was a desperate plot to entice the prospering Maemo environment, backed by Nokia. Crashed and burned after a few years, with both Nokia and Intel ditching the project.
So, I guess it's time for Intel to try Android..
If they follow the same track as before; demand arbitrary design changes that benefit your platform (=Atom) and hurt competitors (=ARM/VIA/AMD), push in your expertise trying to alienate older developers (pushing rpm onto dpkg-based maemo), rinse and repeat until competitors switch platform. After that point, you might as well drop the platform too. But who cares as long as you get huge margins on the CPU market!
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.
Intel is the most capable CPU vendor in the world. It owns the design. It owns the fab. The x86 ISA is the primary ISA for Linux. There's no legacy in a new platform. In terms of power efficiency, the ISA decode plays a smaller and smaller role in overall power efficiency and processor speed every year. They have a shipping 64-bit ISA, which will become important in the coming years when 32-bits stop being enough (don't be naive enough to think "nobody needs more than 32-bits on a smartphone").
If Intel apply themselves with force, they will own this. The only question is whether they actually want to go there, as they make pots of money on desktop and server CPUs.
In terms of 64-bit, the only other vendor with a proven 64-bit ISA is MIPS. They're barely in the game, which I think is a real shame.
ARM isn't going anywhere. It's a truly beautiful architecture, but competition is a good thing.
Android is CPU agnostic (although there is the NDK - but developers should provide bundles for all shipping CPUs IMO) and I think that's a strength rather than a weakness (iOS fans might say Android is sluggish due to its generally non-native applications. I see it... but time will fix that).
> 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.
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.
About a month ago, the HTC Sensation 4G smartphone got an Android 2.3.4 update. A new Sensation has now landed called the HTC Sensation XE. The Sensation XE has gone official and the smartphone packs in some cool features that the original Sensation didn’t offer. The new smartphone is the first to get the special audio tech from Beats Audio thanks to a new partnership. That custom audio processing hardware and software is also coupled with a nice set of earphones.Better audio isn’t all that is in store for the geeks that buy the new Sensation XE. The smartphone also has a faster processor with 1.5GHz clock speed. The smartphone also gets a new larger battery that should let you talk, play, and listen to music longer before the battery goes dead. I already mentioned those cool Beats earphones briefly.The smartphone will automatically switch to the Beats Audio hardware and software processing when the earphones are plugged in. The special earphones also have an inline remote that will let you control your music. A mic is also integrated for making and receiving phone calls Affiliate Programs Review. The Sensation XE is set for sale in Europe and Asia late this month. Pricing isn’t announced at this time.
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...
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.
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?
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.