The Linux-Proof Processor That Nobody Wants

RISC is not the silver bullet by wvmarle · 2012-09-16 02:36 · Score: 3, Interesting

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

Re:RISC is not the silver bullet by Anonymous Coward · 2012-09-16 02:48 · Score: 5, Insightful

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.
RISC beats CISC in price performance trade-off, but backwards compatibility keeps the interface the same.
Re:RISC is not the silver bullet by stripes · 2012-09-16 02:49 · Score: 2, Informative
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
FYI, all of Apple's iOS devices have ARM CPUs, which are RISC CPUs. So I'm not so sure your "don't seem to be in any hurry to move back" bit is all that accurate. In fact looking at Apple's major successful product lines we have:
1. Apple I/Apple ][ on a 6502 (largely classed as CISC)
2. Mac on 680x0 (CISC) then PPC (RISC), then x86 (CISC) and x86_64 (also CISC)
3. iPod on ARM (RISC), I'm sure the first iPod was an ARM, I'm not positive about the rest of them, but I think they were as well
4. iPhone/iPod Touch/iPad all on ARM (RISC)
So a pretty mixed bag. Neither a condemnation of CISC nor a ringing endorsement of it.
Re:RISC is not the silver bullet by vovick · 2012-09-16 03:02 · Score: 3, Interesting

The question is, how much can the hardware optimize the decoded RISC microcode? Or the optimization does not matter much at this point?
Re:RISC is not the silver bullet by UnknowingFool · 2012-09-16 03:14 · Score: 5, Informative

I would argue the problem for Apple wasn't about performance but about updates, mobile, and logistics.. PowerPC originally held promise as a collaboration between Motorola, IBM, and Apple. IBM got much out of it as their current line of servers and workstations run on it. Apple's needs were different than IBM's. Apple needed new processors every year or so to keep up with Moore's law. Apple needed more power efficient mobile processors. Also Apple needed a stable supply of the processors.
Despite ordering millions of chips a year, Apple was never going to be a big customer for Motorola or IBM. Their chips would be highly customized that none of their other customers needed or wanted and Apple needed updates every year. So neither Motorola or IBM could dedicate huge resources for a small order of chips as they could make millions more for other customers. PowerPC might have eventually come up with a mobile G5 that could rival Intel but it would have taken many years and lots of R&D. IBM and Motorola didn't want to invest that kind of effort (again for one customer). So every year Apple would order enough chips they thought they needed. If they were short, they would have order more. Now Motorola and IBM like most manufacturers (including Apple) do not like carrying excess inventory. So they were never able to keep up with Apple's orders as their other customers had more steady and larger chip orders.
So what was Apple to do? Intel represented the best option. Intel's mobile x86 chips were more power efficient than PowerPC versions. Intel would keep up the yearly updates of their chips. If Apple increased their orders from Intel, Intel could handle it because if Apple wasn't ordering a custom part, they were ordering more of a stock part. There are some cases where Apple has Intel design custom chips for them, mostly on the lower power side; however, Intel still can sell these to their other customers.
As a side note, as a difference in the relationship between IBM and Apple look at the relationship between MS and IBM for the Xbox 360 Xenon chip. This was a custom design by IBM for MS, but the basic chip design hasn't changed in seven years. As such chip manufacturing has been able to move the chip to smaller lithographies (90nm --> 45nm in 2008) both increasing yield and lowering cost.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:RISC is not the silver bullet by slashping · 2012-09-16 03:18 · Score: 2

The single-cycle rule is bogus. Plenty of ARM instructions (branches, multiply, load/store multiple) take more than 1 cycle, and plenty of x86 instructions only take 1.
Re:RISC is not the silver bullet by stripes · 2012-09-16 03:23 · Score: 2

So far RISC is only found in low-power applications (when it comes to consumer devices at least).
Plus printers (or at least last I checked), game consoles (the original Xbox was the only CISC in the last 2~3 generations of game consoles not to be a RISC). Many of IBMs mainframes are RISCs these days. In fact I think the desktop market is the only place you can randomly pick a product and have a near certainty that it is a CISC CPU. Servers are a mixed bag. Network infrastructure is a mixed bag. Embedded devices are use to be CISC, but now that tends to vary a lot, lower cost embeded devices (under $10) tend to be CISC, but over $10 tends to be RISC.
Ah! You might find CISC dominant in radiation hard environments. There is a MIPS R2000-based silicon on sapphire design in that space, but pretty much everything else is CISC (I haven't looked in a while, but that is a very slow moving market).
Re:RISC is not the silver bullet by stripes · 2012-09-16 03:34 · Score: 5, Interesting

First, RISC instructions complete in one cycle. If you have multi-cycle instructions, you're not RISC
LOAD and STORE aren't single cycle instructions on any RISC I know of. Lots of RISC designs also have multicycle floating point instructions. A lot of second or third generation RISCs added a MULTIPLY instruction and they were multiple cycle.
There are not a lot of hard and fast rules about what makes things RISCy, mostly just "they tend to this" and "tend not to that". Like "tend to have very simple addressing modes" (most have register+constant displacement -- but the AMD29k had an adder before you could get the register data out, so R[n+C1]+C2 which is more complext then the norm). Also "no more then two source registers and one destination register per instruction" (I think the PPC breaks this) -- oh, and "no condition register" but the PPC breaks that.

Second, x86 processors are internally RISCy and x86 is decomposed into multiple micro-ops.
Yeah, Intel invented microcode again, or a new marketing term for it. It doesn't make the x86 any more a RISC then the VAX was though. (for anyone too young to remember the VAX was the poster child for big fast CISC before the x86 became the big deal it is today).
Re:RISC is not the silver bullet by tolkienfan · 2012-09-16 04:15 · Score: 2

Gave it up? http://m.engadget.com/2010/09/06/ibm-claims-worlds-fastest-processor-with-5-2ghz-z196/
Also, porting has much more to do with APIs than instruction set.
Re:RISC is not the silver bullet by smash · 2012-09-16 04:34 · Score: 4, Interesting

I bet that Apple did not make the decision based on technical grounds, it was probably a business decision.
Actually it was both; the great irony is that Apple ditched PPC and went to x86 because of better power consumption with the new intel gear. The core onwards CPUs, in terms of performance per watt, have been awesome and were far and away leaps and bounds better than anything IBM/Motorola could offer with the RISC powerPC processors. If apple didn't go x86 and tried to stick with PPC, they would have been slaughtered in the notebook market, which is/was the fastest growing personal computer segment. Neither IBM or Motorola gave a crap about making a CPU to cater to apples 10% of the portable computer market.
There's a lot of "RISC is so much better for power!" crap floating around, and maybe in theory it is. However in practice when you take into account real world applications and the "race to sleep", having a more powerful, CISC based core with an instruction set that provides many many functions in hardware can help offset the "in theory" better power consumption of the RISC competition. That and the fact that intel has the world's best fabs.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:RISC is not the silver bullet by LostMyBeaver · 2012-09-16 05:14 · Score: 3, Informative

Consoles choose RISC vs. CISC for a much simpler reason. The performance isn't really that important. It's typically an issue of endianess.

It has become quite simple in modern times to make a CPU emulating JIT (meaning treating the binary instruction set of one CPU as source code and recompiling it for the host platform.) what is extremely expensive execution-wise is data model conversion on loads and stores. Unless Intel starts making load and store instructions that can function in big endian mode (we can only dream), data loading in an emulator/JIT will always be a huge execution burden.

The result being that while an x86 can run rings around any of the console processors, a perfect one to one JIT can't be developed to make big-endian code run on a little endian CPU with a 1 to 1 mapping.

As an example of this, if you look at emulators for systems that make use of little endian ARM, performance of the JIT is perfect. In fact, the JIT can sometimes even make performance better. But if you look at a modern 3.4Ghz Quad-Core Core-i7, it still struggles with emulating the Wii which is insanely low performance.

So, don't read into RISC vs. CISC here. It's really an issue of blocking emulators in most cases.
Re:RISC is not the silver bullet by yoshman · 2012-09-16 05:59 · Score: 2

Unless Intel starts making load and store instructions that can function in big endian mode (we can only dream), data loading in an emulator/JIT will always be a huge execution burden.
You mean like the movbe instructions supported by Atom and Haswell? All current x86 CPUs do have support for the bswap instruction, so they can emulate movbe with one bswap and one mov.
Re:RISC is not the silver bullet by Pseudonym · 2012-09-16 12:33 · Score: 2

First, a piece of terminology: The Intel term for what you call "decoded RISC microcode" is "uop". The "u" is meant to be a mu, but it's usually pronounced "u". It's short for micro-operation.
So there are essentially two kinds of optimisation available:
1. How the uops are scheduled. The CPU has a lot more freedom here than a typical RISC processor because the CPU did the code generation, rather than the compiler.
2. If the uop doesn't use a functional unit, don't generate any uops for it. The common case is register-to-register moves, which can be implemented by manipulating the architectural-to-virtual register allocation table.
Some Intel chips also have one more feature which could be argued as an optimisation: there is no L1 instruction cache. Instead of caching x86 instructions in memory, it caches sequences of uops, avoiding the decoding overhead for commonly-executed code.
The other thing is that programmers and compiler writers are told to avoid the more CISC-y instructions (e.g. LOOP, PUSHA/POPA), on the grounds that they are guaranteed to be slow compared to the RISC-y equivalents.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});

