Slashdot Mirror
Intel Confirms That Android 3.0 Is Coming To x86 Tablets
timothy writes "Considering that x86 and ARM have been playing leapfrog in at least their future *promised* efficiencies, and that there are a ton of x86 tablets in the works, it's good to see cross-platform OS choices. The most popular Linux distro (Ubuntu) as well as several other conventional Linux options, Windows (even if so far confined to tech demos), and Android — interesting mix."
OOO requires a huge silicon footprint, and it is tricky to avoid increased power consumption. Not exactly an embedded-friendly feature.
The real path to male liberation
Easy to see why Intel thinks it's worth using X86 for Android devices. Hard to see why anyone else would think it's a good idea - except perhaps AMD.
Who cares? If Adobe can't keep up (entirely their own problem) then they will fade away.
Intel still holds a full ARM license. They sold the XScale to Marvell, but retained a license. Why couldn't they build ARM again?
Intel still builds ARM processors. Their entire line of "IO Processors" are basically dual-core ARM chips used for RAID cards. Adaptec and Highpoint both use these chips, for example.
Of course, contributing to Android is to undermine open source as a whole, seeing as how they continue to hide the Honeycomb source but deliver it to Intel. If you truly appreciate open source and want it to succeed in the mobile space, you should support and push for MeeGo (and stop buying shit from companies like Motorola.)
Really? http://www.androidcentral.com/gpl-portions-honeycomb-entered-aosp
Sig Battery depleted. Reverting to safe mode.
and the point ends up enabling Microsoft to come in and pay vendors to put Windows on the device at the expense and exclusion of the other OS's. ARM means you'll have vendors adapting and competing while x86 means you get Microsoft's vision of the world and you only get Windows unless you are creative enough to install another OS yourself. We know most of the world does not install their own OS and couldn't if their lives depended on it.
We are already seeing Intel paying vendors to push out x86 devices so they'll also be taking Microsoft's funny money because on x86 they can throw Windows while on ARM they can not. Consumers lose because of the lack of choice and they'll lose because the x86 and Windows solutions will not have the staying power in the portable device segment because of the bloat. IMO
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
That is a short-sighted perspective. There are some "real world" considerations to be think through.
Open Source, the way we know and love it today, is filled with projects that struggle with direction. GNOME, KDE and other extremely well known projects suffer from having too many people in charge. Meanwhile, commercial projects have the advantage of having stronger direction which is great from a perspective of getting a project planned, built and "completed."
(I know, I will catch hell even for talking about this but go ahead... say what you're gonna say.)
Google is attempting to keep the project as open as it can while still maintaining its direction. As has been said, Honeycomb was designed for a higher resolution display and offers functionality intended for a specific set of capabilities. So in addition to being an OS, it is also an "experience" that needs to be consistent and reliable. It WILL be released. Of that I am certain, but I believe Google is trying to maintain a strong direction element in the project so that this open source project will have the same advantages as Windows and Mac OS X.
And keep in mind that this tablet computing is a new format of computing. It is one in which Microsoft cannot successfully participate at this time. Therefore, this time is crucial for the development of this OS platform and for the tablet market in general. If ever there was a way to take Microsoft down, it is through a market in which they cannot compete and interfere. They can't do tablets and they can't do phones (tiny tablets).
I think Google is doing the right thing at the moment. But I guess time will tell.
In fact it wouldn't be a stretch to say that Linux/BSD/et al just isn't suitable for phones.
Doesn't the iPhone run on a modified BSD kernel? If so, it would seem odd that pretty much every smart phone runs on an operating system that isn't suitable for phones.
I guess it comes down to can intel beat a dual core 2 Ghz ARM?
Yes, easily. Can they beat them in the same power budget? Will the ARM do as much per clock cycle as the Intel? Those are better questions. ARM has a lot to learn about high performance chips. Intel has a lot to learn about low power chips. I wouldn't be so quick to wager ARM can learn Intel's tricks faster than Intel can learn ARM's tricks.
The Atom wasn't targeting ARM, it was more about choking AMD by creating a very low cost, low power chip that'd steal a lot of the "value" market from AMD with battery life AMD couldn't match. In that I would argue it was a success and has been a thorn in AMDs side until the Brazos platform launched this year. It is of course a stepping stone on the way to competing with ARM, but it's hardly the best Intel can do.
Live today, because you never know what tomorrow brings
In that case, the compiler will already have reordered the instructions to fit Atom's microarchitecture.
Sort of. There's not much a compiler can do when you have a last-level (L2, L3) cache miss, which takes hundreds of clocks to service. Even an L1 miss hurts somewhat. OOO processors can execute other, independent instructions for which it has data available in registers or in the L1, and which are in the processor's OOO execution window. In-order processors can't do much. Atom does have some limited ability to hide cache miss latency via some bypassing around L1 misses, but not as much as true OOO.
And what is the benefit of out-of-order compared to simultaneous multithreading [wikipedia.org]?
SMT gets you throughput on multiple threads, for a cheaper area/power budget than just stamping another core down on the die. Obviously it's not as good as another real core, but for some applications that lightly load the processor, for example memory-bound or I/O-bound apps, it is pretty good. It does nothing for single-thread performance however; it can even hurt it single-thread IPC, in fact.