Slashdot Mirror
The Linux-Proof Processor That Nobody Wants
Bruce Perens writes "Clover Trail, Intel's newly announced 'Linux proof' processor, is already a dead end for technical and business reasons. Clover Trail is said to include power-management that will make the Atom run longer under Windows. It had better, since Atom currently provides about 1/4 of the power efficiency of the ARM processors that run iOS and Android devices. The details of Clover Trail's power management won't be disclosed to Linux developers. Power management isn't magic, though — there is no great secret about shutting down hardware that isn't being used. Other CPU manufacturers, and Intel itself, will provide similar power management to Linux on later chips. Why has Atom lagged so far behind ARM? Simply because ARM requires fewer transistors to do the same job. Atom and most of Intel's line are based on the ia32 architecture. ia32 dates back to the 1970s and is the last bastion of CISC, Complex Instruction Set Computing. ARM and all later architectures are based on RISC, Reduced Instruction Set Computing, which provides very simple instructions that run fast. RISC chips allow the language compilers to perform complex tasks by combining instructions, rather than by selecting a single complex instruction that's 'perfect' for the task. As it happens, compilers are more likely to get optimal performance with a number of RISC instructions than with a few big instructions that are over-generalized or don't do exactly what the compiler requires. RISC instructions are much more likely to run in a single processor cycle than complex ones. So, ARM ends up being several times more efficient than Intel."
Nice advertisement for RISC architecture.
Sure it has advantages, but obviously it's not all that great. After all Apple ditched the RISC-type PowerPC for CISC-type Intel chips a while back, and they don't seem to be in any hurry to move back. It seems no-one can beat the price/performance of the CISC-based x86 chips...
I'm happy for you that you can develop more efficiently with Visual Studio, but I'm piffed that MyCleanPC still isn't available for Linux. I mean, I'm looking at my friend on his Windows box, and ever since he installed MyCleanPC, his gigabits are running faster than ever!
Plus, MyCleanPC completely eradicated any viruses on his computer, sped up his internet connection and gave him some peace of mind! We desperately need a Linux port of such outstanding software as MyCleanPC!
The x86 instruction set is pretty awful and Atom is a pretty lousy processor. But that's probably not due to RISC vs. CISC. IA32 today is little more than an encoding for a sequence of RISC instructions, and the decoder takes up very little silicon. If there really were large intrinsic performance differences, companies like Apple wouldn't have switched to x86 and RISC would have won in the desktop and workstation markets, both of which are performance sensitive.
I'd like to see a well-founded analysis of the differences of Atom and ARM, but superficial statements like "RISC is bad" don't cut it.
Hell, I remember using an Archimedes in 1988. Odd to think that my phone now has four of them.
Back to the topic, the border between RISC and CISC is a bit fuzzy these days. Every modern CISC chip is basically a dynamic translator on top of a RISC core. But even high-end ARM chips can do some of this with Jazelle.
To be fair, CISC does have a few performance advantages when power consumption isn't (as big) an issue. The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely. ARM chips generally don't do out-of-order scheduling and retirement; that uses a lot of power, and is the main architectural difference between laptop-grade and desktop/server-grade x86en).
I'd like to see what a mobile-grade Alpha processor looks like. But I never will.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Some here were immediately crying anti-trust and not understanding why Intel won't support Linux for Clover Tail. It's not an easy answer but power efficiency for Intel has been their weakness against ARM. If consumers had a choice between ARM based Android or Intel based Android, the Intel one might be slightly more powerful in computing but comes at the cost of battery life. For how tablets are used for most consumers, the increase in computing isn't worth the decrease in battery life. For geeks, it's worth it but general consumers don't see the value. Now if the tablet used a desktop OS like Windows or Linux, then the advantages are more transparent; however, the numbers favor Windows are there are more likely to be desktop Windows users with an Intel tablet than desktop Linux users with an Intel tablet. For short term strategy, it makes sense.
Long term, I would say Intel isn't paying attention. Considering how MS have treated past partners, Intel is being short-sighted if they want to bet their mobile computing hopes on MS. Also have they seen Windows 8? Intel based tablets might appeal to businesses but Win 8 is a consumer OS. So consumers aren't going to buy it; businesses aren't going to buy it. Intel may have bet on the wrong horse.
Well, there's spam egg sausage and spam, that's not got much spam in it.
"ARM ends up being several times more efficient than Intel"
Wow. Someone suffered a flashback to the ancient CISC vs RISC wars.
This is really totally out to lunch. Seek out some analysis from actual CPU designers on the topic. What I read generally pegs the x86 CISC overhead at maybe 10%, not several times.
While I do feel it is annoying that Intel is pushing an Anti-Linux platform, it doesn't make sense to trot out ancient CISC/RISC myths to attack it.
Intel Chips have lagged because they were targeting much different performance envelopes. But now the performance envelopes are converging and so are the power envelopes.
Medfield has already been demonstrated at competetive power envelope in smartphones.
http://www.anandtech.com/show/5770/lava-xolo-x900-review-the-first-intel-medfield-phone/6
Again we see reasonable numbers for the X900 but nothing stellar. The good news is that the whole x86 can't be power efficient argument appears to be completely debunked with the release of a single device.
Is it really true that x86 is necessarily (substantially) less efficient than ARM? x86 instruction decoding has been a tiny part of the chip area for many years now. While it's probably relatively more on smaller processors like Atom, it's still small. The rest of the architecture is already RISC. Atom might still be a bad architecture, but I don't think it's fair to say x86 always causes that.
Also, there is exactly one x86 Android phone that I know of, and while its power efficiency isn't stellar, the difference is nowhere near 4x. From the benchmarks I've seen, it seems to be right in the middle of the pack. I'd really like to see the source for that claim.
Proud member of the Ferengi Socialist Party.
Every modern CISC chip is basically a dynamic translator on top of a RISC core.
And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.
But even high-end ARM chips can do some of this with Jazelle.
Jazelle has been gone for years. None of the Cortex series include it. It gave worse performance to a modern JIT, but in a lower memory footprint. It's only useful when you want to run Java apps in 4MB of RAM.
The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely
That's not what my tests show, in either compiled core or hand-written assembly.
I am TheRaven on Soylent News
.. and the reason is not efficiency or performance.. Intel enjoys huge (50%+) margins on x86 CPUs that simply will not be tolerated by the tablet or mobile device vendors. Contrast this with the pennies that ARM and their fab partners make for each unit sold. Even Intel's excellent process tech can't save them cost wise when you can get a complete ARM SoC with integrated GPU for $7.
For all intensive porpoises your a bunch of rediculous loosers
Visual Studio
Please, please, please, stay on Windows, we don't need your Microsoft-infected minds spreading their diseases to other systems.
Contrary to the popular belief, there indeed is no God.
So this OS specific chip is nothing new, and *nix exclusion is not new. Many microcomputers could not run *nix because they did not have a PMMU. The ATT computer ran a 68K processor with a custom PMMU. Over the past 10 years there have been MS Windows only printers and cameras which offloaded work to the computer to make the peripheral cheaper.
Which is to say that there are clearly benefits for RISC and CISC. MS built and empire on CISC, and clearly intends to continue to do so, only moving to RISC on a limited basis for high end highly efficient devices. For the tablet for the rest of us, if they can ship MS Windows 8 on a $400 device that runs just like a laptop, they will do so., If efficiency were the only issue, then we would be running Apple type hardware, which, I guess, on the tablet we are. But while 50 million tablets are sold, MS wants the other 100 million laptop users that do not have a tablet, yet, because it is not MS Windows.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
If nobody wants it and it's a dead-end for technical and business reasons, then how come that there is a slew of x86 Win8 devices announced by different manufacturers - including guys such as Samsung, who don't have any problems earning boatloads of money on Android today?
Heck, it's even funnier than that - what about Android devices already running Medfield?
Like I posted elsewhere, intel hasn't made real CISC processors for years, and I don't think anyone has. Modern Intel processors are just RISC with a decoder to the old CISC instruction set.
Exactly. Intel has been doing this ever since the Pentium Pro and Pentium II came out in the 1990s. Anyone who knows much at all about x86 CPUs is aware of this, and Perens certainly will be. That's why I'm surprised that that article misleadingly states:-
So, we start with the fact that Atom isn't really the right architecture for portable devices (*) with limited power budgets. Intel has tried to address this by building a hidden core within the chip that actually runs RISC instructions, while providing the CISC instruction set that ia32 programs like Microsoft Windows expect.
The "hidden core" bit is, of course, correct, but the way it's stated here implies that this is (a) something new and (b) something that Intel have done to mitigate performance issues on such devices, when in fact it's the way that all Intel's "x86" processors have been designed for the past 15 years!
Perhaps I'm misinterpreting or misunderstanding the article, and he's saying that- unlike previous CPUs- the new Atom chips have their "internal" RISC instruction set directly accessible to the outside world. But I don't think that's what was meant.
(*) This is in the context of having explained why IA32 is a legacy architecture not suited to portable devices and presented Atom as an example of this.
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
This is better:
http://fix-kit.com/Explosive-diarrhea/repair/
http://fix-kit.com/Assassination-of-reigning-monarch/repair/
Finally, downloadable software for Windows that'll cure just about anything!
I imagine /. readers are savvy enough to realise that the site is a scam, and that downloading their software is akin to having unprotected sex with third-world prostitutes.
-- Using the preview button since 2005
So does it matter when someone sends you a .pptx file that Office 2003 freezes on? Yeah, yeah, I'm pretty sure you can get a converter, but I like telling people that if their file has an 'x' in the extension it means that it's 'experimental' and they shouldn't send it to others. They need to send the version without the 'x'.
Faster! Faster! Faster would be better!
Getting back on topic: the last ARM architecture, ARMv8, is far from what was called "RISC" back in the '70s. E.g. it can run instructions of different sizes (16 vs 32 bit), it has 4 specialized instructions for AES, registers with different sizes (32, 64 and 128 bits), instructions for running a subset of the Java bytecode, a rich set of SIMD operations and specialized instructions for SHA-1 and SHA-256.
Similarily the architecture supported by the new Atom chips (which is AMD64/x86-64 BTW, IA32 is only present for backward compatibility) is almost universally run on RISC-like processors that have instruction translators. Considering that the increased density of the x86-64 instructions usually allows to save more cache transistors than the ones required for decoding the instructions themselves, I think that the power consumption differences that we see are more due to the implementation and different traditional focus areas of ARM vs Intel/AMD than inherent differences in the instruction sets.
There's a hidden treasure in Python 3.x: __prepare__()
For me, the year of linux on desktops is now. With Steam coming to Linux [steampowered.com], along with Crossover and pure Linux-ported games, the inevitable has happened. I'm glad Visual Studio [microsoft.com] also runs perfectly on Wine (I'm also making sure to have a party with my friends on Visual Studio 2012 Virtual Launch Party, where thousands of geeks around the globe connect together to party the release of latest Visual Studio).
A bit of "linux on the desktop" ass-licking, followed by a big, fat Visual Studio plug.
Ladies and gents, we have a shill. A very smart one, but a shill none the less. Modded up by a few other plants, no doubt.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
You have shattered my dream of playing Angry Birds foe a living.
Any insufficiently advanced magic is indistinguishable from technology.
Don't give up hope, hundreds of thousands of people in offices across the globe have made a living whilst playing Windows Solitaire.
To do something right, you often have to roll up your sleeves and get busy.
Furthermore a distinguishing feature of CISC vs. RISC is number of general purpose registers. RISC always tried to do everything in registers and treat RAM as an I/O device, instead of stuff like "load accumulator with value in RAM and write it back to RAM" or "load this register with this value from RAM, multiply it with the value in this register, then store it back to RAM." - there are many instructions like this in CISC architectures that encourage treating RAM as just as good for temporary storage as registers - which, of course, it hasn't been for a long time now.
Intel has become more RISCy with MMX/SSE and now with the amd64 extensions that give it 8 more general purpose registers.
Everyone has a RISC style core nowdays because RISC essentially won. People don't understand what RISC was all about though, they tend to think it's about instruction set complexity or microcoding. No, the concept is about putting the CPU resources in places where it matters, eliminating less useful parts of the processor, discarding the accepted design wisdom of the 70s, etc. RISC wasn't even that new or radical an idea, except for the big machine makers. Seymour Cray was using some RISC concepts before the RISC term was invented.
If power consumption is not an issue then code density most likely is not an issue either. Use the space taken up by the decoder and use it for a larger instruction cache or buffer instead. The sole reason the complex decoder is there is for instruction sets that were designed to be hand written by humans. The x86 instruction set was absolutely not created with performance in mind, it was designed as a long series of backwards compatible incremental changes, starting from the original 4004 chip. Every chip since then in the ancestry kept some compatibility to make code easier to convert to the new processors.
Yes it is true that back in the 70s and 80s when this stuff was new that memory was very small and very slow and very expensive. RISC came about in the era when memory stopped being the most expensive part of a computer.