Visual Studio is great, but what about MyCleanPC? by CRCulver · 2012-09-16 02:39 · Score: 4, Funny

I'm glad Visual Studio 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).

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!

oversimplified by kenorland · 2012-09-16 02:39 · Score: 5, Insightful

ia32 dates back to the 1970's and is the last bastion of CISC,

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.

Re:oversimplified by aaron552 · 2012-09-16 03:03 · Score: 2

Someday linux devs will resign themselves to the fact that linux is (somewhat) great for servers and terrible for almost everything else.
Remind me how being the core of the most-used mobile operating system is "terrible for almost everything else"

--
I had a sig once. It was lost in the great storm of '09.
Re:oversimplified by Anonymous Coward · 2012-09-16 03:13 · Score: 3, Interesting

What really kills x86's performance/power ratio is that it has to maintain compatibility with ancient implementations. When x86 was designed, things like caches and page tables didn't exist; they got tacked on later. Today's x86 CPUs are forced to use optimizations such as caches (because it's the only way to get any performance) while still maintaining the illusion that they don't, as far as software is concerned. For example, x86 has to implement memory snooping on page tables to automatically invalidate TLBs when the page table entry is modified by software, because there is no architectural requirement that software invalidate TLBs (and in fact no instructions to individually invalidate TLB entries, IIRC). Similarly, x86 requires data and instruction cache coherency, so there has to be a bunch of logic snooping on one cache and invalidating the other.
RISC CPUs were originally designed with performance in mind: instead of having the CPU include all that logic to deal with the performance optimizations and make them transparent, the software has to handle them explicitly (e.g. TLB flushes, cache flushes and invalidation, explicit memory barriers, etc.). As it turns out, it's much easier for software to do that job (because the programmer knows when they are needed, instead of having the CPU check every single instruction for these issues), and it makes the CPU much more efficient.
Re:oversimplified by stripes · 2012-09-16 03:13 · Score: 3, Insightful

I'de say the x86 being the dominant CPU in the desktop has given Intel the R&D budget to overcome the disadvantages of being a 1970s instruction set. Anything they lose by not being able to wipe the slate clean (complex addressing modes in the critical data path, and complex instruction decoders for example), they get to offset by pouring tons of R&D onto either finding a way to "do the inefficient, efficiently", or finding another area they can make fast enough to offset the slowness they can't fix.
The x86 is inelegant, and nothing will ever fix that, but if you want to bang some numbers around, well, the inelegance isn't slowing it down this decade.
P.S.:

IA32 today is little more than an encoding for a sequence of RISC instructions
That was true of many CPUs over the years, even when RISC was new. In fact even before RISC existed as a concept. One of the "RISC sucks, it'll never take off" complaints was "if I wanted to write microcode I would have gotten onto the VAX design team". While the instruction set matters, it isn't the only thing. RISCs have very very simple addressing modes (sometimes no addressing modes) which means they can get some of the advantages of OOO without any hardware OOE support. When they get hardware OOE support nothing has to fuse results back together and so on. There are tons of things like that, but pretty much all of them can be combated with enough cleverness and die area. (but since die area tends to contribute to power usage, it'll be interesting to see if power efficiency is forever out of x86's reach, or if that too will eventually fall -- Intel seems to be doing a nice job chipping away at it)
Re:oversimplified by gadzook33 · 2012-09-16 03:18 · Score: 2

Well it's a matter of personal preference but personally I think android is pretty lousy and suffers from many of the same issues that desktop Linux does such as lack of standardization and a somewhat clunky interface.
Re:oversimplified by RabidReindeer · 2012-09-16 03:22 · Score: 3, Interesting

This is just a rant session about Atom. Someday linux devs will resign themselves to the fact that linux is (somewhat) great for servers and terrible for almost everything else. This will probably get modded as trolling but if I said the opposite thing about MS it would be insightful. In my opinion this entire article is trolling.
Well, excuse me for living.
I boot up Windows for 3 reasons:
1. Tax preparation
2. Diagnosing IE-specific issues
3. Flight Simulator (Yes, I know, there's a flight simulator for Linux, but I like the MS one OK)
Mostly the Windows box is powered off, because those are infrequent occasions and I'd rather not add another 500 watts to the A/C load. All of the day-to-day stuff I do to make a living is running on Linux. If for no other reason that the fact that I'd have to take out a second mortgage to pay for all the Windows equivalents of the databases, software development and text-processing tools that come free with Linux. Or in some cases, free for Linux.
If you said "Linux is terrible for almost everything else" and gave specific examples, you'd be insightful. Given however, that I'm quite happy with at least 2 of the "everything else"s (desktop and Android), lack of specific illustrations makes you a troll.
Re:oversimplified by lkcl · 2012-09-16 03:34 · Score: 5, Insightful

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.
i've covered this a couple of times on slashdot: simply put it's down to the differences in execution speed vs the storage size of those instructions. slightly interfering with that is of course the sizes of the L1 and L2 caches, but that's another story.
in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
now, as we well know, power consumption is a square law of the clock rate. so in a rough comparison, in the same geometry (e.g. 45nm), that 1.6ghz CPU is going to be roughly TEN times more power consumption than that dual-core ARM Cortex A9. e.g. that 500mhz dual-core Cortex A9 is going to be about 0.5 watts (roughly true) and the 1.6ghz Intel Atom is going to be about 5 watts (roughly true).
what that means is that x86 is basicallly onto a losing game.... period. the only way to "win" is for Intel and AMD to have access to geometries that are at least 2x better than anything else available in the world. each new geometry that comes out is not going to *stay* 2x better for very long. when everyone has access to 45nm, intel and AMD have to have access to 22nm or better... *at the same time*. not "in 6-12 months time", but *at the same time*. when everyone else has access to 28nm, intel and AMD have to have access to 14nm or better.
intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Re:oversimplified by Zero__Kelvin · 2012-09-16 03:53 · Score: 4, Informative

"Someday linux devs will resign themselves to the fact that linux is (somewhat) great for servers and terrible for almost everything else"
You don't know anything about Linux. It powers all RISC / ARM based Android smartphones. It also runs on more than 33 different CPU architectures. A huge number of those platforms are embedded systems that are probably sitting in your living room and enabling you to watch TV, DVDs, Blue Ray, etc as well as listen to it all in Surround Sound.

" In my opinion this entire article is trolling."
To be blatantly honest, I haven't quite figured out if it is you that is trolling, or you are really just that ignorant of the facts.

--
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Re:oversimplified by kenorland · 2012-09-16 04:06 · Score: 2

While they were being actively developed and promoted, RISC architectures were beating x86 quite heavily on performance
At times, a high end RISC chip would beat a similarly priced high end x86 chip, but performance advantages were modest and didn't last long.

Intel tried to move on from x86 too, with IA64... They failed, largely because of a lack of backwards compatibility...
Backwards compatibility at the instruction set level matters little to people who need high performance. If IA64 had worked well, people would have snapped it up. IA64 failed because it had a lousy cost/performance ratio, in part because it was nearly impossible to write good compilers for it. In different words, it failed because it was a badly designed architecture and a badly designed instruction set.
Re:oversimplified by kenorland · 2012-09-16 06:05 · Score: 4, Interesting

As it turns out, it's much easier for software to do that job
As it turns out, that's false. Optimizations are highly dependent on the specific hardware and data, and it's hard for compilers or programmers to know what to do. Modern processors are as fast as they are because they split optimization in a good way between compilers and the CPU. Traditional CISC processors got that wrong, as well as hardcore traditional RISC processors; the last gasp of the latter was the IA64, which proved pretty conclusively that neither programmers nor compilers can do the job by themselves.
Re:oversimplified by PCK · 2012-09-16 06:52 · Score: 2

in essence: the x86 instruction set is *extremely* efficiently memory-packed. it was designed when memory was at a premium. each new revision added extra "escape codes" which kept the compactness but increased the complexity. by contrast, RISC instructions consume quite a lot more memory as they waste quite a few bits. in some cases *double* the amount of memory is required to store the instructions for a given program [hence where the L1 and L2 cache problem starts to come into play, but leaving that aside for now...]
New x86 instructions did n't use escape codes, they used unused opcode space, the instruction format has n't changed much since the 386. In fact when going to 64-bits the default data size and some of the fields meanings where changed but other than that nothing radical.

so what that means is that *regardless* of the fact that CISC instructions are translated into RISC ones, the main part of the CPU has to run at a *much* faster clock rate than an equivalent RISC processor, just to keep up with decode rate. we've seen this clearly in an "empirical observable" way in the demo by ARM last year, of a 500mhz Dual-Core ARM Cortex A9 clearly keeping up with a 1.6ghz Intel Atom in side-by-side running of a web browser, which you can find on youtube.
This makes no sense, instructions on modern x86 processors are decoded and stored in the trace cache, in a loop the processor is executing pre-translated instructions. In fact on AMDs latest CPU architecture instructions cant be sent to the execution units fast enough.

intel know this, and AMD don't. it's why intel will sell their fab R&D plant when hell freezes over. AMD have a slight advantage in that they've added in parallel execution which *just* keeps them in the game i.e. their CPUs have always run at a clock rate that's *lower* than an intel CPU, forcing them to publish "equivalent clock rate" numbers in order to not appear to be behind intel. this trick - of doing more at a lower speed - will keep them in the game for a while.
AMD has n't done this for years, and when they did it was because their processors had higher a IPC count than Intels at the time so MHz was not a fair metric to compare the processors.

but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Erm, Intel had VLIW, remember Itanium? Other than in highly parallel number crunching workloads it was being outperformed by Intels own x86s. For general computing VLIW sucks, program execution is just too dynamc.
Re:oversimplified by Anonymous Coward · 2012-09-16 08:18 · Score: 3, Informative
For example, x86 has to implement memory snooping on page tables to automatically invalidate TLBs when the page table entry is modified by software, because there is no architectural requirement that software invalidate TLBs (and in fact no instructions to individually invalidate TLB entries, IIRC). Similarly, x86 requires data and instruction cache coherency, so there has to be a bunch of logic snooping on one cache and invalidating the other.
Err... Not quite:
- x86 TLBs aren't coherent with main memory; you need to do an explicit invalidate every time you change a PTE.
- The instruction to invalidate individual TLB entries is called invlpg, and was introduced with the 486. Admittedly, it's quite slow, so it doesn't get used much, but it is there.
- x86 has only very limited I-D cache coherence. You need to issue a serialising instruction whenever you modify anything which might have been cached in the I-cache.
Basically, there's nothing in the x86 architecture which is both frequently used and extravagantly difficult to implement performantly, at least on uniprocessor systems (although admittedly that's partly because Intel and AMD have spent an enormous amount of research effort solving all the hard problems). On the other hand, x86 does really suck for large (>64-ish core) SMP systems, because it mandates a very strong memory ordering model, and that is difficult to implement efficiently in very large systems (and there's good reason to suspect from the theory that that won't get much better in the near future).
Re:oversimplified by Olorion · 2012-09-16 08:34 · Score: 2

The decoder and the register renamer are on the critical path, so the power they dissipate is far out of proportion to their sizes.
Re:oversimplified by postbigbang · 2012-09-16 08:52 · Score: 3, Funny

Careful, there's a bit of the Bill Gates in your statement.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Bruce+Perens · 2012-09-16 16:36 · Score: 3, Informative

Oh, get off it. If I want to personally attack him, I will do more than ask "Wasn't that when Linus was working for Transmeta?".
Linus was obviously not the only one there who believed they could get more performance out of the architecture than they actually got.

--
Bruce Perens.

Re:Blast in time by Pseudonym · 2012-09-16 02:42 · Score: 4, Informative

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});

Short term vs Long term thinking by UnknowingFool · 2012-09-16 02:47 · Score: 4, Interesting

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.

Re:Short term vs Long term thinking by 0123456 · 2012-09-16 05:16 · Score: 4, Insightful

Oh, you're right. A company the size of Intel couldn't possibly spare one or two people for a few weeks to get support for their new power management into Linux.

Sorry Bruce, but that is total nonsense. by guidryp · 2012-09-16 02:48 · Score: 5, Insightful

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

Re:Sorry Bruce, but that is total nonsense. by CajunArson · 2012-09-16 03:19 · Score: 2

If it were possible to give a +6, then your post would deserve one...
One other thing about the pro-ARM propaganda on this site practically every day: How come the exact same people throwing a hissy-fit over Clovertrail never make a peep when ARM bends over backwards to cooperate with companies like Nokia & Apple whose ARM chips don't work with Linux in the slightest? By comparison, making a few tweaks to turn on Cloverfield's power saving features will be trivial compared to trying to get Linux running on an iPhone 5's A6 SoC....

--
AntiFA: An abbreviation for Anti First Amendment.
Re:Sorry Bruce, but that is total nonsense. by Truekaiser · 2012-09-16 03:51 · Score: 3, Informative

arm does not make their own chips. They design the instruction sets and the silicon photo masks(look up how chips are made) but other companies make the actuall physical silicon product. Those companies can pick and choose what parts of the cpu they want to use and what instruction sets they want in it.
to use food as a analogy, Intel is every store or restaurant that you can buy food pre made and ready to eat. arm would be like someone selling a recipe to you. it's up to you to make it, and what you put into it.
So it's not arm's fault for not supporting linux on the nokia and apple variants of the arm v7 instruction set. It's those respective companies. So if you had enough money and access to either rent or own a cpu fab plant, you too could make your own version of a arm chip and make it only be support on haiku os for example.
Re:Sorry Bruce, but that is total nonsense. by kent.dickey · 2012-09-16 04:09 · Score: 2

Intel in the 90's was performance at any power cost. Then in the last 10 years, it was performance within a limited power envelope, aiming at laptops and desktops. The power they were aiming at was much higher than smartphones, so although they got more "power efficient", you do very different things when aiming at 1W than when aiming at 10W or 100W. If you can waste 5W and get 20% more performance, that's a great thing to do. But not for phones.
I think what you're seeing is Atom was a kludge. If Intel chooses to aim directly at the 1W market, then you'll see there really is no "CISC" overhead.
The ARM Cortex-A9 is comparable in performance per MHz with the Pentium II of the mid-90's. That's because ARM is very sensitive to power, not to performance, so they're not throwing in everything that high-performance CPUs have. Intel is coming at the market from the other end--high performance chips they're trying to trim down to use less power. And they've not executed that well yet. Just look at the Atom--it has a FSB, meaning the memory is attached to a different chip. Lots of wasted power. Umm...ARM chips used in phones have the memory in the same PACKAGE now (stacked die).
Note that ARM has something analogous to the CISC decoder since it has 2 instruction sets it runs (Thumb and ARM). It's not as complex as the decoder needed for x86, though.
Re:Sorry Bruce, but that is total nonsense. by symbolset · 2012-09-16 07:34 · Score: 2

The 1 percent Linux hobbyist market has miraculously changed into the 50 percent Android market in the last two years. Chip makers should care about that.

--
Help stamp out iliturcy.

x86 to blame? by leromarinvit · 2012-09-16 02:49 · Score: 4, Insightful

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.

Linux-proof? Challenge Accepted! by nopainogain · 2012-09-16 02:52 · Score: 2

just send me the hardware.

Re:Blast in time by TheRaven64 · 2012-09-16 02:54 · Score: 4, Informative

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

Re:Thanks by stripes · 2012-09-16 02:58 · Score: 2

BTW, intel processors haven't been CISC for years. They're all RISC with a components that translates from the CISC instructions to RISC

Nice marketing talk. So was the VAX (most of them anyway - I think the VAX9000 was a notable exception) I mean it had this hardware instruction decoder, and it did simple instructions in hardware, and then it slopped all the complex stuff over onto microcode. In fact most CISC CPUs work that way - in the past all of the "cheap" ones did, and now pretty much all of them do. So if you call any CPU that executes "only simple components directly and translates the rest" it is hard to find any non-RISC CPU. Of corse internally they aren't so much "RISCy" as "VLIWy"...

The x86 is still the poster boy for CISC. (and hey, CISC isn't all bad pick up a copy of Hennasy and Patterson and read up on the relevant topics)

Intel will fail at mobile by leathered · 2012-09-16 03:03 · Score: 3, Interesting

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

Re:The Year of Linux on Desktop Is Now by Alex+Belits · 2012-09-16 03:13 · Score: 3, Insightful

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.

Re:Windows developers by Alex+Belits · 2012-09-16 03:16 · Score: 2

The "info" is "just use it on Windows 8 with our great modified kernel".

--
Contrary to the popular belief, there indeed is no God.

Re:Steam the new Unreal Tournament?? by Anonymous Coward · 2012-09-16 03:24 · Score: 2, Informative

Just wait until these people see what "supporting Linux" means to Valve too. I run Steam on OS X and it's not the games fest that they make it out to be. Oh, to be sure there are a few great games there. But aside from CivV (which had a native OS X before Steam) just about every non-Valve game isn't supported except for a handful of "indie" games. The other day I was going down the upcoming release list and not a single major title release was being slated for OS X.

Oh, and wait until one of them has a Steam-centric problem with their system. Steam is a bunch of sweethearts on supporting that too.

Steam may get a few current Linux users to stop using Windows but it's not going to make anyone switch.

RISC vs CISC, really? by fermion · 2012-09-16 03:25 · Score: 4, Informative

Most 70's era microprocessor pretty much had 50 opcode and a few registers. It was possible to memorize these all and decompile from hex in your head. I never had the mental acuity to do so, but many of my friends in high school could. By the 1980's, there was a lot of big iron that used RISC, but as I recall these had more opcodes than, say, a 6502, and I know that RISC does not just mean reduced instruction. It is a simplified instruction set. Right now I think we have a lot of hybrid chips on the market. The war between CISC and RISC has come to place where both are used as needed. In the x86 space, legacy is an issue. MS has not done what Apple does which is to say support a machine for 3-5 years, then develop something that meets current demands. The common person would not even see a RISC processor until Apple switched to the PowerPC, which brought the conflict between CISC and RISC to the public. It is interesting to have this conversation now because this was exactly what was said back them. RISC is more efficient, so the chip can be about half as fast, and still be as fast as the CISC chip.

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

Only benefits.. by Bert64 · 2012-09-16 03:32 · Score: 2

The only advantages x86 has over ARM are performance and the ability to run closed source x86-only binaries...

Performance is generally less important than power consumption in an embedded device, and this CPU is clearly designed for lower power use so it may not be much faster than comparable ARM designs...

And when it comes to x86-only binaries, there is very little linux software which is x86 only and even less for android... Conversely there are a lot of closed source android applications which are arm-only... So at best you have a linux device which offers no advantages over ARM, at worst you have an android device which cannot run large numbers of android apps while costing more, being slower and having inferior battery life.

Windows on the other hand does have huge numbers of apps which are tied to x86, which for some users may outweigh any other downsides. On the other hand, most windows apps are not designed for a touchscreen interface and might not be very usable on tablets, and any new apps designed for such devices might well be ported to arm too.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!

Reality check by shutdown+-p+now · 2012-09-16 03:34 · Score: 3, Interesting

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?

Re:Reality check by fm6 · 2012-09-16 04:27 · Score: 3, Insightful

In geekland, Nobody == Nobody I Know.
Re:Reality check by Bruce+Perens · 2012-09-16 05:54 · Score: 2

Manufacturer announced devices != customer purchased devices.

--
Bruce Perens.

Misleading slant on mention of Atom's RISC core by Dogtanian · 2012-09-16 03:35 · Score: 5, Informative

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

Re:Misleading slant on mention of Atom's RISC core by im_thatoneguy · 2012-09-16 07:32 · Score: 4, Insightful

It also ignores the fact that in flops per watt Intel still dominates ARM.
It's like comparing a moped to a bus and saying "see look how much more fuel efficient the moped is!"
True... but then fill a bus with people and suddenly the mpg per person goes through the roof for the bus. You could get 300mpg per person from a bus. Good luck getting that with a moped.
And like the introduction of plugin hybrids competing with even Mopeds for single occupancy MPG--you can also see RISC x86 chips out-competing ARM too on RAW watts. The next generation of Intel chips are going to be not only substantially faster but also on parity for watts.
Simply stripping down technology inevitably will come back to bite you in the ass. I think the domination of ARM in the mobile space is about to evaporate within the next year on every conceivable metric.
Re:Misleading slant on mention of Atom's RISC core by reiisi · 2012-09-16 19:38 · Score: 2

I think you are confusing Intel with AMD in the '90s.
Sure, Intel (and Motorola) were using RISC tech in their CISC designs from back in the mid-'80s. Bits and pieces of the tech. Not full (almost-)RISC cores running CISC instructions by emulation circuitry (contrary to the propoganda), but cherry-picked RISC techniques. (8 GP registers do not a RISC make.)
AMD's 64 bit CPU was the first real x86 CISC-on-RISC. (And Intel had to go cap-in-hand to AMD for that, in the end.)

--
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.

Re:Visual Studio is great, but what about MyCleanP by MysteriousPreacher · 2012-09-16 03:39 · Score: 3, Funny

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

Re:The Year of Linux on Desktop Is Now by ColdWetDog · 2012-09-16 03:41 · Score: 5, Insightful

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!

Don't bet on it being so much more efficient by samuisan · 2012-09-16 03:46 · Score: 2

> It had better, since Atom currently provides about 1/4 of the power efficiency of the
> ARM processors that run IOS and Android devices.

Don't bet on it. The ARM design in itself is more efficient for sure, but Intel are frankly well ahead of anyone else in actual manufacture.

If they decide to build these with their Finfets and the latest node they have, then the gap between Intel Atoms and ARMs made at Samsung, TSMC or anyone else won't be so noticeable, unless that is that the Atoms actually pull ahead.

It will mean Intel using their latest high cost Fabs for Atoms though, rather than server or high end desktop chips.

Re: ia32 dates back to the 1970's -- B.S. by stripes · 2012-09-16 03:47 · Score: 2

Say again? Are you telling me they had a 32-bit architecture in the 1970s...? I call BS.

No, but the way ia32 is binary compatible with the 16 bit x86 code from the 1970s makes it relevant. You still have to handle AL and AH as aliases to AX. Ask Transmeta how much of a pain that was (hint: that is a big part of why their x86 CPU ran windows like a dog...the other part being they benchmarked Windows apps too late in the game to hit the market with something that efficiently handled the register aliases). If x86 mode was a fully distinct mode that ditched anything from the past that Intel decided made stuff slow then yes, we would be talking about ia32 as a 1980s architecture.

backroom agreement? by zman58 · 2012-09-16 03:55 · Score: 2

"The details of Clover Trail's power management won't be disclosed to Linux developers." ...Perhaps this is because Microsoft is helping to fund development of the Intel solution behind the scenes? Perhaps they have worked out an agreement of some sort to prevent Linux from finding its way onto the chip.

I would like to know why any information would be withheld from Linux developers--the only reason I could imagine for doing so would be to help Microsoft stage a lead on use of the chip. I can think of no good reason Intel would not reveal how the chip works to Linux developers. Providing the information openly would serve only to increase interest and possible additional revenue for Intel that an Android or other Linux based solution could provide to them. Looks like the same old gaming of the the system here--good old buddies.

ARM is not RISC and x86-64 is not CISC by YA_Python_dev · 2012-09-16 04:08 · Score: 5, Informative

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__()

Re:ARM is not RISC and x86-64 is not CISC by imroy · 2012-09-16 04:58 · Score: 4, Interesting

The ARM ISA may seem "complex" when you describe it like you have, but each instruction is still a fixed size, they all follow one of only a limited number of formats (R-type, etc), and memory is only accessed by load/store instructions. That's why many prefer the term "load/store architecture". Anyway, these things really help to simplify your instruction decoder stage and keep memory accesses simple. These in turn make it easier to implement things like pipelines, out-of-order execution, branch prediction, etc. And that's only the stuff that has been implemented in ARM so far. I wonder how long until ARM develops a core with more advanced features, like register renaming and specularitive execution, and how it will perform then compared to x86 (which already has these things).
Re:ARM is not RISC and x86-64 is not CISC by Bruce+Perens · 2012-09-16 05:19 · Score: 5, Insightful

None of today's "RISC" processors are what John Mashey was designing when RISC was introduced.
I agree (and wrote in the article) that ARM has complicated their own architecture, and that Atom uses a RISC-like processor and instruction translation. However, backward compatibility with all of the generations of x86 still increases the complexity of Atom quite a lot.
Thumb (ARM's 16-bit instruction set) is itself an instruction translator to the 32-bit opcodes, adding fixed or default operands for many of the instructions.
The SIMD instructions used by Intel, AMD, and ARM go back to Pixar's CHAP compositing hardware in the 80's.
None of this would have been in a Stanford MIPS.

--
Bruce Perens.
Re:ARM is not RISC and x86-64 is not CISC by default+luser · 2012-09-16 05:56 · Score: 3, Interesting

So you decided that the best way to get this point across to the Slashdot denizens (who never read the article) is to NOT ONCE mention the weaknesses of ARM or the strengths of x86 in your summary.
Never in all my years reading Real World Tech have I ever seen a thread or article absolutely decide the question of "which instruction set is better?" between ARM and x86 (and some of the biggest industry heavyweights weigh-in on those discussions). Does better code density trump better compiler optimization flexibility. And does it even matter when ARM introduces out-of-order in mainstream cores like the A9, and Intel keeps Hyperthreading attached to every new Atom core to deal with blocking?
So just because you feel slighted you write this fluff piece? Bruce, you shouldn't say things that aren't true just because you didn't get what you want, and because this "locked-down" tablet ecosystem is quickly taking away the free software community's free-ride.
And you can keep pretending all you want that Intel can't compete with ARM on performance/watt or price. I guess you weren't paying attention when Intel released the Atom Z2460 phone platform, with competitive performance and battery life? The Xolo x900 has a street price of around $400, so you can bet Intel is charging a tiny fee for that chipset.
Tell me again why Intel can't compete?

--
Man is the animal that laughs.
And occasionally whores for Karma.
Re:ARM is not RISC and x86-64 is not CISC by Bruce+Perens · 2012-09-16 06:20 · Score: 4, Insightful

I didn't write the summary posted on Slashdot. My summary (it's probably still in the "firehose" section) was one line. The Slashdot editor just scraped the first few paragraphs of my article. You can tell the number of people who actually read my article by the discussion of PowerVR graphics. There isn't one.
Intel's competition with ARM right now is like a doped race-horse. They are hiding the problems of their architecture by using a semiconductor process half the size of the competition. Given equal FABs, we wouldn't see Intel as competitive.

--
Bruce Perens.
Re:ARM is not RISC and x86-64 is not CISC by AcidPenguin9873 · 2012-09-16 07:32 · Score: 5, Insightful

Given equal FABs, we wouldn't see Intel as competitive.
Intel has had a fab advantage for years, and it's only getting bigger. Ask AMD how it feels - AMD made nice gains with K8 while Intel had uarch problems (Itanium+P4), but as soon as Intel fixed that (Core2/Nehalem/Sandy/Ivy), AMD felt the pain of their fab advantage all over again, and now AMD has uarch problems AND fab disadvantage.
Saying "given equal FABs" is a ridiculously stupid way to analyze the processor market. Real chips are what people buy, not some hypothetical ARM A15 produced on Intel's 22nm FinFET or an Atom produced in TSMC 28. If you want to talk about microarchitecture, sure, take process out of the equation. But people don't buy microarchitecture, they buy a final product. Fab advantage allows Intel to hide their uarch problems until they fix them. When the next-gen Atom (Silvermon/Valleyview) comes out, then Intel won't have uarch problems AND they will still have a massive fab advantage.
Re:ARM is not RISC and x86-64 is not CISC by Darinbob · 2012-09-16 08:52 · Score: 2

ARM is vastly far away from CISC and very close to RISC. The instruction sets are very regular, decoding is simple, operations are orthagonal, one instruction issue per cycle, etc. Save all those decoding transistors and save power or use them for performance instead.
Re:ARM is not RISC and x86-64 is not CISC by default+luser · 2012-09-16 11:23 · Score: 2

I didn't write the summary posted on Slashdot. My summary (it's probably still in the "firehose" section) was one line. The Slashdot editor just scraped the first few paragraphs of my article. You can tell the number of people who actually read my article by the discussion of PowerVR graphics. There isn't one.
And yet those are your words un-edited (aside from the first paragraph, where they inserted a link)! The incendiary TITLE, and the second and third paragraphs of the article summary are stripped directly from your blog post! How have you magically disavowed all knowledge of the the words that you posted on your blog?
And yet I'll bet you still find a way to convince yourself that your title is not incendiary or fluff.
Speaking of which, you sidestepped my concerns over the main tenet of your article (and I quote): "ARM ends up being several times more efficient than Intel." You make this claim without any analysis, and expect the world to believe you. Except that people have already commented on this matter who tend to know a little bit more about processor micro architectures than you Bruce (like Linus Torvalds, and David Kanter offers further insight), and the general consensus is that Intel is not at any disadvantage against ARM.
Want to tell me in *technical terms* why your worthless blog post has merit at all? Yes, we all know Intel has a process advantage...boo, hoo hoo! Got any other REAL complaints aside from that obvious one?

--
Man is the animal that laughs.
And occasionally whores for Karma.
Re:ARM is not RISC and x86-64 is not CISC by WilliamBaughman · 2012-09-16 11:46 · Score: 2

Bruce, if you understand this stuff so well, why is your article so wrong about RISC vs CISC? And why are your comments about Atom vs modern ARM SoCs so far removed from real power and efficiency measurements? And are you aware that many Android phones (not just the Medfield ones) use PowerVR graphics?
Re:ARM is not RISC and x86-64 is not CISC by unixisc · 2012-09-16 13:34 · Score: 2

Just b'cos they can compete in a certain market doesn't imply that they'd necessarily want to! There are more factors involved than just market-share.
Like I mentioned in the Hondo thread, if Intel & AMD wanted Android to be the target market of their tablet CPUs, they'd have to price it competitively w/ umpteen ARMs out there, and erode their margins. Given a choice, which company would like to do that? Here, they see an opportunity w/ Windows 8 tablets, where they can promote their tablets to run Windows 8, and at least make the claim that it can run Windows 7 software & beyond. While in reality, there may be hurdles, since current Windows 7 apps don't support touch inputs, at least in the battle of perceptions, Intel is not @ a disadvantage here.
For Intel & AMD, the market perception is pretty much baked - that ARM consumes lower power than Android, like it forever has. No matter how low Intel's power consumption is - it's an uphill battle to shake that perception. And even if they did manage to blow it, they'd still have water down their prices to the level of all those ARM CPUs out there. Hardly rewarding. Here, w/ Windows 8, they can @ least use a different perception - that Windows 8 can run one's existing Windows 7 software, even if it's tablets (which is probably less true than it seems). So it makes sense for Intel & AMD to ignore Android, since Android is a great CPU leveller, and forcus on something where they can at least play to their strengths.

Re:The Year of Linux on Desktop Is Now by blind+biker · 2012-09-16 04:24 · Score: 3, Insightful

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.

Re:The Year of Linux on Desktop Is Now by jd2112 · 2012-09-16 04:50 · Score: 3, Funny

You have shattered my dream of playing Angry Birds foe a living.

--
Any insufficiently advanced magic is indistinguishable from technology.

Re:Blast in time by PCK · 2012-09-16 04:58 · Score: 2

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.

If it was just the case of turning off execution units for a processor with a simpler decoder then the Cortex-A9 would n't have the need for the extra low-power fifth core.

Re:The Year of Linux on Desktop Is Now by hack++slash · 2012-09-16 05:14 · Score: 4, Insightful

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.

Here is what Intel says by PCM2 · 2012-09-16 06:15 · Score: 2

This is from an Intel rep:

There is no fundamental barrier to supporting Linux on Clover Trail since it utilizes Intel architecture cores, we are simply focusing our current efforts for this Clover Trail product on Windows 8. Our Medfield products support Android-based smartphones and tablets on the market today, and we may evaluate supporting Linux-based OSes on other tablet products in the future.

Just quoting, believe what you want.

--
Breakfast served all day!

Re:Blast in time by PCK · 2012-09-16 07:09 · Score: 2

This is why modern x86 processors have a trace-cache for decoded instructions.

Re:The Year of Linux on Desktop Is Now by udippel · 2012-09-16 07:27 · Score: 2

Mods, bugger off! How can 437 be a troll?

Plus, he's right. There is no need for VB compiled for other systems. And no, there is no need for C-code compiled with VC on other systems.

Now mod me down as well, please, to be consistent.

Re:Visual Studio is great, but what about MyCleanP by ultrasawblade · 2012-09-16 08:25 · Score: 4, Informative

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.

My hope... by clevershark · 2012-09-16 08:53 · Score: 2

...is that this will fail miserably and cost enough that other manufacturers will think twice before accepting bribes from Microsoft for making something that actively shuts out non-Windows OS's.

--

My sig is too lon

Re:Blast in time by Darinbob · 2012-09-16 09:17 · Score: 3, Informative

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.

Waiting for the day... by DaneM · 2012-09-16 09:36 · Score: 2

I'm just waiting for the day when I can get an ARM-based mid-high-end PC and expect it to run all the applications and games I currently expect from an x86_64 CPU. It's becoming apparent (to me, at least) that ARM is a much better kind of CPU than x86 derivatives, so naturally, I want one--so long as it doesn't put me in the same boat as Mac users were in 10 years ago.

but when you don't have a busload of passengers .. by reiisi · 2012-09-16 19:32 · Score: 2

My bicycle is significantly more efficient getting me to the train station than the bus is.

I walk because it costs 150 yen or so to park the bike. That's still more efficient. I don't live close to a bus stop. Lots of people near me don't live close to a bus stop.

More than half the people going into the station at any particular time of the morning have not come in on a bus. And most buses at this station are about half-full, not operating at maximum efficiency.

The plain and simple fact is that we are not all going from and to the same place at the same time. Buses and trains are very useful in certain traffic corridors, but rely on small-volume transport to fill in the very huge gaps.

That said, there is still more to say. If Intel threw as much money at ARM as they do at x86, ARM could be even that much more efficient at the smaller design rules Intel has to resort to to make x86 anywhere close to efficient. And if Intel had joined (for example) the PPC consortia with the engineers they head-hunted away from better designs, they could have much more efficient server CPUs than any x86 CPU they have now or ever will have.

But, if they had done so, they could not have maintained their practical monopoly on desktop processors, and they would have given up their strategic inroads on servers. (Because someone else owns the IP, you see.)

--
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.

Re:CISC vs RISC by cpghost · 2012-09-17 01:02 · Score: 2

I couldn't agree more. This is absolutely not a matter of CISC (-frontend with a RISC backend) vs. RISC; it's about Intel (and AMD?) withholding hardware specifications of a particular subsystem of their new chips. That's not a technological issue, it is a purely economic/political... and maybe even legal one in some parts of the world (antitrust behavior, anybody?).

IMHO, it looks and smells like MSFT having signed a deal with Intel and AMD to lock down the x86 tablet platform to Win8. This complements nicely the UEFI lockdown on ARM tablets they have signed with hardware manufacturers with Win8 offerings. Nothing really surprising.

--
cpghost at Cordula's Web.

Slashdot Mirror

The Linux-Proof Processor That Nobody Wants

81 of 403 comments (clear)