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

Comments

Blast in time

[Anonymous Coward]

Hey, I remember reading this in 1987!

Re:Blast in time

[Pseudonym]

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.

Re:Blast in time

[TheRaven64]

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.

Re:Blast in time

[Truekaiser]

Seems you have not actually been keeping up with the arm architecture. They have had out-of-order-execution since the debut of the cortex a9.

Re:Blast in time

[Anonymous Coward]

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.

This is nonsense. The instruction translator/decoder is a tiny fraction of the full die and the power savings it yields in terms of reducing the external pin transitions and improved performance in terms of the reduced in instruction input bandwidth over those pins (due to the Huffmanesque coding of CISC instructions relative to RISC) more than compensate for the tiny sliver of silicon that the instruction translation logic occupies.

When instruction bandwidth was not the bottleneck, big RISC instructions were not a limiting factor. Now that instruction bandwidth is a bottleneck, CISC's more compact frequently used instructions are more efficient. RISC optimized the instruction decocde. CISC optimized the instructions. The instruction decode these days is not a big factor in power consumption.

Re:Blast in time

[YA_Python_dev]

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.

Are you sure? ARM advertises it as part of all architectures from ARMv5 to ARMv8: http://www.arm.com/files/downloads/ARMv8_Architecture.pdf.

Re:Blast in time

[TheRaven64]

Look at the picture, it's only in ARMv5/6. In ARMv7 it's kind-of there, but the enter Jazelle mode instruction returns failure (check the docs). There's no ARMv8 silicon, but given the lack of market, I'd very much doubt it.

Re:Blast in time

[PCK]

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:Blast in time

[Anonymous Coward]

Back to the topic, the border between RISC and CISC is a bit fuzzy these days.

Meh, pretty simple. Almost all CPUs are CISC. By definition, RISC requires that one instruction does exactly one operation, which means any CPU that can handle SIMD is CISC.

ARM Thumb instructions have been violating this basic premise of RISC since 1994.

End of the sarcasm
Like you said, the differences are fuzzy.

Re:Blast in time

[Anonymous Coward]

True for the instruction decoders. I can't remember which chip it was, but I read about one x86 that had 16 instruction decoders to be able to decode at most 3 or 4 in a cycle. This means that every byte had to be fanned-out to several decoders (first byte only one, 2nd byte to 2, 3rd byte to 3, you see the pattern). Then logic decided what the length of each instruction was and discarded the results from the decoders that had been fed an instruction which did not start on an instruction boundary. This means that at least 75% of the work done by the decoders was lost! Besides that generating copies and routing them costs: fan-out is not free and may be critical in terms of cycle time, i.e., clock frequency.

Re:Blast in time

[PCK]

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

Re:Blast in time

[Darinbob]

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.

Re:Blast in time

[hajile]

Look at the labeled die shot from AMD's presentation on Jaguar. The parts that make CISC differ from RISC are still major parts of the architecture (as written in the old RealWorldTech article www.realworldtech.com/risc-vs-cisc/ ). CISC adds lots of instructions forcing a (much) bigger decode and instruction cache. CISC adds a multi-stage decoder which requires huge increases in branch prediction size just to break even. 32-bit x86 code takes lots more room due to lack of registers (AMD stated (about Hammer) that switching to 16 general purpose registers for 64-bit operation decreased code 5% and increased performance 20% solely based on less time spent grinding the wheels in the dirt). RISC chips are easier to compile for. x86 uses lots of 1 or 2-register operations which require extra mov instructions whenever data shouldn't be overwritten (and that's a lot of the time). There's extra circuitry to deal with instruction dependencies. Finally, all this additional complexity increases the amount of possible errors (Intel and AMD processors have hundreds of unfixable errors that must be coded around. Many of these could be avoided with a simpler system).

Re:Blast in time

[Pseudonym]

In my defence, I did say "generally".

Re:Blast in time

[TheRaven64]

The trace cache, as I said in my original post, is mainly used for loops. It's very small, so it only kicks in if you're running the same sequence of instructions repeatedly. Make it any bigger, and it starts to cut into die area that could be used for instruction cache, so it stops being a win. The trace cache contains the result of translating x86 ops to micro ops. The micro ops are about as complex in terms of encoding as a typical RISC encoding like ARM and so the power cost of decoding them is similar to that of just decoding ARM instructions, except that you need to store them in SRAM twice: once in their encoded and once in their decoded state.

Re:Blast in time

[Alioth]

I've seen both Sophie Wilson and Steve Furber (who designed the ARM instruction set and ARM hardware, respectively) talk. Both are still active in CPU design - Sophie Wilson now working for Broadcom designing processors for networking gear, and Steve Furber at Manchester University is a researcher.

Two interesting points: Sophie Wilson says there's no reason why Intel can't have the same power efficiency as ARM. However, that doesn't necessarily mean that in the small end of the computing world, Intel will be any good - Steve Furber pointed out in his talk when asked "since Intel x86 etc is now a RISC like core with a translator, where's ARM's advantage?" that *just* the part of the x86 that works out how long the next instruction is (just that part!) is as large as an entire ARM execution core. That's not to mention the much more complex circuitry needed to implement things like the pipeline, do branch prediction etc. This doesn't matter so much in a big system like a server where most of the die is taken up by cache, but in a small system it puts x86 at a big disadvantage. Especially a small multicore system.

The other thing that ARM has is they license their design so anyone cam make a SoC they want with the peripherals they want. With Intel, you get only what Intel gives you. So even if Intel got to the power efficiency of ARM for small systems, designers of small systems will still go with ARM partly due to backward compatibility and existing experience (ARM has a strangle hold here for the same reason as Intel has a desktop/server CPU stranglehold), and partly because they can make whatever SoC they want with ARM and aren't limited to what they get offered.

Re:The Year of Linux on Desktop Is Now

[Anonymous Coward]

Except it doesn't matter and hasn't for years. The world's most popular applications run in browsers, not desktops.

RISC is not the silver bullet

[wvmarle]

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

[Anonymous Coward]

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

[Anonymous Coward]

That's not a RISC vs CISC thing. Intel has just put tons of money into making CISC not suck. They may have also done that to make Windows work on Mac or to relieve the burden on some software developers who add assembly to their code so they only have to make it once (i.e. sse3 instructions in Photoshop).

Re:RISC is not the silver bullet

[stripes]

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

[Anonymous Coward]

RISC has similar problems as IPv6...
Everyone knows that they are better, but business that stifles investment and progress aka "buy the cheapest" will always keep an older inferior system alive as long as possible.
I bet that Apple did not make the decision based on technical grounds, it was probably a business decision.
Even in the end of 1980's there were big articles about how much better RISC is.
We seen how great it can preform in Sun Sparc and PowerPC machines..

And i think we finally are watching RISC to gain momentum, via mobile phones, tablets etc...
Even the "big" player Microsoft is releasing binaries for ARM (RISC) architecture.
There are rumors about servers with ARM instead of Intel/AMD

The interesting thing is to see if they "liftoff" before larger introduction of cell processors that seems to be the next step in processor architecture...

Re:RISC is not the silver bullet

[wvmarle]

iPhone and iPad are not known as powerful devices; computing power lags far behind a typical desktop at double the price. Form factor (and the touch screens) add a lot of cost.

So far RISC is only found in low-power applications (when it comes to consumer devices at least).

Re:RISC is not the silver bullet

[vovick]

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

[drinkypoo]

The summary is outright incorrect. First, RISC instructions complete in one cycle. If you have multi-cycle instructions, you're not RISC. Second, x86 processors are internally RISCy and x86 is decomposed into multiple micro-ops. Third, RISC may mean less gates for the same tasks, but it also means that some tasks get broken up into multiple tasks.

ARM doesn't scale as far as x86, so in the high end you need more cores and some tasks are less parallelizable than others. ARM should be recognized as the current killer in the low end, while x86 (well, amd64) is clearly still the best price-performance option in the high end.

Re:RISC is not the silver bullet

[Anonymous Coward]

The reason Apple left for it was to compete with Windows more.

IBM were lagging behind in Power because they, well, history already happened. They gave it up.
Intel, however, were going full-speed in to multicore processers, whereas IBM with Sony and Toshiba made the experimental CellBE, which could have went places if they never gave up on it. But 3 companies working on one thing like that was destined to fail.

If Apple switched to the same architecture that Windows used, they could get programmers making the same native apps on their OS without much of a hassle in porting them.
Power was what gave Apple that advantage for media creation up until Intel went multicore. At that point it was more-or-less the same until Intel eventually overtook IBM. Still makes me laugh that this thing is still used by Apple fanboys of today though, that advantage is long gone.

Re:RISC is not the silver bullet

[UnknowingFool]

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.

Re:RISC is not the silver bullet

[slashping]

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

[Anonymous Coward]

Nice strawman:

Apple ditched PowerPC because IBM was better at getting performance rather than power management. This isn't a fault of the RISC architecture just like a Pinto's issues are not due to having four wheels.

Apple also knew that x86 is cheaper and that people would buy Macs to run Windows. Being able to use PC hardware cut their manufacturing costs by a significant margin.

No matter how much state-of-the-art lipstick Intel puts on it, there is still a 1970s-era pig underneath.

Yes, the RISC/CISC battle went Intel's way, but it was not for the CPU architecture. It was Intel's ablity to keep wrapping a shell around the antediluvian x86 command set, then add the 64 bit extensions after AMD added theirs.

ARM may not be as fast, but because it doesn't have to have the exotic microcode the x86 descendants have, it can perform fewer switches per CPU calculation, thus less power consumed.

Re:RISC is not the silver bullet

[Anonymous Coward]

That was in part because IBM was taking the PPC places that Apple was not interested in, and other suppliers had no product ready within reasonable time that could keep up with x86. The problem was not RISC, it was down to the business plans of the PPC producers at that time. Now Apple do their own chips, in the form of an ARM variant. Likely they have some variant in the lab that is set up and clock more like a desktop CPU than a mobile SoC. And if Intel ever gets uppity about Apple demands, well hey here is a ARM based Mac and the tools to yet again produce fat binaries for the transition. Or Apple slowly exits the traditional desktop market by slowly importing more and more design concepts from iOS into OSX.

Re:RISC is not the silver bullet

[stripes]

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

[gweihir]

Unless you have energy constraints, that is. Then RISC architecture rules. Given that most computers today are smartphones (and most run Linux, some run iOS), and many other CPUs are in data-centers were energy consumption also matters very much, I think discounting RISK this way does not reflect reality. Sure, enough people do run full-sized computers with wired network and power-grid access at home and these will remain enough to keep that model alive, but RISK has won the battle for supremacy a while ago.

As to Linux: It is already dominant in the server space. The year of "Linux in the pocket" has been a while ago. On the desktop? That will come, as soon as MS customers realize that MS cannot innovate away from what works well. The ribbon, their desktop-unfriendly new window manager, etc., are all attempts to be different, even if it degrades usability. At that time, the alternatives will catch up and "Linux or Windows" will not matter that much anymore. On the plus side, that will also be the time when Windows finally catches up and become a modern, reasonable OS. Might still take a while though and require significant depletion of the MS war chest. But the atrocious Win8 is a step in the right direction. Nobody in their right mind will want that either on the desktop or on a tablet or smartphone. Forget about enterprise users as well, they are currently thinking about whether all the changes in Win7 are too much to migrate away from XP or have just migrated to Win7. I also know some pretty large Enterprises that are still on Office 2003, because they do not want to retrain their people for the Ribbon.

Re:RISC is not the silver bullet

[stripes]

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

[Anonymous Coward]

They moved, most likely because it was and still is cheaper to go with x86 chips. IBM was the one making their powerpc chips correct? While every other chip maker for desktops is making x86 chips... Arm and most of the risc type chipsets are for mobile devices not the desktop, though I bet some of these high end mobile chips would be good enough you prob couldn't tell a difference until you got to the gpu.

Also not as much software runs on risc compared to x86. I mean yeah linux can support it and windows could if they compiled a version for it, but all the other apps,games and other programs already out will not run on risc unless it can emulate x86 or x86-64. Wouldn't be quite as much of an issue for new releases as they can just compile for whatever the new arch is.

Though it does pose an interesting area to explore. Now with multi-cores being the norm even for x86 cisc chips. imagine how many of these small risc cores you could pack into the same space? would be neat to try

Re:RISC is not the silver bullet

[Anonymous Coward]

A lot of second or third generation RISCs added a MULTIPLY instruction and they were multiple cycle.

Just to make clear that this is not something that happened recently: the first ARM processor with multiply instructions was the ARM2, back in 1986. And I'm fairly sure the ARM1 was only a proof of concept. Unless you worked for Acorn in the mid-80s, every ARM chip you've ever used had multiply instructions.

Re:RISC is not the silver bullet

[Anonymous Coward]

The only reason why x86 seems to have an advantage is simply because Intel has spent lots of it's Microsoft-monopoly money on having the smallest transistors possible. They're consistently one process technology ahead of the rest of the industry, which lets them get away with such inefficient designs.

Re:RISC is not the silver bullet

[tolkienfan]

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

[smash]

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.

Re:RISC is not the silver bullet

[Anonymous Coward]

You are correct in the context you've created. But Apple doesn't care RISC or CISC. They "ditched" PowerPC for "business" reasons. You know, the kind that the bean counters start out by stating "we feel...".

One of many issues with PowerPC architecture is the power consumption (hence the name?) Jobs wanted smaller, cooler, quieter, power efficient, battery life, etc. For reasons more detailed than I know or care to research, PowerPC got hungrier and hungrier. I own many.

I own a dual G5 (2.5GHz) that friggin screams. It feels, acts, and runs more than twice as fast as a quad Intel 3 GHz Power Mac I use often. It's way way way faster than the dual G4s I also own. I sometimes fire up my G5 just to feel giddy about how fast it boots, how smooth and fast it feels, and how it shuts down in less than 10 seconds. It has the liquid cooling system. The fans are normally essentially silent, and only speed up a little when doing processor intensive operations, like audio or video rendering.

I'm not arguing for CISC or RISC. I think these arguments are silly. They each have their strengths and we've seen sharing and morphing between them and I just hope for the day when someone makes an architecture that combines them. Surely won't be Harvard!

Re:RISC is not the silver bullet

[galanom]

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.

Idk for computer processors, but Texas Instruments had some older DSP that could load, store, add, multiply and add-and-multiply in single cycle (TMS320C30 for example). Modern models ('C67xx, 'DM642) may not compute in single cycle but do not block execution - flow continues, and when data is ready it appears at the registers. Even conditional jump is single-cycle as it continues to flow, and 4 clocks later executes the jump (you can fill with NOPs if you please)

Actually it is less than single cycle if you take into account that you can execute (by hand) multiple instructions per clock (granted that you don't use the same resource).

Re:RISC is not the silver bullet

[KingMotley]

The single cycle part of your post is inaccurate, but I'd mod you up for the rest of it if I had mod points left.

Today's intel processors have combined the best parts of both the RISC and CISC worlds, and really can't be classified as being completely either type architecture. Externally it's CISC, but internally it acts much more like a RISC processor.

I'm not aware of any successful implementation of a pure RISC processor at the high end. If there is one, please point it out because I'd like to learn about it. And it sure doesn't look like the PPC chips are very comparable today.

Re:RISC is not the silver bullet

[LostMyBeaver]

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

[Anonymous Coward]

SPARC and POWER certainly are high-end RISC processors I'd say.

Re:RISC is not the silver bullet

[BenoitRen]

Apple ditched the PowerPC because there is so much effort in improving the terrible x86 architecture that PowerPC's advantages eventually became meaningless.

Re:RISC is not the silver bullet

[Anonymous Coward]

I think you are muddying the waters - of course it's not going to be a single cycle as you'd have to load the instruction, decode, and store in one operation. Also a 32 bit word in a 32bit instruction set would naturally mean that you couldn't store the entire instruction in a single word - pretty much required for RISC.

Something like MIPS will have an instruction which specifies a register and a (16 bit?) offset from on of the pointer registers to load from - the instruction will be loaded, decoded, value fetched and stored as parts of the five (or so) stage pipeline. It takes 5 cycles, but as this is part of a pipeline of 5 other instructions it is essentially 1 cycle per instruction.

Much easier for a compiler to schedule complementing concurrent instructions to best make us of the pipeline in the context of the program than for a microcode to deal with whatever stream of instructions spat into it with no context of the program as a whole.

Re:RISC is not the silver bullet

[yoshman]

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

[Anonymous Coward]

For space applications, the RAD750, based on PowerPC750, aka G3, seems to be a favorite these days (that's what Curiosity uses for the matter). I've seen Sparc, MIPS, and PPC used for satellites and deep space mission. Not a single x86, it seems nobody is interested in producing a low volume high cost x86 processor. On the same process the PPC offers much better bang for the buck than x86, especially on process geometries from the mid 90's (and with
a decent FPU instead of the nightmare of the stack based x87 FPU of that epoch).

Actually, if I remember correctly, the RAD750 is produced on a less advanced process, in terms of feature size, than the first G3 Macs.

Re:RISC is not the silver bullet

[Anonymous Coward]

Apple initially choose the RISC PowerPC chip because it was RISC as opposed to the x86 family of "wintel". They ditched the PowerPC chip because IBM was the only one making those chips which meant Apple was solely dependent on this single partner which produced this special hardware only for them. Somewhere along the lines of being utterly dependent on IBM and at the whim of their pricing structure, they decided not to shoot themselves in the foot and go with "commodity" chips. More favorable prices and less risk in being dependent on a single manufacturer.

Re:RISC is not the silver bullet

[Anonymous Coward]

There is a lot of innovation that's gone into making intel chips fast at the cost off power hungry complexity. ARMs run lower power through simplicity - they simply have far, far fewer transistors. Without adding some complexity they will never compete with Intel's speed, absolutely, but Intel are fighting a losing battle to turn their x86 architectures into something that can compete on ARM's turf.

Re:RISC is not the silver bullet

[Bengie]

The single-cycle rule is bogus.

If you remove "The single-cycle rule", then there is no difference between RISC and CISC. Single cycle is the corner stone of the difference between the two.

Re:RISC is not the silver bullet

[Bill_the_Engineer]

Ah! You might find CISC dominant in radiation hard environments.

I've used PowerPC based CPUs in radiation environments without issues.

Re:RISC is not the silver bullet

[Anonymous Coward]

Actually each RISC instructions is executed at one instruction per cycle.

However a RISC instruction can take multiple cycles to complete. The compiler will need to order instructions in such a way that the program will actually work. Interleaving different computations, or if all other things fail inserting no-operation instructions.

For example a conditional jump instruction like jump-on-not-equal will take two cycles to actually update the instruction pointer. Therefor the instruction after the JNE will always be executed if the condition is true or not.

Re:RISC is not the silver bullet

[ZosX]

There were power pc cores that were later designed to be much more efficient. They have also remained competitive with x86 in terms of power. Apple switched because intel was moving faster than ibm/motorola. Power pc is still used on high end servers and mainframes, so clearly they were able to keep up.

Re:RISC is not the silver bullet

[stripes]

I've used PowerPC based CPUs in radiation environments without issues

Cool! Was it a designed to be radhard PPC, or was it a normal PPC that turned out to be radhard enough?

Re:RISC is not the silver bullet

[Anonymous Coward]

i'm pretty sure they switched because Intel chips were cheaper than PowerPC chips. Who else uses PowerPC? I'm sure somebody does but compare the moving volume of PowerPC chips with Intel chips. Surely Intel moves more volume and, therefore, can offer a better price. I'm fairly confident that Apple was probably in the top 5 of volume PowerPC buyers. I'm guessing PowerPC kept uping the price and betting Apple would gladly pay it.

Re:RISC is not the silver bullet

[gagol]

Do you have any idea of the rice tag of this processor module? To chieve this IBM threw lots of money in MCM ceramic modules and what not. IBM POWER series are not meant for volume production, are not cheap and will not fit inside anything portable by today's standards. Way to compare apples and oranges!

Re:RISC is not the silver bullet

[Anonymous Coward]

After all Apple ditched the RISC-type PowerPC

RISC is indeed superior. The reason Apple needed to move from PowerPC was due to IBM's investment in the chips made for Apple; Apple's business was so small it created no incentive for IBM to improve the chips, and they stagnated. The chips IBM was making for Apple were special, and included AlteVec, which no one else was using. Had IBM stuck to their roadmap, Apple would have stayed with them... but, again, IBM had no incentive to placate Apple with GHz advances in these special versions of PowerPC chips, so Apple moved to Intel.

Re:RISC is not the silver bullet

[viperidaenz]

Modern? It's been that way for nearly 20 years

Re:RISC is not the silver bullet

[viperidaenz]

Intel's current CPU's beat ARM hands down in performance per watt. I doubt there is a competitive PPC processor.

Re:RISC is not the silver bullet

[ZosX]

PPC is over 5ghz now. Quite competitive!

Re:RISC is not the silver bullet

[tolkienfan]

What was I comparing?

Re:RISC is not the silver bullet

[hajile]

Intel killed most RISC through Itanium marketing. Everyone was convinced that RISC was better than CISC. Everyone was also convinced that VLIW (EPIC in our case) was better than RISC. The problem there was that VLIW has two glaring problems. The first is that compilers haven't yet (years after Itanium released) come close to the optimization they were supposed to be capable of creating (a little like it was once believed that AI was just a few years away). The second is that some optimizations can't be predicted by the compiler anyway. IBM's POWER, DEC/Compaq's Alpha (later bought by Intel... I assume that Intel's internal x86 micro-ops take inspiration from Alpha), MIPS non-low power division, HP's PA-RISC, etc all bet that Itanium would be the next great thing (Intel was claiming outrageous and unjustifiable performance numbers). Meanwhile, Intel continued development on it's high-end x86 chips (the screw-up known as P4). With almost all of Intel's competitors shutting down or drastically scaling back, Intel gained several years worth of advantage (something that most companies involved still haven't recovered from). Apple changing to x86 is part of the fallout from this decision. IBM and Apple weren't wanting to spend the R&D money needed to make a competitive chip (first betting on the Itanic and later not wanting to play catch-up). Thus, Apple switched from POWER to x86 serving as a (seemingly lost) example of why to never trust a company that claims something is great when that company doesn't have product in hand (Itanic launched and all it's competitor's chips which were already too far along to cancel offered better performance).

Re:RISC is not the silver bullet

[Pseudonym]

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.

Re:RISC is not the silver bullet

[Snorbert Xangox]

John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.

He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]

The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as:
- no variable-length string comparison/move instructions
- accesses to multibyte data are aligned so they can't cross page boundaries
- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.

The more complex the exception handling requirements, the more you pay to implement those, either with more hardware, [which can imply more cost, or more power, or longer cycle time], or by giving up opportunities for parallelism because the exceptions get too hard to handle with many operations in flight. Even if an exception is rare compared to the common case, the implementation has to be able to handle it correctly...

Re:RISC is not the silver bullet

[Anonymous Coward]

Gulliver would be proud of such a meaningless reasoning behind choosing which end to crack the egg on.

However, in the real world the efficiency of a particular architecture is not dependent on endianess. In fact, most modern CPUs provide an extremely efficient way to flip bits. Go ahead and look it up. Also, don't take what you learn from your CS prof as the gospel. It may have been a while since he has done any meaningful work in his field.

Re:RISC is not the silver bullet

[unixisc]

x86_64 is RISC, if you don't count the 32-bit instructions. And you can bet that at some point, support for 32-bit instructions will be deprecated, just like support for 16-bit instructions are now. Probably @ the point where 8GB is the bare minimum you can buy. And once the CPU drops support for 32-bit instructions, the CPU will be a RISC, not a CISC, CPU

As others have pointed out, ARM is not exactly a RISC CPU, due to both variable instruction lengths, as well as different instructions taking different #cycles to complete

Re:RISC is not the silver bullet

[unixisc]

RISC doesn't have problems similar to IPv6. CISC CPUs - since the Pentium II - have been internally RISC, but externally CISC. There is no way an internet protocol can internally have 128 address bits but externally 32. Businesses go w/ IPv4 b'cos that's still the vast majority of what is available, and vendors haven't moved. Which was never the case w/ RISC - it was available to whoever wanted it - from IBM, DEC, HP, Sun, SGI, Intergraph, and so on.

RISC was always popular in networking gear, games consoles, and now tablets & phones.. CISC hasn't been making inroads into non PC platforms.

Re:RISC is not the silver bullet

[unixisc]

Which is why ARM is not exactly RISC. And x86 would indeed be RISC once it loses its old Pentium era 32-bit instructions that have been deprecated in x64 as far as 64-bit instructions go

Re:RISC is not the silver bullet

[smash]

Yes, they're used in high end servers and mainframes. Where power consumption isn't as important.

There is no real suitable PPC processor on the market for laptops. The potential market share is not there to justify the effort to develop one, either.

Re:RISC is not the silver bullet

[unixisc]

There are quite a number of PPC vendors as well - the company that Apple acquired - PA Semiconductors - was a PPC vendor, not an ARM one. So Apple could have used a PPC platform for iOS, instead of ARM, and what's more, they could even have re-designed the Mac around that CPU, but using off-the-shelf PC peripheral chips. An ARM based MAC would be yet another jump, and not needed. Indeed, I hope that at least internally, Apple has PPC versions of Mountain Lion running so that if they ever needed, they could revert to that. I mean, if all the game consoles could go w/ POWER, why not Apple?

Re:RISC is not the silver bullet

[smash]

You missed the "per watt" part. PPC has not been designed for mobile. The potential mobile market to run PPC software is non-existent.

Re:RISC is not the silver bullet

[FrangoAssado]

If you remove "The single-cycle rule", then there is no difference between RISC and CISC.

No. With RISC, the only way to access memory is via load/store instructions. The general data processing instructions (arithmetic, comparison, etc.) are always done on registers. That's why instructions are very simple.

On CISC, on the other hand, you can use data from memory without loading it into registers, for example in x86 you can do something like "add eax,dword ptr[ebx]" or "add dword ptr[ebx],eax".

Re:RISC is not the silver bullet

[LordLimecat]

And im pretty sure AMD64 isnt RISC, but the current-gen Intel 64-bit chips absolutely slaughter RISC chips in terms of computational efficiency, if Im not mistaken.

It was hard to find details, but it looks like as an example, a Cortex A8 gets ~15MBps for AES when benchmarking in OpenSSL; it uses anywhere from 1 to 10w. An unaccelerated low-voltage Sandy Bridge (like the 2GBps with AES-NI. Best case scenario (the A8 using its "idle" of 1w), the Xeon merely beats it by ~20%, and with a more realistic load of 3-4w the disparity grows-- this before factoring in the AES acceleration, at which point the Xeon blows the Cortex out of the water.

Re:RISC is not the silver bullet

[LordLimecat]

Somehow between preview and submit my post got mangled. The sandy bridge in question was a Xeon E3 1220-L2-- dual core, 17w TDP.

Re:RISC is not the silver bullet

[reiisi]

You've got a few of the points right, but my experience with a single-core Atom (recent Lenovo) versus a single core G4 (ancient G4 iBook) leads me to think Intel really only caught up with the PPC recently.

Re:RISC is not the silver bullet

[Anonymous Coward]

1. Incorrect. The CPU does not do "code generation" in any way akin to compiler code generation, it just cracks instructions into typically 1-2 uops. Modern OOOE RISC CPUs can actually also crack difficult instructions into micro instructions in the same way. Scheduling of instructions is really just a function of its dependencies, and the reason why instructions are cracked is to simplify these dependencies (which is how typical RISC instructions already come).

2. This is not an x86 or even a uop specific optimization. On recent Intel CPUs it was made possible with the use of PRFs.

3. The Pentium 4 had no L1 x86 instruction cache, instead it had a trace cache. Core CPUs had progressively more capable uop caches, but they still have L1 x86 instruction caches too. Some RISC CPUs have similar decoded-instruction caches (ARM A15 is one).

Re:RISC is not the silver bullet

[UnknowingFool]

The problem was Apple needed a mobile G5 with more computing power and at an acceptable power consumption and cooling. The G5's were hot and power hungry. IBM and Motorola were not able to do that without significant investment.

Re:RISC is not the silver bullet

[dfghjk]

Only if that's the only "instruction set" you look at.

It has been decades since the instruction set dictated the internal architecture of the processor. The distinction is irrelevant.

Curiously, RISC is inherently less power efficient than CISC because it requires more space to encode it's operations and therefore requires more memory bandwidth. Of course, that's only if you consider the instruction set. See how stupid the argument is, and how uninformed the article is?

Re:RISC is not the silver bullet

[dfghjk]

Because there is no RISC vs CISC. That left the equation long, long ago. No need for tribalistic nonsense.

Re:RISC is not the silver bullet

[dfghjk]

"Everyone knows that they are better, but business that stifles investment and progress aka "buy the cheapest" will always keep an older inferior system alive as long as possible."

Everything about this comment is wrong.

x86 won because it proved that RISC vs CISC doesn't matter. All that remains is a bunch of architectures with a legacy of RISC (plus one CISC) where all use similar internal approaches. This solution was arrived at through intense market pressure and tons of research investment on both sides. If it were only what was cheapest, PowerPC would have won out because that was its strategy from the start. They got Apple, everyone else cared more.

Re:RISC is not the silver bullet

[dfghjk]

"Yeah, Intel invented microcode again, or a new marketing term for it."

That process is in no way "microcode", though someone totally ignorant on the subject might make that assumption.

Spend a little more time educating yourself and less time telling others how superior RISC is.

Re:RISC is not the silver bullet

[dfghjk]

Apple switched because Intel was vastly superior in performance. Nothing else. IBM had long since abandoned PowerPC as a desktop processor and would not commit to doing a PowerPC variant of their current Power design. Since Moto/Freescale sucked, the writing was on the wall.

PowerPC (Power was different at the time) did not provide "media creation" advantages either. There were the Altivec extensions which were not a PowerPC standard anyway, but most of the media creation "advantages" were not from hardware. Even given Altivec, the architectures were not "more-or-less the same". PowerPC languished with derivatives of the 603/604/620 architectures that were created by IBM from the start. By the time IBM made an all-out performance part with the 970/G5, all it proved was that PowerPC was not compelling on the desktop. It was enormously power-hungry as well. Some argument for the power advantages of RISC. ;)

Re:RISC is not the silver bullet

[Bengie]

Being able to atomic modify a memory location allows x86 to have much faster/cheaper multi-thread locking. Sounds like a feature to me.

Re:RISC is not the silver bullet

[dfghjk]

"PowerPC originally held promise as a collaboration between Motorola, IBM, and Apple."

PowerPC was not originally a collaboration between those three. It was IBM and Motorola, with IBM providing ALL of the technology. Apple was PowerPC's first customer, they were not a contributor.

With that in mind, it's easy to understand the true meaning of "highly customized" and "for one customer". PowerPC was the Power architecture adapted to PCs, and Apple was the only PC customer. In other words, PowerPC was a failure, IBM/Moto/Freescale wanted to focus on their real market so Apple was left out in the cold. Serves them right, as the PowerPC concept was bogus from the start.

IBM's current line of servers and workstations don't run on PowerPC either. IBM never adandoned their Power line during the PowerPC era. The entire line runs on those processors.

Re:RISC is not the silver bullet

[dfghjk]

It's easy to say these things when you don't know anything.

Re:RISC is not the silver bullet

[Anonymous Coward]

It seems no-one can beat the price/performance of the CISC-based x86 chips...

The Cell processor developed for the PS3 proved you wrong

Re:RISC is not the silver bullet

[dfghjk]

Apple does their own chips that contain ARM cores, but they don't design the ARM cores. Apple is in no way in control of the ARM processors in their mobile systems, they are only in control of how they are packaged. They have no ability to introduce ARM as a competitor to x86 on the desktop and it is not simply of matter of clocking one more like a desktop.

Re:RISC is not the silver bullet

[FrangoAssado]

Again, no. Just because it's a single assembly instruction, it doesn't make it atomic -- x86 will do exactly the same as any RISC processor: it will load the memory contents, perform the add and then store the result. Nothing guarantees that another processor will not modify the memory content during the execution of the instruction.

If you want to do it atomically, you'd have to do something like this.

Re:RISC is not the silver bullet

[Guy Harris]

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.

Was Rosetta, translating PowerPC to x86, really that bad?

Re:RISC is not the silver bullet

[Guy Harris]

x86_64 is RISC, if you don't count the 32-bit instructions.

And if you don't count the non-register-to-register arithmetic instructions and the CALL instruction (even in its simplest form, it pushes the return address onto the stack rather than just stuffing it in a register).

Re:RISC is not the silver bullet

[Guy Harris]

John Mashey, one of the MIPS architecture designers among many other things, has written a really good essay on RISC architectural choices.

He posted it to the comp.arch USENET group a few times; here's a copy of that post that renders in a monospace font so you can read the ASCII tables easily. [Google Groups' version makes the tables unreadable.]

The best rule of thumb I like to remember from that essay is that RISC architectures try to make exception handling simple; for example, they don't tend to use the MMU for data access more than once per instruction, because then you have multiple ways that the instruction can generate an exception. Other RISC choices can be seen as stemming from this rule, such as: - no variable-length string comparison/move instructions

Still applies to most if not all RISCs these days; x86 sort-of has that with some looping instructions.

- accesses to multibyte data are aligned so they can't cross page boundaries

Does any RISC architecture other than SPARC have that restriction these days? (I had the impression ARM just ignored the low-order bits with multi-byte loads and stores, but somebody indicated that's not true in recent versions of the architecture.)

- load/store architectures; this keeps MMU exceptions and ALU exceptions from ever being generated by the same instruction.

Still applies to most if not all RISCs these days; does not apply to x86, even in 64-bit mode.

Re:RISC is not the silver bullet

[Guy Harris]

Gave it up? http://m.engadget.com/2010/09/06/ibm-claims-worlds-fastest-processor-with-5-2ghz-z196/

That's a CISC chip, by the way. (Memory-to-register arithmetic instructions, for example, although some of the more exotic instructions are implemented in a fashion similar to DEC Alpha's PALcode, wherein the instructions trap into a special processor mode with special non-architected instructions available, so the decimal fixed-point stuff and MVC/MVCL/TR/TRT/etc. stuff is sort of done in software.)

But, no, IBM didn't give up the Power architecture (or whatever you want to call the collection of architectures descended from POWER) either: http://arstechnica.com/gadgets/2009/09/ibms-8-core-power7-twice-the-muscle-half-the-transistors/.

However, neither of those are aimed at desktop/laptop machines, so IBM arguably did give up on doing processors for those machines. (In fact, after selling off the PC division to Lenovo and killing off the workstation side of RS/6000 and its successors, they arguably gave up on doing those machines, period.)

Also, porting has much more to do with APIs than instruction set.

In the example given by the person to whom you're responding, you're 10000% correct - it's not as if Apple switching to x86 suddenly made it easy to translate Windows applications to OS X applications (well, other than making the apps run "the lazy way" by running them atop Wine).

Re:RISC is not the silver bullet

[Guy Harris]

You've got a few of the points right, but my experience with a single-core Atom (recent Lenovo) versus a single core G4 (ancient G4 iBook) leads me to think Intel really only caught up with the PPC recently.

Atom isn't aimed at the laptop computer market. What Intel's selling for that market is, at least in the "compute pi with bc with scale=2000" benchmark, about 28 times faster than the G4 (it's quad-core, but, unless bc is multi-threaded, about all the other core might be doing is running Terminal as the digits of pi are being spit out, running Safari as it chews up CPU for already-loaded-but-still-open windows, etc.):

$ time bc -l <<EOF
> scale=2000
> a(1)*4
> EOF
3.141592653589793238462643383279502884197169399375105820974944592307\
81640628620899862803482534211706798214808651328230664709384460955058\
22317253594081284811174502841027019385211055596446229489549303819644\
28810975665933446128475648233786783165271201909145648566923460348610\
45432664821339360726024914127372458700660631558817488152092096282925\
40917153643678925903600113305305488204665213841469519415116094330572\
70365759591953092186117381932611793105118548074462379962749567351885\
75272489122793818301194912983367336244065664308602139494639522473719\
07021798609437027705392171762931767523846748184676694051320005681271\
45263560827785771342757789609173637178721468440901224953430146549585\
37105079227968925892354201995611212902196086403441815981362977477130\
99605187072113499999983729780499510597317328160963185950244594553469\
08302642522308253344685035261931188171010003137838752886587533208381\
42061717766914730359825349042875546873115956286388235378759375195778\
18577805321712268066130019278766111959092164201989380952572010654858\
63278865936153381827968230301952035301852968995773622599413891249721\
77528347913151557485724245415069595082953311686172785588907509838175\
46374649393192550604009277016711390098488240128583616035637076601047\
10181942955596198946767837449448255379774726847104047534646208046684\
25906949129331367702898915210475216205696602405803815019351125338243\
00355876402474964732639141992726042699227967823547816360093417216412\
19924586315030286182974555706749838505494588586926995690927210797509\
30295532116534498720275596023648066549911988183479775356636980742654\
25278625518184175746728909777727938000816470600161452491921732172147\
72350141441973568548161361157352552133475741849468438523323907394143\
33454776241686251898356948556209921922218427255025425688767179049460\
16534668049886272327917860857843838279679766814541009538837863609506\
80064225125205117392984896084128488626945604241965285022210661186306\
74427862203919494504712371378696095636437191728746776465757396241389\
086583264599581339047802759008

real 0m1.941s
user 0m1.936s
sys 0m0.003s

Re:RISC is not the silver bullet

[Guy Harris]

As to Linux: It is already dominant in the server space. The year of "Linux in the pocket" has been a while ago. On the desktop? That will come, as soon as MS customers realize that MS cannot innovate away from what works well. The ribbon, their desktop-unfriendly new window manager, etc., are all attempts to be different, even if it degrades usability.

I've heard that at least some free-software UN*X desktop environments are pretty competitive with Windows in the "different, even if it degrades usability" department, at least from some of the complaints heard here. :-)

Re:RISC is not the silver bullet

[Guy Harris]

IBM's POWER, DEC/Compaq's Alpha (later bought by Intel... I assume that Intel's internal x86 micro-ops take inspiration from Alpha), MIPS non-low power division, HP's PA-RISC, etc all bet that Itanium would be the next great thing

HP bet that Itanium would be the next great thing because it was originally their idea - they teamed up with Intel to make it. As far as I know, IBM never decided that Itanium was the future, although Compaq and SGI ("MIPS non-low power division") eventually did.

And your assumption is, I suspect, incorrect, given that Compaq sold the Alpha to Intel in 2001, and the first micro-op Intel processor, the Pentium Pro, came out in 1995. There's no reason to assume that Pentium Pro's uops took inspiration from Alpha rather than from some other RISC processor, or even, necessarily, that it took direct inspiration from any of them, given that they're an internal implementation detail rather than a user-available instruction set.

Re:RISC is not the silver bullet

[gagol]

Apple products with a mainframe.

Re:RISC is not the silver bullet

[Pseudonym]

1. Incorrect. The CPU does not do "code generation" in any way akin to compiler code generation, it just cracks instructions into typically 1-2 uops.

It also does a few register optimisations. Exactly which ones depends on the chip and the vendor, but for example, register-to-register moves are sometimes implemented as manipulations of the architectural-to-physical register mapping tables.

And even this is only true on current x86 implementations. We don't know exactly how Jazelle DBX works (ARM won't say), but some other JVM-on-top-of-RISC translators do optimisation on the translated code. There's quite a bit of research, for example, on code-optimisation-by-finite-state transducer which has been translated into silicon.

Re:RISC is not the silver bullet

[tolkienfan]

Nope. That was in your head. There isn't any way a rational person could read my comment as a comparison between Apple products and a mainframe.

Re:RISC is not the silver bullet

[gweihir]

I've heard that at least some free-software UN*X desktop environments are pretty competitive with Windows in the "different, even if it degrades usability" department, at least from some of the complaints heard here. :-)

Yes, sure. But you are free to ignore them and use Linux anyways. It is possible that most desktop-designers have some kind of problem, regardless of platform. My impression is that they want to design the "experience" for people and then force them to comply. The things going on with KDE and Gnome seem to be indications for that....

I just ignore them and use my, by now 20 years old fvwm configuration. The difference is that on Windows you do not get that choice. On Linux it is easy to make and has no negative impact I noticed so far.

GUI applications are a bit different. For example, the Emacs people get on my nerve no end with arrogance and stupidity in the newest versions, i.e. they do some things that make a real difference and you cannot turn them off. LibreOffice on the other hand is quite nice. I just hope they do not go for the ribbon ever. And commandline stuff is typically unproblematic, although there is the occasional stupidity as well, for example when GNU tar replaced the '-l' option for staying in the local filesystem by '--one-file-system', WTF? Fortunately these things are very, very rare.

Re:RISC is not the silver bullet

[Anonymous Coward]

Does this mean that if the compiled program only use the really simple RISC like instruction codes that don't require decoding then the atom will run as efficiently as an arm chip ? Can this actually be realized ?

Re:RISC is not the silver bullet

[Stuarticus]

I played all the way through skyward sword recently upscaled to 1080 on an i5 2500k and it was flawless...

Thanks

[Anonymous Coward]

Thanks for that quick history lesson in computer architecture.
BTW, intel processors haven't been CISC for years.
They're all RISC with a components that translates from the CISC instructions to RISC.

Re:Thanks

[stripes]

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)

Re:Thanks

[Anonymous Coward]

Yes. I consider all these words including RISC, CISC, VLIW, etc to be completely useless for today's processors.
They are only useful for a historical understanding for why things are done a certain way, and how the techniques were developed.
Any kind of serious commercial processor will combine elements from these different architectures.

BTW your argument that somehow intel processors are CISC because other processors use microcode as well doesn't make sense.
It just means that they are both not CISC.

Re:Thanks

[stripes]

That situation existed in the early 1990s/late 1980s when the terms CISC and RISC were invented. The x86 existed and was CISCy on the outside and microcoded inside. The VAX was the same. The arguments were never "you can't implement CISC internally the same as a RISC" because they were all already done that way. It was "if you avoid X, Y and Z in your programmer visible instruction set you don't need all that cruft in the chip". What makes something RISC or CISC was originally all about the instruction set, and I see nothing that has changed in the last 20 years that makes it useful to change the definitions.

Collapsing two useful words into one useless meaning doesn't add value to the language, it destroys it (well, not the whole language, just those two words). So why do it? If the new meanings actually had some value, sure I can see adopting new usage, but why switch to something worse?

Visual Studio is great, but what about MyCleanPC?

[CRCulver]

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

[kenorland]

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

[PCK]

Well there has never been a CISC-RISC instruction conversion from an Intel processor, AFAIK the AMD-K5 was the only processor to do so and the original Pentiums pretty much out performed them.

Out of order Intel processors since the Pentium Pro have converted instructios into very simple uOPs, in fact many RISC processors do the same thing.

Re:oversimplified

[aaron552]

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"

Re:oversimplified

[postbigbang]

I don't think you're trolling, just living in the early 2000s. If Intel doesn't release ATOM power settings, no big deal. Easily.Avoided. Atom 64-bit is still a few years away until practical implementations are made. Atom is their answer to a bridge between ARM and fat Xeons. As a design, it's a compromise, and is unlikely to live long.

That Intel doesn't release specs is a questionable assertion. That we care is also questionable. It's more of the Intel-Microsoft boogie-man propaganda meme that's rooted in some false premise. ARM is really good and graftable-- in low power apps in a 32-bit space. Currently, that's a sweet spot for entrant/basic computing devices. Intel (and to an extent, AMD) can't write a sufficient amount of basics that allow operating systems to use all the cores that they can slab into a socket, so virtualization has become the strength of multi-core devices, and there's plenty of current popularity in *that*.

Atom is fun, but isn't a big deal, and IMHO, won't be around very long. Getting one's feathers ruffled over it is nihilistic and distracts from other, deeper rivalries between F/OSS and Microsoft and Google's models.

Re:oversimplified

[postbigbang]

Let me correct: ARM 64-bit is still a few years away.

Re:oversimplified

[Anonymous Coward]

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

[stripes]

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

[gadzook33]

Ok oddly enough this I agree with.

Re:oversimplified

[gadzook33]

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

[RabidReindeer]

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

[Bert64]

Performance hasn't got a lot to do with it... Backwards compatibility is what matters, closely followed by price and availability.
While they were being actively developed and promoted, RISC architectures were beating x86 quite heavily on performance. However Intel had economies of scale on their side, they were able to sell millions of x86 chips and therefore outspend the RISC designers quite heavily.

Intel tried to move on from x86 too, with IA64... They failed, largely because of a lack of backwards compatibility...

Re:oversimplified

[Anonymous Coward]

Yep, Intel is offsetting design inefficiencies by having some of the most advanced production processes.

Intel is already pushing 22nm while the competition is still on 32 or even 45.

Re:oversimplified

[postbigbang]

I can't vouch for the GPU or hefty graphics card you're using, but you could do the same thing with lots of heft for under 150watts, including the freaking LCD monitor. There are a number of nice, high stroke CPUs out there that don't need a 500w supply.

Yes, Flight Simulator is a pig. But it seems to like AMD's math over AMDs, and in terms of graphics, I haven't kept up, so can't address that particular piece. Nonetheless, 500w can power a decent electric scooter.

Re:oversimplified

[lkcl]

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

[Anonymous Coward]

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.

This. Android's smartphone marketshare reminds me of Windows' desktop marketshare. Just because it's ubiquitous doesn't mean it's any good. Android is free/cheap, and "good enough." But jesus, do I cringe whenever I see someone on the bus scrolling through a list of contacts or panning/zooming on a webpage on their Android phone.

Re:oversimplified

[Anonymous Coward]

This half assed meme about CISC vs RISC and how the ARM is magically more efficient than stupid old x86 has to die. It's wrong and technically illiterate.

ARM has been hugely successful because THEY SELL DESIGNS. They sell them to system-on-a-chip designers who compete to make the best ones, and those are then built into products. The SOCs are low power, reliable and pack masses of features into one chip... and chinese manufacturers compete crank out products that use them as they don't really care about really high end performance.

It's great.. but it's not magic. Intel won't sell license their chip designs, and neither will AMD (partly through the contracts they have with Intel). So no-one gets the kind of flexbility and competition that's coming with ARM.

Good on the ARM guys for hitting mark... so Intel and AMD are competing by being every more hidden and controlling and getting further into bed with Microsoft and trusted computing (see UEFI).

Re:oversimplified

[RabidReindeer]

I can't vouch for the GPU or hefty graphics card you're using, but you could do the same thing with lots of heft for under 150watts, including the freaking LCD monitor. There are a number of nice, high stroke CPUs out there that don't need a 500w supply.

Yes, Flight Simulator is a pig. But it seems to like AMD's math over AMDs, and in terms of graphics, I haven't kept up, so can't address that particular piece. Nonetheless, 500w can power a decent electric scooter.

Forgive me. I haven't actually measured the true wattage. I don't have gamer hardware on this box - it's just a bog-standard small form-factor desktop with a mobo graphics card that's so crappy that I've been known to use Remote Desktop in from the Linux box just to preserve my eyes.

All I can say for certain is that it can make the office nice and toasty when I've already got my regular equipment running. Good for January. Not so good for July.

I'd probably do better making a VM out of it and running it on the Linux box, but one of the things that Linux is exactly the opposite of "terrible" for versus Windows is that I cannot just go throwing around Windows VM images around with wild abandon the way I can with Linux, BSD, OpenSolaris, etc. Windows has to be licensed and blessed by Redmond.

Re:oversimplified

[MindlessAutomata]

How is an iPhone better? Having used both an iPhone and iPad I was far from impressed. The thing I was mostly impressed about was that I had great difficulty trying to use it, because it takes awhile to figure you you actually can't do a lot of very basic computer operations as it's very dumbed down (file system access for one--what the hell?)

Re:oversimplified

[Zero__Kelvin]

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

Re:oversimplified

[kenorland]

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

[stripes]

Not just production process though. They do well in many other areas of research. The ALUs are mighty well designed. They have plenty of great work in many many areas. I really do hate the instruction set, and I'm not fond of the company, but they do really good work in so many areas.

I think if you gave them and IBM equal research budgets and aimed them at the same part of the market it would be hard to predict who would win. Any other two companies though, and the bet is clear.

Re:oversimplified

[postbigbang]

Let's say you have but one legally licensed copy of Windows. Do a P2V and then run it on VirtualBox. When doing the initial bring-up with Windows, just re-register it. Little fuss or muss. However, if you were doing luscious, GPU-enabled fast graphics, lower your expectations unless you're optimizing your Linux host and perhaps, using a better hypervisor than VP.

Then, with the saved money, go on eBay and get a nice FlightSim controller kit, and have at it. I used to enjoy flying a lot, and had lots of Flight Simulator stuff, then for a while, x-frame (which has an evolved ecosystem worthy of investigation).

Then, wild-abandon-time, on the cheap.

Re:oversimplified

[gadzook33]

You're right about embedded systems (not counting smartphones, I personally think android is sort of crappy). I guess I was sort of lumping headless systems like set top boxes in with servers (possibly unfairly). That being said, I spent years programming on Linux including both user land and kernel level stuff so you can take your righteous indignation to someone who cares.

Re:oversimplified

[Anonymous Coward]

I throw an XP VM across different servers all the time. Vista and Win 7 would be an issue though.

Re:oversimplified

[cheesybagel]

x86 is not the last bastion of CISC. Two of the world's much successful architectures are CISC based: x86 and S/360.

People seem to think it is impossible to make a low power or low transistor count CISC processor. However I still remember the Acorn computers with ARM processors with similar performance than a MC68020 coming in multi-chip packages. People are basically comparing a 386 or a 486 with a Pentium. Only recently have ARM added out-of-order processing which is something the Pentium Pro had nearly two decades ago.

Re:oversimplified

[Anonymous Coward]

Well, I'm not a follower of the field, but I recall this from Torvalds in 2003:

The x86 is a hell of a lot nicer than the ppc32, for example. On the
x86, you get good performance and you can ignore the design mistakes (ie
segmentation) by just basically turning them off.

On the ppc32, the MMU braindamage is not something you can ignore, you
have to write your OS for it and if you turn it off (ie enable soft-fill
on the ones that support it) you now have to have separate paths in the
OS for it.

And the baroque instruction encoding on the x86 is actually a _good_
thing: it's a rather dense encoding, which means that you win on icache.
It's a bit hard to decode, but who cares? Existing chips do well at
decoding, and thanks to the icache win they tend to perform better - and
they load faster too (which is important - you can make your CPU have
big caches, but _nothing_ saves you from the cold-cache costs).

The low register count isn't an issue when you code in any high-level
language, and it has actually forced x86 implementors to do a hell of a
lot better job than the competition when it comes to memory loads and
stores - which helps in general. While the RISC people were off trying
to optimize their compilers to generate loops that used all 32 registers
efficiently, the x86 implementors instead made the chip run fast on
varied loads and used tons of register renaming hardware (and looking at
_memory_ renaming too).

IA64 made all the mistakes anybody else did, and threw out all the good
parts of the x86 because people thought those parts were ugly. They
aren't ugly, they're the "charming oddity" that makes it do well. Look
at them the right way and you realize that a lot of the grottyness is
exactly _why_ the x86 works so well (yeah, and the fact that they are
everywhere ;).

but maybe things have changed since then

Re:oversimplified

[cheesybagel]

Servers, smartphones, and soon tablets.

Re:oversimplified

[Anonymous Coward]

So you're option three (not listed by OP), a dumbass.

Re:oversimplified

[kenorland]

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

[Bruce Perens]

Wasn't that when Linus was working for Transmeta? The x86-clone manufacturer that didn't make it?

I think he's mainly complaining about things other than the instruction set.

Re:oversimplified

[Bruce Perens]

Hi Kenorland,

I submit that the only reason we are seeing Intel processors as being close in either speed or power efficiency to other current architectures is because of the semiconductor process difference.

Intel is using smaller transistors than the CPUs they are being compared to. Sometimes much smaller - the transistor size is a square of the feature size of course, so what might seem half the size is actually 1/4.

Intel has its own, carefully optimized fab, while the other mobile manufacturers are buying the ARM architecture as software and using independent fabs for the most part.

So, Intel's competition with ARM in mobile is like running a doped horse in a race. Were we seeing all architectures on the same feature size, differences would be more apparent.

Re:oversimplified

[Bruce Perens]

Think of it: an S/360 mobile processor!

Re:oversimplified

[PCK]

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

[ServereNerd]

"Power management isn't magic, though - there is no great secret about shutting down hardware that isn't being used."

Powering down is the easy part, sometimes the power company does that for me. Bringing it back up is the hard part. Having an excellent software architecture for power savings will help, but not as much as you would hope.

SoCs are incredibly black-box when you power devices and/or the CPU down. You have nothing to help you -- especially logs -- until you bring it back up. Often, even JTAG cannot attach depending on how deep it went. There are fewer signals leaving the SoC, so there's less to probe. You'll find yourself desperately grasping for any sign of life. If you guess wrong too often, you might even fry portions of the chip.

If they provide no documentation, it's even harder. Bringing it back up is all-or-nothing and you're at the mercy of the configuration and register sequences you did. If you do it wrong, you might introduce the internal bus to APIC #2: Destroyer of Worlds.

Sorry to focus so much on a bummer. If the Atom really is %25 efficient as ARM while running, these power cycles are important to compete with Windows over battery life.

Re:oversimplified

[marcosdumay]

It's that (and code density is becomming less of an issue as processors start to simply compress their code)... It's also about general porpouse vs. specialized registers, and big cache vs. plenty of registers (a big performance vs. power tradeoff), and less coupled modules that can be powered (and clocked) off, and a miriad of details that people didn't care about at the 70's but ARM took into account.

Re:oversimplified

[Carewolf]

Let me correct: ARM 64-bit is still a few years away.

Away from what, your pocket? Sure, there is not yet a need for tablets with 4Gbyte of memory. But ARM 64-bit is not some far away dream, it just doesn't make much sense yet.

Re:oversimplified

[ghettoimp]

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.

I don't understand this reasoning.

If the backend can't keep up with the decode rate, say because

• each CISC instruction is turning into a few RISC-equivalent micro-instructions, and
• CISC instructions have an edge w.r.t. memory density, so you can keep more of them in the icache and have fewer stalls waiting for the next instruction to come from RAM.

Then aren't you winning?

• You aren't stalled out trying to figure out what to do next.
• Your execution units are busy doing productive work.
• You can turn off the frontend fetch/decode stuff to save some power.

Obviously there has to be some balance. An anemic backend with an overpowered frontend will slow you down. But if the backend is reasonably powerful, it seems like you want to have it working as fast as it can, rather than idly waiting for the frontend to tell it what to do next.

Re:oversimplified

[Anonymous Coward]

I moved from an iPhone to a significantly more powerful Android phone, and while it has its advantages, the user interface definitely feels slower. Like the grand parent said, it's really noticeable when scrolling lists/webpages or when zooming.

Re:oversimplified

[Anonymous Coward]

This may come as a surprise to you, but there are a lot of very smart people that think Linux sucks. For example, a lot of the FreeBSD, OpenBSD and Solaris developers think Linux is garbage, and a lot of the older Unix gurus that are now working at Google aren't terribly fond of it either.

Re:oversimplified

[Anonymous Coward]

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

[Olorion]

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

[Anonymous Coward]

Indeed. Once upon a time, VLIW (Very Long Instruction Word) processors were tooted as being "the next generation of general purpose processors". There were some interesting implementations, such as the Wave Tracer super computer, but they just were not enough better than current RISC and CISC processors to take over the world. In truth, most so-called RISC chips, such as ARM, MIPS, et al are a mix of RISC and CISC instructions. I call them MISC (Mixed Instruction Set Computer) chips... :-)

Re:oversimplified

[Compaqt]

Oh, ARM is 32-bit? That's interesting.

We've been moving pretty fast to 1GB memory, and I'm sure the pace is only going to increase. We'll be at 2, and then 4GB in no time.

Which would bring up possible need for a 64-bit mobile chip.

Re:oversimplified

[postbigbang]

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

Re:oversimplified

[postbigbang]

As otherwise noted, perhaps the chip will emerge when the need is demonstrated. Oh, wait, there really is nothing like a 64-bit 6502. Much work would need to be done to change the math, the memory vectors, timing, bus bandwidth and various timings, ad infinitum. Oh, might be more like Atom then? I wonder. The loveliness of the ARM family is that it's easily modified and graftable with other functionalities/features. Will a 64-bit version have the same nearly pluggable ease? We'll get to see, I'm guessing, soon enough.

Re:oversimplified

[Nivag064]

PostgreSQL (http://www.postgresql.org) runs on Microsoft as well as Linux, and (AFAICT) outperforms SQL Server. However, any serious server stuff runs on Linux.

I run Linux at home for both desktop & server stuff - I am a developer.

Re:oversimplified

[Anonymous Coward]

When x86 was designed, things like caches and page tables didn't exist; they got tacked on later.

And that is different from the ARM instruction set how? ARM isn't really a much "younger" architecture than x86.

As an aside, an argument can be made that certain aspects of ARM place more severe burdens on modern OoO CPU implementations than do the various x86 quirks. For instance, performant implementations of ARM conditional execution typically require either predicting conditionals (akin to branch prediction), or all conditional operations reading three source registers (src1, src2, and old value of dest) rather than two. That is additional energy per op, for not much of a perf gain on average.

Re:oversimplified

[Daniel Phillips]

IA32 today is little more than an encoding for a sequence of RISC instructions, and the decoder takes up very little silicon.

Stated without proof. The decoder is per-core, so you can't immediately see the amount of real estate it takes up. To avoid decoding the same instructions multiple times Intel has the complex "loop stream detector" logic. I'm sure that's not the end of it, somebody whose business this is might comment. And besides the real estate this logic consumes (which on ARM would instead be devoted to more cores) this all eats energy. I doubt this in itself accounts for the power efficiency multiple Bruce claims, and I wonder where he got his numbers. But it certainly counts for something.

Anyway, power efficiency is far from Intel's biggest problem with ARM. The real issue is price. Intel just can't afford to sell power efficient processors at the price ARMS cost, that work well enough to compete with its big server and desktop iron. One word: margins.

Re:oversimplified

[kenorland]

I think that's a simplistic view of looking at it. Architectures, production facilities, pricing, and applications are deeply intertwined and interdependent. Although putting ARM chips on cutting edge processes would give you better ARM chips, it would probably not be economically efficient overall. In the end, I really don't care. Either Intel will figure out how to make efficient, cost-competitive x86-based chips or they won't; I think it makes little difference to users.

Re:oversimplified

[kenorland]

Well, x86 has pretty much destroyed the RISC market on the desktop, for workstations, and for supercomputers. The last big attempt at RISC, IA64, was a failure. If you want to argue that x86 has some enormous overhead due to its instruction set, I think the burden of proof is on you.

I think instruction sets matter little, and the fact that we have x86 on the desktop and ARM on mobile devices is an accident of history. Either architecture could evolve to fill the other's niche. Intel seems to think so too. If you disagree, where is your proof?

Re:oversimplified

[MindlessAutomata]

I agree, but Jelly Bean is largely cleaning this up. The difference still isn't worth the cost or the crippled functionality of the iDevices.

Re:oversimplified

[Anonymous Coward]

Tut tut. "64K is enough" is Steve Jobs statement and the great artist from Redmond stole it!

Re:oversimplified

[Daniel Phillips]

I think instruction sets matter little...

Speaking of burden of proof, ARM is considerably more power efficient than any x86. Rhetoric doesn't change that.

Re:oversimplified

[Bruce Perens]

I can't say that I have much sympathy for the folks who would buy that platform, but in the end I think what matters most to them is that there is not going to be anything like CyanogenMod for it, because the IPR terms of the whole platform aren't compatible with that. Users are starting to realize the value of a non-manufacturer upgrade path.

Re:oversimplified

[Anonymous Coward]

Wasn't that when Linus was working for Transmeta?

yes, it was.

The x86-clone manufacturer that didn't make it?

and..?

I think he's mainly complaining about things other than the instruction set.

did you even read that? the x86 instruction set is a dense encoding, so it loads faster and you get fewer icache misses than with a RISC instruction set.

Re:oversimplified

[Bengie]

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.

You want programmers to deal with TLB flushes and cache flushes and other low level things that require knowing how the CPU arch works? You must know a lot of good programmers, because I bet 90% of "programmers" think computers are magic.

I'm not sure I want a program to have the ability to flush caches to adversely affect the rest of the system. Not every instruction needs to be checked, only memory related instructions.

I would like to see a discussion about the pro-and-cons of what you said.

Re:oversimplified

[Bengie]

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

Don't worry, the new Atom CPU coming out next year is 750mw(Max draw, including 3D graphics) and about 20%-100% faster than current ARM CPUs, and only a 20mw idle.

That's on a 22nm. 14nm will be coming out the year after. Enjoy.

Forgot to add. Intel's new research into low power usage for phones/tablets has also leaked into their desktop chips. Intel is claiming about a 20x reduction in average office workload power draw. Over a magnitude power savings in one generation while keeping the same performance.

Re:oversimplified

[Snorbert Xangox]

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

The funny thing being that the complainer apparently wanted to spend their life writing assembly code. :-)

It's like big-endian versus little-endian memory organisation: on the one hand, you have a data format that makes it a bit easier to read raw hex dumps of main memory, but does your head in whenever you want actually write something useful (like, picking out the nth significant byte from a multibyte data type), while little-endian looks ugly on paper, but makes writing code to do multiple precision stuff simpler - the bit with significance 2^n is in the byte at [baseaddr + (n>>3)], no matter *what* length the full data type is... and the debugger will helpfully display that ugly little-endian piece of memory properly for you should you need to see it.

Re:oversimplified

[kenorland]

Speaking of burden of proof, ARM is considerably more power efficient than any x86. Rhetoric doesn't change that.

Current ARM chips are more power efficient than current x86 chips. The question is whether that's an intrinsic property of the instruction set and whether it holds true at the whole system level (rather than instruction by instruction). I think you haven't made your case.

Re:oversimplified

[kenorland]

I'm not sure I get that. Why would x86 based mobile devices be less open than ARM-based ones? Seems to me that as far as Microsoft's products are concerned, it's the x86-based ones that are less restrictive. And much as I like CyanogenMod, I doubt it has much influence on the market place: it is such a pain and so risky to install on many devices. We need to address the issue of the disappearance of programmable general purpose computers, but that issue won't be addressed by ARM-vs-Intel. Ultimately, I think it needs to be addressed legally via anti-trust law.

Re:oversimplified

[Bruce Perens]

Why would x86 based mobile devices be less open than ARM-based ones?

Because the manufacturers are only marketing them for Microsoft platforms. MS isn't going to allow anything like CyanogenMod.

Re:oversimplified

[Mr_DW]

Wasn't that when Linus was working for Transmeta? The x86-clone manufacturer that didn't make it?

Wow! A personal attack on him. That's your reply?. I thought better of you. And in case you think it's not... http://en.wikipedia.org/wiki/Character_assassination and http://en.wikipedia.org/wiki/Ad_hominem YES implying Linus only said something because he was paid by Transmeta is a personal attack which you used to deflect the question being presented to you.

Re:oversimplified

[Bruce Perens]

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.

Re:oversimplified

[Daniel Phillips]

If you go back and read, the case I was making is that Intel's real problem is, it can't afford to drop the price of its chips to ARM levels because that will eviscerate its lucrative margins.

Re:oversimplified

[kenorland]

I don't get it. If you look at Surface, third party operating systems are allowed on x86 but not on ARM. And for Android, CyanogenMod isn't "allowed" by most manufacturers either: no device is designed to facilitate installation of other operating systems, most take active steps to make it hard, and pretty much all of them void your warranty and can be bricked that way. There is a big problem there, but I don't see it as being related to x86 vs ARM.

Re:oversimplified

[kenorland]

I don't see what choice Intel has. A large chunk of the server and desktop market cares less and less about instruction sets, so they are in competition with ARM whether they want it or not. If they manage to bring power efficient and cheap x86 chips to market quickly, they have a slight competitive advantage while people still care a little about instruction sets. If they don't, then they may continue to make a bit more money on x86 for a while but lose to ARM (and other processors) in the long run. Either way, it seems like a pretty straightforward business problem, not some deep rooted technical issue.

Re:oversimplified

[shiftless]

I agree, and the fact this was modded Troll is laughable. Android is a slow buggy piece of shit. Java is a piece of shit, and a horrible idea. Anyone who disagrees obviously never used computers back in the 80s and early-mid 90s, when they weren't complete shit. Today, on a quad core Phenom II w/ 16 gigs of RAM, I can't even click double to full screen a Youtube video without the fucking thing skipping. When I unplug my phone from its charger, there is a full 10 seconds where it's damn near unusable while the phone mounts the SD card etc. Hell, it's laggy just in normal use; and this is with an *overclocked* aftermarket ROM! This is unacceptable.

Re:oversimplified

[Bruce Perens]

The main reason that CyanogenMod can work on Android is that the kernel is under GPL and so is the Android platform (though of course not most of the applications). So, the developers get to start with a working system despite what the manufacturers want. This is not the case with a Windows platform.

Re:oversimplified

[Anonymous Coward]

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

That's in no way empirical. How much GPU rendering was the ARM system using? What other processes were running on the Atom machine? How was "clearly keeping up" measured in a non-subjective manner?

Did they then set both machines to trans-coding a video? No? I wonder why not, it's a common use-case nowadays.

Re:oversimplified

[Anonymous Coward]

Actually, IA64 is not RISC... it is VLIW, as you can see here:
http://en.wikipedia.org/wiki/Very_long_instruction_word

Re:oversimplified

[Ash-Fox]

PostgreSQL (http://www.postgresql.org) runs on Microsoft as well as Linux, and (AFAICT) outperforms SQL Server.

In what way does it outperform SQL Server?

Re:oversimplified

[kenorland]

Right, but what does that have to do with ARM vs x86? An x86-based mobile phone running Android will be no worse in that regard than an ARM-based mobile phone running Android. And both Windows and Linux run on both ARM and x86.

Re:oversimplified

[Bruce Perens]

Kernel programmers, not user-mode ones. I agree that most programmers could not describe how the print command actually gets the printer to do something physical. But kernel programmers are a different breed.

Re:oversimplified

[Anonymous Coward]

> now, as we well know, power consumption is a square law of the clock rate

Power consumption does not scale with the square of the clock rate. Dynamic power scales linearly with frequency and with the square of the voltage. Now in practice, in order to run at a higher frequency you may need to increase the voltage on your circuit, but what you wrote is not correct.

Re:oversimplified

[Guy Harris]

Away from what, your pocket? Sure, there is not yet a need for tablets with 4Gbyte of memory. But ARM 64-bit is not some far away dream, it just doesn't make much sense yet.

...in your pocket. ARM 64-bit might also be intended for servers (e.g., "low power means lower heat means you can stuff more processors into the same space in the machine room").

Re:oversimplified

[Guy Harris]

As otherwise noted, perhaps the chip will emerge when the need is demonstrated.

Well, according to the slide show, silicon will be available for the X-Gene in "2H. 2012", so maybe they're already shipping.

They're pushing it as a server processor, though, rather than a mobile processor.

The loveliness of the ARM family is that it's easily modified and graftable with other functionalities/features. Will a 64-bit version have the same nearly pluggable ease? We'll get to see, I'm guessing, soon enough.

"The loveliness of the ARM family" as described there is less a function of the instruction set and more a function of the CPU core being offered as an "intellectual property block" to stick onto a system-on-a-chip; I see no reason why it'd be any harder to do that with a 64-bit processor.

Re:oversimplified

[postbigbang]

Hmmmm. Then why hasn't it been done? Power consumption, mostly. Ease of supply chain. More easily grafted support chips than Intel/AMD family chips in current ARM architectures. There is no data on how much power a 64-bit CPU will pull, but I'll look around and see if someone's studied that.

AppliedMicro is a foundry, and it does indeed seem to have a v8 64-bit chip-- at least a prototype. I'm checking to see if it's shipping, and if so, who the customers are.

Re:oversimplified

[Guy Harris]

Hmmmm. Then why hasn't it been done?

What does "it" mean here? Offering a 64-bit core as an embeddable block, or offering a 64-bit ARM core as an embeddable block?

If the former, perhaps most 64-bit processors aren't interesting to people building systems-on-a-chip, especially given that many of them are developed solely for the developers' own systems or maybe a few others (POWERn and z/Architecture processors are developed only for IBM's use or maybe a couple of other vendors if they let them use POWERn; the same applies for SPARCv9 and Sun^WOracle and Fujitsu) and even those that aren't are aimed at stuff a bit bigger (x86 except maybe for Atom, IA-64). MIPS appear to be the only ones offering 64-bit processors that might be available as embeddable blocks, but their Web site seems to mostly talk about the 32-bit cores.

If the latter, perhaps, err, umm, 64-bit ARM processors are just now beginning to arrive.

Re:oversimplified

[postbigbang]

A bit of digging says that there 64-bit ARM CPUs out there. I don't know if they're available in quantity, or how they're sold. I looked for applications using them, and there are LAMP stacks, but nothing that appears "optimized" for the foundation.

No one seems to know about power consumption, except that there's L1-3 support onboard on two of them, and beyond that, I'm still fishing for information. Why? Because it's there.

Re:oversimplified

[Guy Harris]

A bit of digging says that there 64-bit ARM CPUs out there. I don't know if they're available in quantity, or how they're sold. I looked for applications using them, and there are LAMP stacks,

...i.e., server stuff, so there's probably not much interest in embeddable cores for systems-on-a-chip right now.

Re:oversimplified

[Nivag064]

Seems difficult to get up to date meanigful performance comparisons, probably because Microsoft's licence forbids it unless they approve!

As to which is better... it depends!

I strongly suspect that given a fixed budget and starting from scratch buying new hardware: one wouild get more transactions per second using PostgreSQL & Linux over SQL Server & Microsoft O/S. Howver, I suspect that on the same hardware, PostgreSQL would be faster as then you can use Linux whereas SQL Server is limited to a Microsoft O/S.

Ten Reasons PostgreSQL is Better Than SQL Server:
http://facility9.com/2011/12/ten-reasons-postgresql-is-better-than-sql-server/
[...]
        Jeremiah Peschka,
        Wed Dec 14, 2011 at 7:19 am

        Two other quick bits of info around PostgreSQL and scalability. You can see some of the current benchmarks here: Scalability, in Graphical Form, Analyzed. As far as other scalable companies using PostgreSQL – Instagram have recently published how they scale with PostgreSQL.

        TL;DR version: Benchmarks show PostgreSQL 9.1 scaling up to around 45,000 transactions per second with 9.2s code base edging past the 200,000 TPS mark. ...

David,
Wed Apr 11, 2012 at 10:07 pm

completely changed my perspective on postgre, I always thought it was junk. Any leads on a VM to fool around with ?
[...]

http://rhaas.blogspot.co.nz/2010/12/postgresql-performance-vs-microsoft-sql.html
[...]
Grant JohnsonDecember 21, 2010 11:43 AM

Over many years of using both, here is what I have found:

For applications with plenty of hardware and few users, the two are very comparable for performance. As concurrency grows, PostgreSQL seems to handle it better, likely due to its MVCC model using disk in the existing data files. However, if the data file run out of room, it can be slower expanding used storage than SQL server. Keep your free space maps big enough, and your vacuums frequent enough to deal with it, and it is great.

The other time when it really seems to shine is when starved for hardware. PostgreSQL seems to deal much better with all of the CPU's being at 100% and swap going like mad trying to keep up. Remember also that I have always used PostgreSQL on Linux or BSD, so some of this may be how the operating systems handle different loads.
[...]

Re:oversimplified

[postbigbang]

So far, yes. But when will the need for grafted cores into a 64bit memory model and computational strength start? In the early 2000s, everyone thought: 32 bit is great! Look how fast it goes! Now you can't find a 32-bit server except as VM.

Re:oversimplified

[Altrag]

Windows equivalents of the databases, software development and text-processing tools that come free with Linux

Most, if not all, of which are available for Windows as well (though many of the dev and text tools might require cygwin or similar.)

I'm certainly not going to tell you to dislike or stop using Linux if its fulfilling your needs, but claiming Linux has a more accessible software suite is.. a little silly. There are very very few major projects, open or closed, that don't have a Windows port. Even free software tends to go where the users are.

Of course if you just like to run a whole lot of experimental or largely-unknown software then you might be on to something.. but nothing you've listed suggests that you're looking for that.

Re:oversimplified

[Phantom Gremlin]

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.

You have mis-remembered the power consumption rules. It's directly proportional to clock rate. It's a square law with respect to voltage. That's why Intel takes great pains to constantly vary the voltage of its chips as they operate. C.f. this Wikipedia article: http://en.wikipedia.org/wiki/Dynamic_voltage_scaling

Of course, there are a whole lot of details beyond the simplistic formula of v-squared times f. E.g., until recently, the "leakage currents" (i.e. power drawn even at zero clock rate) were getting worse and worse (as a percentage of total power). That's why when Intel announced Ivy Bridge it was a big deal. Their tri-gate transistors are much better in terms of leakage: http://en.wikipedia.org/wiki/Multigate_device#Tri-gate_transistors

Re:oversimplified

[aaron552]

Obviously you're doing it wrong, because I never experience what you're describing on much more modest hardware. Youtube videos "skip" when I switch to fullscreen if they switch resolution (eg. from 360p to 1080p) but otherwise the transition is smooth on my Core 2 Duo at 2.33GHz with 2GB of RAM. My Android phone (running an aftermarket Jelly Bean ROM, not overclocked) never has any of the issues you describe, the SD card mounts once at boot and then never unmounts, even when connected to the PC, not is it anywhere near laggy in normal use, and it's noticeably smoother when heavily loaded than an iPhone 3GS, 4 and possibly the 4S.

Re:oversimplified

[postbigbang]

Further research says: sampling quantities only. Nothing in real production until perhaps next year. No one's talking grafts yet, and no one knows the outcome. Only proof of concept hardware is out there, and it's so far, not really testable.

Re:oversimplified

[Anonymous Coward]

AMD has a VLIW architecture to draw on in the form of the Radeon execution units. I anticipate them integrating these further into the CPU design over the next few product cycles. I expect most of the SSE instructions will be internally converted to these, saving die space in the FPU.

Re:oversimplified

[Bert64]

For many years a high priced RISC chip would easily beat any x86 chip on the market...
In its day, the Alpha was able to emulate x86 code faster than any real x86 chip available at the time. Even after they stopped developing it, the Alpha was able to outperform x86 comfortably for floating point code.

For instance, see specfp2000 results at:
http://www.pvcmuseum.com/cpu/specint-and-specfp-processor-benchmarks.htm

1.25GHz Alpha 21264C = 1365
3.4GHz Pentium 4 Northwood = 1308

1.25ghz Alpha, beating an x86 chip with almost 3 times higher clock rate and 3 years newer...
The P4 3.4ghz was released feb 2, 2004...
The 1.25GHz 21264C came out in 2001.

http://en.wikipedia.org/wiki/Pentium_4#Northwood
http://en.wikipedia.org/wiki/DEC_Alpha#Model_history

All the chips with higher benchmark results than the alpha are considerably newer...

Had they had the same economies of scale and thus development budget behind them, those chips would still be heaving outclassing x86 even today.

Re:oversimplified

[kenorland]

For many years a high priced RISC chip would easily beat any x86 chip on the market...

But what matters is bang for the buck, not bang. And, as you may notice, the difference was primarily in FP performance, which mainly depends on the FPU and where Intel probably just made a conscious choice to sacrifice some performance in order to keep cost down.

All the chips with higher benchmark results than the alpha are considerably newer...

The alpha was a chip designed to do well on benchmarks. But it did so only really with proprietary compilers for a long time, which meant you had to use shitty proprietary operating systems, and even with all that, all you got was slightly higher performance at a much higher price.

Re:oversimplified

[Bert64]

The price difference was largely down to economies of scale and competition in the x86 market, Alpha pretty much had only one supplier and was low volume...

Alpha was faster at integer code too, but the difference for floating point was far larger.

The Alpha could run Tru64, VMS, Linux and various BSD versions It even ran a version of windows at one point... Sure there was a proprietary compiler which produced faster code than gcc, but the same is true on x86 and other platforms too.

Re:oversimplified

[kenorland]

The price difference was largely down to economies of scale and competition in the x86 market, Alpha pretty much had only one supplier and was low volume...

Or maybe it was because the Alpha chip was just badly designed. We don't know because nobody can do a controlled experiment.

Alpha was faster at integer code too, but the difference for floating point was far larger.

The difference on integer code was small, and even on floating point, it wasn't really worth the hassle. And that's only if you actually managed to get the performance out of the chip that they got for benchmarks, and most of the time you didn't.

Wow

[Anonymous Coward]

Author, a well-known Linux fanboy, has butthurt because Intel won't share their toys with his favorite operating system in the whole world. News at eleven.

Re:The Year of Linux on Desktop Is Now

[Goodyob]

I wish I could agree with you, but from what I can tell, Gaben has stalled developing the Linux port in favor of making hardware.

Windows developers

[sunderland56]

The details of Clover Trail's power management won't be disclosed to Linux developers.

So sign up as a Windows developer, get the info, and use it to improve Linux.

Re:Windows developers

[Alex Belits]

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

Re:Windows developers

[Guy Harris]

The details of Clover Trail's power management won't be disclosed to Linux developers.

So sign up as a Windows developer, get the info, and use it to improve Linux.

...and perhaps get sued for violating a non-disclosure agreement you signed in order to get the info.

Short term vs Long term thinking

[UnknowingFool]

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.

Re:Short term vs Long term thinking

[Anonymous Coward]

That isn't the issue.

He issue is that Intel isn't providing the drivers or even the documentation so that Linux CAN support these features.

Re:Short term vs Long term thinking

[UnknowingFool]

It's a matter of resources. Can Intel provide the drivers or documentation? Yes. But it takes people. It takes planning. As of now, they would rather focus their efforts on Windows 8. I think that's a mistake on their part.

Re:Short term vs Long term thinking

[0123456]

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.

Re:Short term vs Long term thinking

[UnknowingFool]

And you know it's two people for a few weeks, how? Let's take documentation: How many engineers does it take to write/review the documentation? Are all insider and trade secret information scrubbed from external documentation. Does it have to go through legal? What license should the information be under? Does legal have to sign off on the license too? That's a dozen people right there just to release documentation.

Then writing drivers. A few people to write. A few people to test. Then iterate until it works. Then going through the whole bureaucracy. All while their release isn't going to be Linux anyways. Is this going to jeopardize the Windows release? [sarcasm]But companies like Intel can just throw people at every thing that doesn't make them any money.[/sarcasm]

Just because you can do the a small part work as a coder does not mean you know the larger effort it takes a company to do something.

Re:Short term vs Long term thinking

[udippel]

I take it you are what your name says: unknowing. Nevermind. I see where you are coming from (and where you are headed). It is true that what you write would be correct if it was correct. But nobody asks to write drivers. It is only very normal procedure to write documentation on the power shutdowns. Documentation that is needed and will probably asked for by the Windows coders. And documentation that the Microsoft lawyers will want to make sure it exists; they can't afford to have Windows running on verbal information on the features of these CPUs fresh from a drink at the pub. And if this contains third party intellectual property, they can't pass it on to MS neither.

But now, what would happen if Intel came out with an Atom that ran on a significantly reduced power? Yes, it maybe able to make it through as many hours as an ARM-based device. And what if that Atom-based device had Linux support? It would see Android running on it with possibly faster response times. Or the normal x86 of Debian (that is ABCbuntu). Imagine an Atom the size of a BeagleBoard, or Pandaboard. The latter two need no cooling. And, as everyone knows by now, Dick, Tom and Harry have largely accepted Android the interface. The result would be a sales bump up. But not necessarily for Windows (only).

Re:Short term vs Long term thinking

[UnknowingFool]

So are you saying Intel has teams of people sitting around doing nothing or do you think as a company Intel has people allocated to projects? Like getting this new chip ready for release in the next few months. But you'd rather add to everyone's workload even though it's not the company's strategy at the moment. And if right after the Windows 8 release (when people have time), Intel releases the information for Linux, what would you say then? I think Intel should focus more on Linux. But it's Intel's choice not do so.

Re:Short term vs Long term thinking

[shiftless]

And you know it's two people for a few weeks, how?

He has a brain.

Just because you can do the a small part work as a coder does not mean you know the larger effort it takes a company to do something.

Look in the mirror.

Re:Short term vs Long term thinking

[Lisias]

Just because you can do the a small part work as a coder does not mean you know the larger effort it takes a company to do something.

Look in the mirror.

I would suggest you to get a job on a big company instead.

HTML Media Capture is not widely supported

[tepples]

The world's most popular applications run in browsers, not desktops.

So if I want to include microphone, camera, or gamepad support in something that I intend to become one of "[t]he world's most popular applications", what API should I use? Among desktop browsers, neither IE nor Firefox nor Safari supports HTML Media Capture, and nothing mobile supports it at all.

Re:HTML Media Capture is not widely supported

[Anonymous Coward]

http://dev.w3.org/2011/webrtc/editor/getusermedia.html
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html

Those API's

Re:HTML Media Capture is not widely supported

[Anonymous Coward]

It is coming, hold on to your butt.

Hardware API is also on its way too. It is so far working with controllers last I checked.
File API is, I don't know actually, I haven't checked it forever.

Media Capture

Re:HTML Media Capture is not widely supported

[Anonymous Coward]

flash.

Re:HTML Media Capture is not widely supported

[sgunhouse]

Opera Mobile supports video and camera via getUserMedia (mentioned in another reply, I see) ... no idea of gamepad support though, as it's still pretty rare on phones and tablets.

Sorry Bruce, but that is total nonsense.

[guidryp]

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

[CajunArson]

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

Re:Sorry Bruce, but that is total nonsense.

[recoiledsnake]

Thanks for posting that. The article felt nothing like a hit piece against all things Intel and AMD just because they're not officially supporting one processor on Linux at the time of release. Intel is very good at releasing Linux drivers for their GPUs etc. compared to others. I think they figure that too many Linux folks won't be falling over themselves buying Windows 8 touch tablets and running Ubuntu on them. The Slashdot consensus seems to be that Windows 8 tablets suck and will be a massive failure, so why even bother at this point about Clover Trail?

From TFA:

>AMD's "Hondo" processor is being marketed as "Windows Only" too. Microsoft must be paying both manufacturers a lot for this

I don't think Microsoft really cares about the 1% Linux PC market enough to spend any money on exclusivity. They know hobbyists will add support regardless and I don't think they care one bit. Their real target is the iPad here, whether their strategy succeeds or not is a different issue, but this sure feels like a sour grapes hit piece written for the Slashdot audience.

Re:Sorry Bruce, but that is total nonsense.

[Truekaiser]

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.

[pissoncutler]

Thank you for adding some facts to this Intel-bash-fest. The CloverTrail processor was designed with Microsoft specifically for Windows 8. That's like saying that if Logitech makes a left-handed trackball, they are anti right hand.

Intel isn't anti-Linux. Intel has been one of the biggest contributors to Linux for the past decade.

"The top 10 organizations sponsoring Linux kernel development since the last report (or Linux kernel 2.6.36) are Red Hat, Intel, Novell, IBM, Texas Instruments, Broadcom, Nokia" ref: http://www.linuxfoundation.org/news-media/announcements/2012/04/linux-foundation-releases-annual-linux-development-report

Re:Sorry Bruce, but that is total nonsense.

[kent.dickey]

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.

[Anonymous Coward]

Actually, ARM doesn't make the masks - those are intimately tied to the specific ASIC being built. ARM provides the HDL that defines the CPU (all the registers, interactions, clocking, ALU, etc), with defined interfaces to the CPU "block". The companies using their product add this in to the HDL that defines the rest of the ASIC (On-chip peripherals, buses, I/O, clocks, etc), then sends it out for masks to be built.

And, yes, I'm quite aware of how chips are made.

Re:Sorry Bruce, but that is total nonsense.

[KonoWatakushi]

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.

The end result may come within 10% for optimized code, but at what expense? As a user, you may not appreciate the extra burden placed on hardware and software engineers alike, but it has significant consequences on the rate and cost of development, for everyone involved. Look at x86, as contrasted with the rapid progress on a clean architecture like the Alpha, and this point becomes abundantly clear. With ARM as well, Intel has had to expend massive resources, and even with their advanced process technology, they are having great difficulty competing with much smaller firms.

Where would we be today, if the Alpha hadn't been euthanized by incompetent management at Compaq, or ARM and other RISC competitors could compete on an even process with Intel? Thankfully, as time goes by, x86 compatibility is decreasingly important. Open source linux, bsd, and mobile development are largely processor agnostic, and are free to use better architectures.

You appeal to CPU designers, but how many of them wouldn't rather be working on anything but an x86 design? That feeling is also shared by most assembly and systems programmers, I promise you. Any opportunity to remove a convoluted and unnecessary layer of abstraction from a system is a good thing, and should be welcomed.

Re:Sorry Bruce, but that is total nonsense.

[Kjella]

So exactly this. Intel released a Windows-only chip and now Bruce threw a temper tantrum and dug up every pathetic reason you could find this chip must be a total and utter failure. By the sound of it you should think they've released the PIV or the Itanic all over again, from everything I can tell this is a rather standard evolutionary development. It got some power hints that they're working on with Windows, but you know Intel wants the market ARM has today. Maybe this chip is Win-only yes like Google wanted Android 3.0 to only be for tablets but long term, Intel wants to power Microsoft and Apple and Google.

Re:Sorry Bruce, but that is total nonsense.

[symbolset]

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.

Re:Sorry Bruce, but that is total nonsense.

[symbolset]

For a processor vendor to do this is a dangerous step.

Re:Sorry Bruce, but that is total nonsense.

[Type44Q]

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.

Bingo.

Re:Sorry Bruce, but that is total nonsense.

[udippel]

I don't think Microsoft really cares about the 1% Linux PC market enough to spend any money on exclusivity

Hmm. In what year are you living? I for one live in 2012 these days, and the PC has long been abandoned as target. Look at smartphones and tablets, and it rather is Microsoft hoovering around the one-digit market share. Therefore, and without saying that I am convinced that they do, they surely would have a very good reason to even pay Intel each day that the Linux kernel can't take the same economics that Windows does.

Re:Sorry Bruce, but that is total nonsense.

[Anonymous Coward]

I've a feeling that a lot of what makes the difference is the way that x86 chips are running noticeable faster than their memory compared to ARM. Suddenly it's all about highly complex scoreboarding, register renaming and branch prediction to mitigate cache misses, much more so than with ARM CPUs, and that sort of thing all adds transistors.

Re:Sorry Bruce, but that is total nonsense.

[Anonymous Coward]

It's competitive with ARM if produced on a superior fab process though. And at this power envelope, it's still having trouble keeping up with the A9 in performance-per-clock, forget about the A15:

Phoronix

(Note the clockspeed advantage)

Re:Sorry Bruce, but that is total nonsense.

[ocularsinister]

I don't think Intel is being anti-Linux. They are very linux friendly for the most part. I think they know this chip is a bit of a dud and would rather focus on bringing Valley View up to speed. That chip no longer relies on the PowerVR for video so a full, properly supported, open source Linux stack is possible. I get the impression that this chip is being dumped on the market because they need something out there to compete with ARM and to piggy back the Windows 8 tablet releases while the one to watch is Valley View.

x86 to blame?

[leromarinvit]

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.

Re:x86 to blame?

[Anonymous Coward]

The decoder logic becomes a larger part of the equation when you move less powerful but more power efficient cores.

For an android phone the display and the radios tend to dominate power consumption, because the cpus are generally efficient
enough to not be in the way.

As for x86 vs ARM. For all of the years Intel worked to make x86 processors the fastest on the planet. Arm worked to make processors the most power efficient and embeddable processors on the planet. ARM's generally have most of their supporting circuitry on die. While Atom continues to need more support chips. More chips generally equals more power.

In short Intel comes to the race for the best embedded processor 20 years late with a handicap.

Re:x86 to blame?

[StripedCow]

I don't understand why people put so much weight on instruction-level compatibility. As if compiler technology does not exist. Heck, even today compilers can translate efficiently from one instruction-set to the other (see e.g. virtual machines, emulators, etc).

Granted, there will always be some parts of code (the "innermost loops") that need to be handcrafted to be as efficient as possible, but I don't believe this is so important to base your whole roadmap on as a semiconductor design house.

Re:x86 to blame?

[leromarinvit]

Yeah, for really embedded stuff ARM is much better suited, becuase it is a lot simpler. I don't think it's possible or would make sense to squeeze the whole x86 legacy baggage into e.g. a tiny uC with a few KB SRAM, and still get decent performance and features. But I don't think this is where Intel is aiming at.

Re:x86 to blame?

[Anonymous Coward]

Power efficiency is a strange beast.

It's also worth making a trip down memory lane.

The big reason instruction decode power usage between RISC & CISC isn't that significant in modern server & desktop processors is simple: multiple execution pipelines. When you have two or four floating point units per instruction decoder, the number of transistors is overwhelmingly stacked in the floating point unit. Throw in the regular branch & integer hardware, and instruction decode transistor count is negligible.

That little fact clouds so many's understanding of RISC vs CISC. That and the fact nobody does CISC, and hasn't for at least a decade. Even Intel chips are a RISC chip with a x86 emulated in microcode.

Truth be told, you can get roughly the same flops/watt from a 200W Intel Xeon running flat out as from a 3w ARM. In terms of work per watt, ARM doesn't hold much of an advantage.

The problem many have is they don't consider anything but desktop or server processors, which are a tiny fraction of all microprocessors made.

ARM shines where Intel doesn't: low and battery powered devices. ARM doesn't have multiple FPU's, or multiple pipelines in general. A bare bones ARM core has only 40k transistors or so; and no FPU. At that scale, the transistor count penalty for a CISC ID is MUCH more significant, as is the power penalty.

CISC architectures are at a power and performance disadvantage when you have a chip that is not superscalar, multipipeline, and out-of-order. Such a market hasn't existed on the desktop since the first Pentium processors. The embedded and battery powered portable world, however is a different matter entirely.

Re:x86 to blame?

[Anonymous Coward]

Back before superscalar, multi pipelined chips hit the desktop (as well as any given day in the embedded world) CISC instruction decode took up the bulk of a chips transistor count. RISC was a solution to reduce cost, complexity, and increase performance.

However, multiple ALU & FPU pipelines largely made RISC a moot point on the desktop and in servers.

Most mbedded & portable processors omit the 'post-RISC' features in a server chip to reduce power drain & heat output. There, the CISC/RISC argument is still quite relevant.

As for it really mattering: From a software dev's standpoint, modern compilers eliminate most reasons to care what architecture is underneath.

But old biases in computing only die when the people who hold them die as well.

RISC vs CISC is common fodder for software devs, who know little about chip design, history, and implementation.

Hardware devs abandoned CISC long ago; CISC is only emulated these days.

Re:x86 to blame?

[Anonymous Coward]

This is because you can not statically translate a program from one instruction set to another in general. Self modifying code and indirect branches both require some kind of runtime support, such as trap-and-emulate virtualization.

Re:x86 to blame?

[Anonymous Coward]

In reality, most of the inefficiency of "x86" has more to do with the "PC architecture" and its many legacy components and BIOS, rather than the CPU instruction set architecture. The Atom is really pretty power efficient and could be made more so with slightly different fabrication goals, if its power draw were really the primary concern.

To date, Atom has been burdened in comparison to embedded platforms by not having a simple system-on-chip solution. In popular Atom-based systems, the external buses and chipsets consume more power than the CPU itself. If all the legacy IO controllers and general POST/boot legacy could be abandoned like they do on most ARM and MIPS embedded platforms, you could have a much more lean system with just the minimally required controllers on the chip and vastly fewer power hungry external transceivers to allow the chip to talk to other generic stuff on the mainboard.

If you look at the different organization of the Linux kernel and boot process on the embedded platforms, you would see just how much simpler these systems are. So many things are hard-coded and there is no need for general IO bus enumeration and such; this is a symptom of the underlying reality, that there is no general IO bus in the real device. This is a huge power win not because the software is simpler but because there are no high-current, high-capacitance circuits being driven off chip to support all that extensibility!

In extreme cases, the system on chip can even include RAM or flash memory space, but for the multi-gigabit sizes used these days, that would need to be separate chips in a multi-chip module (system on module) or separate modules on a small circuit board. But even in these cases, the circuits can be optimized with lower voltages and lower current drain since a design will have fixed storage built in. There is much less power draw to drive well integrated memory devices than to drive arbitrary memory modules in a field replaceable socket form factor.

Re:x86 to blame?

[viperidaenz]

SRAM caches consume virtually no power when no data is changed.

Linux-proof? Challenge Accepted!

[nopainogain]

just send me the hardware.

Re:Linux-proof? Challenge Accepted!

[Teresita]

Windows 3.1 AARD code made it DR-DOS proof, but that's about the only way to do this sort of thing. Undocumented opcodes.

Re:Linux-proof? Challenge Accepted!

[Anonymous Coward]

Reading between the lines, Intel probably decided that Clover Trail is a dog compared to ARM, but by specializing in Windows 8 they can grab a large piece of the market to buy them time to retool their manufacturing process. Also, there are probably power management features that the Linux kernel doesn't support. Just guessing that this may include disabling obsolete portions of the microcode like 286 protected mode and some of the good ol' complex instructions in the original 8086, like string instructions with the REP prefix.

Inetl having to work backwards

[PCK]

Intel have always designed their processors for performance first where as with ARM it was for power consumption, hell only recently did ARM get a hardware integer divide instruction. x86 instruction decode is not so complicated that it requires four times the amount of power, if it did Intel would never be able to produce high performance chips.

The CISC/RISC debate is pretty much a red-herring but it keeps on coming up over and over again, because as you increase performance the instruction decode becomes a smaller part of the processor, this is why on the A9 you have a fifth extra core for stand-by which has been engineered for low power.

It is n't the 80s and 90s any more.

Re:The Year of Linux on Desktop Is Now

[Anonymous Coward]

That's even better. The hardware would be running Linux.

Intel will fail at mobile

[leathered]

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

Re:Intel will fail at mobile

[Anonymous Coward]

Arm does not produce CPUs, they just license their CPU designs to companies like TI.

Steam the new Unreal Tournament??

[Andy Prough]

Is this like the year that we got Unreal Tournament and Doom on Linux, and we were supposed to take 50% market share from Windows??? Yeah, that worked out well. Although, UT2003 was a lot of fun...

Re:Steam the new Unreal Tournament??

[Anonymous Coward]

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.

Yuck

[Anonymous Coward]

Bad grammar is to Slashdot as weeds are to lawns.

Intel... pfffft !!

[Anonymous Coward]

Nothing but a kludgy Zenith knockoff. Garbage since day one. But... the price was right, and that's all that counts.

Re:The Year of Linux on Desktop Is Now

[Alex Belits]

Visual Studio

Please, please, please, stay on Windows, we don't need your Microsoft-infected minds spreading their diseases to other systems.

Re:The Year of Linux on Desktop Is Now

[Anonymous Coward]

Wow more vs shilling. Surprised only that you've been modded up.

Backwards Compatibility

[Anonymous Coward]

The X86 architecture has maintained backwards compatibility at the binary level for decades.

There are billions of applications for the X86 arch,while the ARM cores have just barely begun to dig themselves out of obscurity.

If Intel were to suddenly get rid of say , X86-16, and X86-32 mode, the CPU's would be much smaller, much more efficient power-wise, but the number of available applications would put Intel back into the dark ages.

There is a reason why everyone still uses an X86/32/64 desktop, and not ARM.

Re:The Year of Linux on Desktop Is Now

[thegreatemu]

Except MS office, which most of the corporate/academic world still uses for everything. Yes, Libre Office can do everything as well or in many cases better, but that doesn't matter when someone sends you a pptx file that Impress mangles into an unreadable smear.

RISC vs CISC, really?

[fermion]

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.

Come on Bruce

[Anonymous Coward]

Can you please refrain from insulting our intelligence with your baby-talk summary of RISC vs CISC? Furthermore, it has jack shot to do with why Clover Trail is Win8-only.

In other words...

[StripedCow]

In other words, Intel says they failed at hiding their power consumption details from the API (instruction set).

Intel has to go mobile

[bigt405]

Come on, look at the shift your average user has taken. Grandmothers aren't using eMachines, they prefer iPads. My laptop is heavy so I stick to my Atrix as often as possible when out and about.

It'd be stupid for Intel to ignore this market, especially with Win 8 RT not supporting the "full desktop" experience we love and know.

Re:Intel has to go mobile

[Anonymous Coward]

Remember, Intel sold off their XScale (ARM-based) line when it was at the top of it's game. Now "certain company" decided it wants ARM and Intel has got nothing to sell.

Intel is left out in the cold really badly right now. Microsoft has them bent over the table without the lube. Intel has to sell this how Microsoft wants.. Or no deal.

Re:The Year of Linux on Desktop Is Now

[Anonymous Coward]

And Lightworks.

http://www.omgubuntu.co.uk/2012/09/oscar-winning-video-editor-lightworks-landing-on-linux-in-october

Only benefits..

[Bert64]

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.

Re:Only benefits..

[Dwedit]

You want a good x86-only Linux program? Wine. There's a good one for you.

Re:Only benefits..

[smash]

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,

2 things: with the advent of smartphones that play 3d games - CPU performance is becoming more important. Also, that ability to run closed source x86 binaries is huge.

In terms of performance per watt, intel is doing pretty well. Phones and tablets are becoming less about absolute minimum consumption, and more about performance per watt. Intel also have the best fabs in the world. Yes, x86 is an ugly bastard hack of an architecture, but people have been trying to kill it off since the 80s. All have failed.

Re:Only benefits..

[KiloByte]

You want a good x86-only Linux program? Wine.

dpkg --add-architecture i386
apt-get update
apt-get install wine-bin:i386
apt-get install qemu-user-static # or non-static if you register binfmts by hand, it's a packaging issue

You may need to apply a NPTL patch to qemu, in most distributions qemu lacks NPTL when emulating i386. I heard qemu-linaro has that patch applied by default but I didn't try that.

Of course, it's more traditional to emulate arm on amd64...

Re:Only benefits..

[pclminion]

And when it comes to x86-only binaries, there is very little linux software which is x86 only

Just because it's open source and written in C doesn't mean it will work on ARM. If a program:

1. Assumes that char is signed
2. Performes unaligned memory access
3. Assumes a specific endianness
4. Assumes sizeof(ptr) == sizeof(some integer type)
5. Assumes the existence of a multi-megabyte execution stack

Or a great number of other things, then that program is not portable, even if it compiles for some other processor architecture. The GNU software that comes with Linux doesn't suffer these issues due to ongoing effort. But a lot of FOSS code is written by well-meaning but portability-impaired developers who've only ever run anything on x86. You can't assume that because it's source code that it's portable, even if you restrict yourself to Linux-only software.

Re:Only benefits..

[Bruce Perens]

Anything that's in a Debian release has already passed by these issues. That's a lot of disparate architectures. And that's 29K separate software packages.

Re:Only benefits..

[Anonymous Coward]

Huh? Nothing you mentioned differs between ARM and x86. Type of char is a compiler thing, any ARM in mobile phones does unaligned just fine, and they are configured to be little-endian, pointer size is the same as x86 and the size of the stack is an operating system function.
Assembler optimizations are a quite relevant and important thing though.

Re:Only benefits..

[Anonymous Coward]

Most of those are fixable. In fact, the only one that's obnoxious and somewhat difficult to resolve, code-wise, is when they stitch the fourth sin in throughout the code. That one's always a fun one- makes for porting 32-bit code to 64-bits "fun" and made it "interesting" to correct things so that a given game title could be 64-bit.

Re:Only benefits..

[Bert64]

There are very few open source programs that suffer from these problems... Open source code has long been ported to all manner of systems (IRIX, Solaris/Sparc, Alpha/Tru64 etc) so any bugs which tied them to a specific architecture have long since been squashed.

Just look at how many packages are available for non x86 architectures in the debian repositories.

It's a long time since i encountered an open source program that had problems on a non x86 system... I used to encounter some problems on alpha, as it was at the time pretty much the only system with a 64bit userland, but the prevalence of amd64 pretty much solved that.

Reality check

[shutdown -p now]

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

[fm6]

In geekland, Nobody == Nobody I Know.

Re:Reality check

[Bruce Perens]

Manufacturer announced devices != customer purchased devices.

Re:Reality check

[marcosdumay]

how come that there is a slew of x86 Win8 devices announced by different manufacturers - including guys such as Samsung

Oh, all the guys that were already selling WP7 phones? Well, Windows will sell a few phones anyway, why would they stay out of this market?

Re:Reality check

[Anonymous Coward]

There's only really business space tablets (and the player kind of gave up on them in recent times...funny that) doing the Medfield thing. I think there was one phone, but that also hasn't been selling all that much because it was overpriced for what it did and underpowered to get X86 Android out the door (Just so you could not be able to play 1/3rd of the games out there, etc...because all of those apps rely on NATIVE ARM CODE to run...)

In truth, there's little difference in overall performance in this space, clock-for-clock, and a Cortex A9. And it's got triple or more the power consumption over the A9 stuff.

A15's up the ante, bringing better performance per-clock and per-watt, and unless Intel can manage to get this one down in that same domain, they've got a problem- seriously, few want the damned things... Just because some vendor announced something doesn't mean someone's going to BUY it.

Re:Reality check

[shutdown -p now]

Sure, but do you think that so many companies would announce their offerings if they didn't expect to at least get their money back?

Re:Reality check

[shutdown -p now]

The obvious and huge difference is that Windows Phone was a brand new OS with zero backwards compatibility, whereas Win8 - and especially Win8 on Intel devices - has full support for existing Windows apps.

Re:Reality check

[shutdown -p now]

There's only really business space tablets (and the player kind of gave up on them in recent times...funny that) doing the Medfield thing.

Medfield is kinda underpowered for tablets, and Intel hasn't actually positioned it for them. I'm not aware of any Medfield tablets. Intel has been pitching Clover Field for tablets.

I think there was one phone, but that also hasn't been selling all that much because it was overpriced for what it did and underpowered to get X86 Android out the door

The one phone in question is actually Intel's reference design, just rebranded by various operators. IIRC it's out in three countries, two of them being India and Russia (I don't recall the other one). It's selling okay in all of them, about what you'd expect from a phone being positioned the way it is (by perf and price, it's about average in the Android pack).

(Just so you could not be able to play 1/3rd of the games out there, etc...because all of those apps rely on NATIVE ARM CODE to run...)

Actually, it can run the vast majority of what's in the app store, because it has a binary ARM-to-x86 translator, which works surprisingly well (people have run Doom compiled on ARM on it, for example).

Re:Reality check

[Bruce Perens]

You've never gone to CES, then?

They might expect to get their money back. Most of them lose. Certainly there have been no shortage of losers in mobile.

Misleading slant on mention of Atom's RISC core

[Dogtanian]

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.

Re:Misleading slant on mention of Atom's RISC core

[Anonymous Coward]

I'm pretty sure the first Atoms were in-order, though.

Re:Misleading slant on mention of Atom's RISC core

[im_thatoneguy]

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

[Anonymous Coward]

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.

We've been hearing this from Intel since the first Atom netbooks were released. It hasn't happened yet and I don't even see any evidence that the gap is getting smaller.

Re:Misleading slant on mention of Atom's RISC core

[ClickOnThis]

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.

Quibble: I think you mean person-miles per gallon.

Re:Misleading slant on mention of Atom's RISC core

[isorox]

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.

Last time I was in Delhi I saw 5 people on a moped. At 70mpg that's 350miles-per-person-gallon :p

Re:Misleading slant on mention of Atom's RISC core

[reiisi]

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

Re:Misleading slant on mention of Atom's RISC core

[Anonymous Coward]

Intel dominates flops per watt compared with ARM? Please cite your proof.

Re:Misleading slant on mention of Atom's RISC core

[Anonymous Coward]

No, the Intel Pentium Pro was the first real "CISC-on-RISC" design.

The phrase is not referring to the programmer-visible ISA. Claiming that "8GP registers do not a RISC make" shows you misunderstand the idea -- of course nobody is claiming that the ISA is a RISC ISA. It certainly is CISC, and x86-64 is also a CISC regardless that it has 16 GP registers.

RISC is referring to the RISC-like micro operations that the CISC instructions are cracked into.

Re:Misleading slant on mention of Atom's RISC core

[Anonymous Coward]

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.

Sure, just hop on the bus!

Re:Misleading slant on mention of Atom's RISC core

[Guy Harris]

No, the Intel Pentium Pro was the first real "CISC-on-RISC" design.

Didn't the Nx586 come out a little earlier?

Re:Visual Studio is great, but what about MyCleanP

[MysteriousPreacher]

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.

Re:The Year of Linux on Desktop Is Now

[Vince6791]

Are you talking about visual studio 6.0 - 6.1? Visual c++ works so far but visual basic crashes every time I type MsgBox(. Yup it crashed at the "(". I can run Steam on wine right now in ubuntu 12.04.1 without issues but it does not run any game. I have cod4MW and of what i heard it runs fine on non-punk buster servers. I will try this today. If netflix came over to linux I would be even more happy but since they are assholes and it's running only in Chrome OS and android devices I have to run it in virtualbox which has video tearing issues. Linux is not bad. I had to install ubuntu 12.04.1 on a atom 1.3ghz netbook gma 500 with 2gbram because windows 7 was running dog slow when web browsing or watching videos. Actually the Poulsbo drivers run better on linux than the native intel gma 500 on windows 7.

Re:The Year of Linux on Desktop Is Now

[ColdWetDog]

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

Re:The Year of Linux on Desktop Is Now

[MindlessAutomata]

What? Valve has multiple teams on different projects. I can't believe you would even post this--hardware people aren't necessarily software people. And if they're doing hardware, how's it gonna run? Oh right, you need software as well. Durr.

hah

[smash]

No wireless. Less space than a nomad. Lame.

I predict clover trail will be a roaring success.

Don't bet on it being so much more efficient

[samuisan]

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

[stripes]

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.

Re:The Year of Linux on Desktop Is Now

[Vince6791]

I had the same issue with office 2010 when people were sending us excel, word, ppt files in office 2003 format. Yup, some text were tabbed to the right, bullets were different sizes, lines appearing as thick double in excel, draw lines in word half in middle page while the end of the line showing up in the next page line. Word had the most issues compared to excel and powerpoint. I imported these 2003 format into libreoffice and it was not that bad compared to the office 2010, just 2 lines of text tabbed over.

backroom agreement?

[zman58]

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

Re:Visual Studio is great, but what about MyCleanP

[Anonymous Coward]

ia32 dates back to the 1970's 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

Sounds just like Windows (cisc) versus the Unix Philosophy of a bunch of small tools which each do one thing well and can easily be linked together to form a more complex task (risc).

Power argument has been mostly debunked

[Anonymous Coward]

The big power efficiency argument of RISC vs. CISC has long been mostly debunked.

It's about an extra 10% overhead on x86 at WORST, likely not even that much in real hardware. Other technology issues end up hugely dominating.

In the case of ARM vs. x86 processor power management, the main difference is that ARM hardware systems have been CUSTOM codesigned with the software to take advantage of special low-power states with special devices they have to offload various operations. This has been much harder to do in the generic x86 ecosystem. For example, real ARM hardware that uses non-targeted versions of Linux generally have higher power utilization.

ARM is not RISC and x86-64 is not CISC

[YA_Python_dev]

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.

Re:ARM is not RISC and x86-64 is not CISC

[imroy]

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

[Anonymous Coward]

RISC means single cycle instruction processing even if the acronym meant something else once. The RISC / CISC thing was lame market-speak when processor comparisons were made and the one that was easier to program could take significantly more t-states to execute each instruction, thus more expensive in processing terms.

Re:ARM is not RISC and x86-64 is not CISC

[Bruce Perens]

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.

Re:ARM is not RISC and x86-64 is not CISC

[default luser]

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?

Re:ARM is not RISC and x86-64 is not CISC

[Bruce Perens]

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.

Re:ARM is not RISC and x86-64 is not CISC

[Anonymous Coward]

a15 has some of that stuff. ..if we one day get cpu's with it.

Re:ARM is not RISC and x86-64 is not CISC

[AcidPenguin9873]

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

[ZosX]

Agreed! I read TFA article too. Intel has been long behind and it is simple fact that their architecture was never efficient from the start and probably never really will be in comparison.

Re:ARM is not RISC and x86-64 is not CISC

[Darinbob]

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

[Darinbob]

The win on different criteria and different goals. Intel most clearly is not a well designed instruction set for the purposes of decoding even Intel wants to dump it but their alternative chips do not sell as well. x86 is all about backwards compatibility and not much else. Yes code density is smaller but with instruction caches and buffers that is a trivial advantage compared to the cost of supporting that instruction set over the decades. Intel gets away with it because they have the resources; they can make an overly complicated chip and put hundreds of engineers on it and new fab technologies and then make up for the cost on volume.

When you move away from the mass market dumb PC model where you don't have to be compatible with Windows and Windows applications then x86 family is not competitive. Argue all you want about how great x86 is but almost no one uses it in their products except for PCs and Macs.

Re:ARM is not RISC and x86-64 is not CISC

[nastav]

I hope somebody mods parent Insightful.

Re:ARM is not RISC and x86-64 is not CISC

[default luser]

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?

Re:ARM is not RISC and x86-64 is not CISC

[Anonymous Coward]

In a few short years, silicon will be replaced. The majority of the research money in this area is tied up in IBM, GF, Samsung, etc. All Intel's fab knowledge will be less useful when switching medium and other companies will have the necessary patents.

Re:ARM is not RISC and x86-64 is not CISC

[WilliamBaughman]

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

[Bruce Perens]

My article isn't wrong about RISC vs. CISC. Actually, that argument was won about 20 years ago.

And it's unfortunate that many Android chips are a mess of hardware with undisclosed interfaces. But that doesn't in any way invalidate my argument.

Re:ARM is not RISC and x86-64 is not CISC

[WilliamBaughman]

Thanks for replying, I should have been more specific. Your conclusion that (I'll paraphrase) no one should care that Intel's Clover Trail SoC is shipping with Windows 8 only (and documentation may be closed) is correct. But parts of your arguments fall down, even though other parts hold up. Your statement about RISC vs. CISC at the core level is correct, but at the ISA level is wrong. You're absolutely right that RISC vs. CISC was settled 20 years ago, with CISC vendors adopting RISC cores wrapped in CISC decoders, but you're wrong about the penalty associated with that decoder. Your statement

ARM ends up being several times more efficient [...]

is wrong in the general case, at least when you look at an SoC or even core level. Some ARM-based SoCs are more efficient than Medfield, but none are several times more efficient. Your comments in this thread about Intel having a 4-to-1 size advantage with its transistors are also wrong, Medfield and Clover Trail are both on 32 nm, both launched (or are launching) after Qualcomm's high-end stuff on TSMC 28 nm, and Samsung's high-end stuff on their own 32 nm process. If Atom were on 22 nm FinFETs and losing to TSMC 40 nm, that would be embarrassing but that's not the case. Atom core has its own shortcomings but they're not really ISA-related.

Re:ARM is not RISC and x86-64 is not CISC

[unixisc]

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:ARM is not RISC and x86-64 is not CISC

[Bruce Perens]

Hi William,

You might be correct that the overhead of instruction decode is not so significant. I think, however, that emulating all of the architecture goes far beyond just instruction decode. The Medfield reference benchmarks we see, it's about 1/2 the normalized battery performance of iPhone 4S.

Re:ARM is not RISC and x86-64 is not CISC

[WilliamBaughman]

That's a good point. ISA goes beyond instructions and also defines the memory and interrupt models, which Atom must then emulate as well. I'm not an expert on the interrupt models, but if I recall correctly, ARM's can be implement more easily and with less power, so Atom loses there. But, to my knowledge, it's still not a large difference.

You're right that iPhone 4S creams Medfield reference in battery performance benchmarks, I'm looking at the ones on AnandTech right now. But the iPhone 4S creams other Android smartphones, too, so it's not just the ISA. Many of the android phones compared in the XOLO review (and the newer ones, too) do about as well as the Medfield reference design in the normalized power charts. AnandTech doesn't include all of the phones in the review in the later link, so you have to tab back and forth. I'm not going to demand that you call the Atom stellar, but its deficiencies are (I think) removed from the ISA and CISC vs. RISC at large.

Re:ARM is not RISC and x86-64 is not CISC

[Bruce Perens]

ARM's R&D expense is very small compared with Intel's. I think ARM can make a good CPU for much less, while Intel had to work very hard to achieve this and I doubt Intel makes a profit on any mobile CPU today. I suspect ARM's R&D investment will increase now,

Re:ARM is not RISC and x86-64 is not CISC

[WilliamBaughman]

Yes, yes, and yes. ARM designs good CPU cores and does so inexpensively, no doubt about it. At the risk of sounding contrary, the real race isn't between Intel's budget and ARM's: it's between Intel on one side and ARM, Apple, Qualcomm, Samsung, NVIDIA, Texas Instruments, and more (AMD is my favorite dark horse) on the other. Apple alone has bought multiple chip design companies, and probably a whole company's worth of engineers from the formerly-ATi side of AMD. I think that's why their phones cream their competitors (or all ISA flavors) in the aforementioned examples.

It's true, ARM will continue to increase it's R&D investment now (which is really their whole budget), but that investment will increase more slowly for awhile, the company is trimming its hiring plans for the rest of 2012 amid concerns about a potential sales slowdown in the second half. (Intel is trimming, too, it's more macro economic than anything else.) But I maintain that ARM Holdings vs. Intel is only a small part of ARM vs. Intel ;-)

It has taken Intel an enormous effort to get as far as it has in the mobile space, which isn't very far (yet). I have no idea what Intel is making on mobile CPUs, but it's not selling many of them at this point. It's going to keep trying, though. Intel knows that ARM is now where Intel was when Intel beat up IBM and took IBM's lunch money, so they're not going to stop. I think it's going to stay interesting.

I hope we get to talk more about architecture some time.

Re:ARM is not RISC and x86-64 is not CISC

[WilliamBaughman]

D'oh! I replied to the wrong comment. Anyway, I hope we get to talk more about architecture some time.

Re:ARM is not RISC and x86-64 is not CISC

[KugelKurt]

a15 has some of that stuff. ..if we one day get cpu's with it.

AnandTech claims that Apple A6, the iPhone 5's CPU, implements the Cortex A15 (arm7s) instruction set.

Re:ARM is not RISC and x86-64 is not CISC

[crutchy]

intel is a much more limited application chipmaker, whereas arm is used everywhere. i think the experience that manufacturers of arm gain from their broad use gives them the edge. intel is in the same boat as microsoft... small incremental developments and holding on as long as the oems keep towing the line

look at microcontrollers that use arm... manufacturers are cramming entire motherboards onto a tiny piece of silicon, with processing grunt that is fast becoming comparable to x86

there's no term of use for claims made on slashdot to be justified... if you expect others to answer your questions that you could have answered with some simple googling, then you're a douchebag

Re:ARM is not RISC and x86-64 is not CISC

[crutchy]

try this one for example, in google results for "arm vs x86" http://www.cnx-software.com/2012/06/19/arm-vs-x86-servers-benchmark-calxeda-energycore-ecx-1000-vs-intel-xeon-e3-1240/

FUD

[Anonymous Coward]

We haven't actually seen what tablet makers will be able to do with Clover Trail yet, and the article is far too light on the details to truly support any of its assertions. But even if the analysis of technical limitations were completely accurate, it would not be enough to write off the processor at this stage. There have been plenty of examples in the past few decades of technologies that prevailed and became ubiquitous despite being arguably inferior than their competitors. Since we're talking about a partnership between the dominant processor maker and the dominant OS maker, it's certainly possible that Clover Trail will succeed even if it sucks. There's a huge gap between finding a technical limitation (or even flaw) and declaring a product "dead-on-arrival."

RISC vs CISC updated with buzzwords

[Anonymous Coward]

Remove the references to "Android" so you can transport this argument back to the 90s where it came from.

Re:The Year of Linux on Desktop Is Now

[fm6]

Steam and Visual Studio. Oh yeah, that's all applications anybody needs.

Re:The Year of Linux on Desktop Is Now

[blind biker]

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.

Re:Visual Studio is great, but what about MyCleanP

[fm6]

If you're going to spam, at least enter the link correctly.

Bruce Parens is Right!

[fm6]

We know that because the Bruce Parens blog post that he linked to confirms it!

Re:The Year of Linux on Desktop Is Now

[hack slash]

A popular application does not mean it's a productive application that can earn you money through its use.

Re:The Year of Linux on Desktop Is Now

[Anonymous Coward]

To run Windows software on WINE it's not one of my dreams.

And at the end only a part of that software will run on Linux. There are so many programs that won't work.

No, Linux will have success on Desktop only when it will be able to offer something MORE and not just some Windows programs.

Also what is the main goal of having tons of proprietary applications on an Open Source OS? At this point I would just use Windows 7 that is pretty stable or I would buy a Mac.

Yes but closed-source x86 binaries usually...

[Anonymous Coward]

expect high resolution, reasonable pixel size (i.e. not too small), keyboard input and accurate multi-button pointing devices. So porting SolidWorks to cell phones isn't really that important.

Re:Yes but closed-source x86 binaries usually...

[smash]

No but there are plenty of apps that could be run with say, a bluetooth keyboard/mouse and an external display. Thus nullifying many user's need for a traditional PC in addition to the tablet. And there are other apps that could be adapted to have a scalable UI (like MS is /attempting/ to do with Win8).

Re:The Year of Linux on Desktop Is Now

[kelemvor4]

For me, the year of linux on desktops is now. With Steam coming to Linux, along with Crossover and pure Linux-ported games, the inevitable has happened. 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). Everything I need works in Linux.

Steam coming to Linux is a start. It would take a lot more than the handful of valve games getting ported to seriously interest me, though. In my opinion it will be viable when you can reasonably assume any random game that is released will have a Linux version available. As far as I'm concerned a wine based solution is really no solution at all; unless it's like the last app you need and everything else is already native. I'm all for Linux on the desktop, but I think it's still got a long way to go.

Re:The Year of Linux on Desktop Is Now

[mwvdlee]

I'm currently forced to use VS2010 on a project.
It is without doubt the shittiest and most error-prone IDE I've ever used.
I have no doubt VS2012 will dumb down things even more.

Re:The Year of Linux on Desktop Is Now

[jd2112]

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

Re:Visual Studio is great, but what about MyCleanP

[jkflying]

Whoosh!

Re:Visual Studio is great, but what about MyCleanP

[Anonymous Coward]

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.

Don't worry; that's not a problem.

Re:The Year of Linux on Desktop Is Now

[hack slash]

Don't give up hope, hundreds of thousands of people in offices across the globe have made a living whilst playing Windows Solitaire.

typo?

[Anonymous Coward]

did anyone else read the title as, "The Linux-Proof Professor That Nobody Wants"?.....

Re:The Year of Linux on Desktop Is Now

[BenoitRen]

There will never be a "Year of Linux on Desktop". The developers are too busy breaking their APIs and changing their GUIs to make it usable.

Between now and January 1st..

[Paracelcus]

Between now and January 1st (IMHO) the complete "Clover Trail" API will (almost) certainly have been disclosed/reverse engineered by somebody, somewhere.

It ALWAYS happens.

Linux Proof?

[nitehawk214]

So in this case the processor simply uses more power when running Linux, and has no savings at all under Windows. And yet you get claims of "Oh look how efficient Wintel is!"

Visual Studio 2012 Has Worst UI Of All Time

[Anonymous Coward]

I was forced to install it at work to develop for [a platform that forces you to install Visual Studio 2012 to develop for it]...

My god, it has the ugliest UI ever seen from a Microsoft app since the Windows 3.1 days! And that's saying something. I thought the Visual Studio 2010 UI looked crappy compared to 2008 (at least on the classic UI theme, maybe if you have whatever stupid UI candy MS was pushing in vista/7 then maybe it looks better, I don't know and I don't care).

But 2012? Holy fuck balls. No borders or 3d bevels anywhere. You can't tell where the edges of a button or a view are, except by inferring it from the surroundings. You can't tell what is supposed to be clickable for input and what isn't. The icons used in Solution Explorer and similar outline views, are THE UGLIEST bar none, that I've ever seen. 2008 and 2010 had decent-looking icons that were consistent with normal Windows UI themes (e.g. folders were yellowish, just like they are in explorer... files were nicely shaded and the file extension was easily readable on the icon). In 2012, these icons all use only one or two colors (BLACK on WHITE is a popular choice, but WHITE on BLACK and RED on BLACK and similar abominable combinations are present). The fucking things are horrible to look at, they look like some intern made them in 20 minutes with MS Paint.

The menus are in ALL CAPITALS. I'm not kidding. It shouts at you: FILE EDIT and so on. The toolbars, like everything else, have no visual cues to separate them from menus or windows or views.

Visual Studio 2012 has a completely unusable UI. Its like they fired all of the people who knew what they were doing and told marketing execs to make the fucking product. Its completely in-line with all the other stupid stuff Microsoft has been doing recently (Metro and Windows RT, etc.) By which I mean it looks like all of the product decisions were made by retarded monkeys.

What amazes me is that Ballmer is doing his best to run Microsoft into the ground, but so far he's hardly even made a dent in their huge cash warchest. He's got to hurry up with that.

Re:Visual Studio 2012 Has Worst UI Of All Time

[godefroi]

There's a setting in the registry to disable the all-caps thing. I haven't tried it.

As for the colors, MS released an extension ("Visual Studio 2012 Color Theme Editor") that can be used to change the theme. It comes with various new ghastly themes, along with "Blue" which looks pretty much like VS2010.

Here is what Intel says

[PCM2]

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.

Re:Here is what Intel says

[gl4ss]

Hey,

Isn't it right that medfield on the other hand, with it's powervr, can't run windows at all?

Re:The Year of Linux on Desktop Is Now

[gl4ss]

should mod +5 funny instead of -1 troll.

virtual launch party should clue that in.

Re:The Year of Linux on Desktop Is Now

[udippel]

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.

not a problem

[JustNiz]

Somebody will reverse engineer the windows version of the API and add an open version into Linux within like half a day of its release (on windows).

NOP is a single instruction on CISC. INC is too.

[Anonymous Coward]

So I guess there's no difference between RISC and CISC if you DON'T get rid of the single-cycle rule.

Re:Visual Studio is great, but what about MyCleanP

[ZosX]

omg..i'm dying here

I feel in another hundred years

[Anonymous Coward]

We will need to post this again the first time I read all this was 30 years ago.

Slashdot hates the Atom processor.

[Anonymous Coward]

But that's okay, because not everyone thinks computing is only about encoding video, or playing games at very high resolutions. There are plenty of people who consider Atom-powered mini-ITX systems to be very useful.

1/4th? No...

[Guspaz]

ARM can still beat Intel when it comes to power efficiency, but I think the Atom-based android smartphones have proven that power efficiency isn't THAT bad.

Re:Visual Studio is great, but what about MyCleanP

[ultrasawblade]

"CISC" made a lot of sense when RAM was $1000/KB (pretty much was in mid to late 1970's). It meant you could have more complex programs for a given amount of RAM.

Some make the argument that RISC's low instruction density is a disadvantage, but the bottleneck in most systems is waiting on RAM, not waiting on decoding instructions (and ARM has the "Thumb" modes that serve effectively as a form of instruction stream compression in a way).

Re:Visual Studio is great, but what about MyCleanP

[ultrasawblade]

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.

peruksatis

[peruksatis citcit]

nice article. What we do not know more. More I look forward to your posts. I hope you will continue like this informative articles. good work http://peruksatis.com/

My hope...

[clevershark]

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

Waiting for the day...

[DaneM]

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.

Re:The Year of Linux on Desktop Is Now

[TheDarkMaster]

I wonder what year you were born to write such nonsense.

CISC vs RISC

[Chas]

Okay, it's 2012 for fuck's sake.
None of the processors being discussed are pure "RISC" or pure "CISC". They're all hybrids, or at least any of the ones manufacturers actually want to put inside a device...

There's always going to be a bunch of "academic" holdouts so they have an example of "Hey! The RISC-Not-In-Anything-30519 IS a pure RISC chip (that's totally unsuitable to general computing applications, or even specialized device applications)!"

But for the most part, this argument died decades ago. Let it fucking go already.

Re:CISC vs RISC

[cpghost]

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.

I'm not doing things your way today

[Bruce Perens]

I think I'll engage in a technical discussion with some other of the readers.

But you're obviously so incensed by my article, so offended, and so outraged, that it would be funnier if I just ignored you and let you steam.

What would a low power Alpha have been like?

[unixisc]

I'd like to see what a mobile-grade Alpha processor looks like. But I never will.

I think that Alpha just as Alpha went from Superpipelining to Superduper (Superspipelining AND Superscaling), similarly, had they been out this long, they'd have tossed in more cores, rather than increase the frequency. In fact, @ this point, they'd probably have used process shrinks to lower the power consumption, and even compromised the frequency, if needed, so long as it was higher than Intel and POWER7. For their mobile grade CPUs, they might have lowered that even more.

Actually, for a thought experiment, why not look @ how the MIPS has evolved? It underwent a similar journey as the Alpha, except that unlike the 21164, which went from superpipelined to superduper, MIPS went from purely superpipelined in MIPS III (R4x00) to purely superscalar in MIPS IV (R8000). Today, w/ SGI pretty much abandoned, they are one of the main competitors in the tablet market, thanks to XBURST and Loongson. Alpha too might have undertaken a similar journey, aside from being a VAX only CPU.

On a different note, I do wish that Microsoft supported MIPS too w/ Windows RT, just like it does ARM

Re:The Year of Linux on Desktop Is Now

[exomondo]

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.

It's a pretty obvious troll...though it seems to have fooled you.

VLIW - the ideal CPU for Liberated s/w

[unixisc]

OP has a typo - should be 'Clover Trail is said to include power-management that will make the Atom run longer under Linux'

Clover Trail and Hondo are not Linux-proof CPUs (they are just prioritized towards WIndows 8). Linux is just a great leveller for CPUs, and whatever ARM vendors throw should run it, and it would be fine. There is nothing like Linux being a RISC OS or Windows being a CISC OS (the latter is only true due to the vast s/w and drivers being Wintel)

On the flip side, the best CPU for not necessarily Linux, but the best CPU for the ideal FSF platform would be something like NXP's Trimedia CPU, ADI's SHARC or TI's C6000 CPUs. Or any other VLIW platform. Since no 2 VLIW platforms would be compatible w/ each other, and everything has to be re-compiled, I'd say that HURD should be compiled to that platform, and following that, all GNU s/w should be. That way, the only s/w for this CPU would have to be liberated, b'cos unlike w/ x86, if it isn't, it just won't run for a next VLIW CPU. That way, the FSF can ensure that all s/w for such platforms are liberated s/w

But x64 is RISC, not counting 32-bit instructions

[unixisc]

True, but what is @ the core of a CPU is quite important as well. Also, in the x64 version of the x86, both AMD and Intel have left out certain instructions that were there in the 32-bit mode - which made it more CISCy. As it is, more & more software is now win64 and same on the Linux side as well. As 8GB becomes the minimum memory density available, both Intel & AMD can drop support for 32-bit instructions completely, @ which point the x86 would be a pure RISC architecture - just like MIPS and POWER (Although POWER has a hugh instruction set - I recall the thickness of the PPC 601 instruction set book when I was a student.)

Triumph

[kimvette]

When Triumph was asked "What do you think of logging bathroom times on the new timesheets?" All he said was "It's great, for me to poop on!"

Manipulation vs engineering.

[Anonymous Coward]

So, ARM ends up being several times more efficient than Intel."

That's because ARM design chips to work as well as possible with any code, as opposed to designing a chip with the intention of using it to control the marketplace for Microtwat.

Bruce Perens knows Slashdot well

[Anonymous Coward]

Bruce Perens knows that Slashdotters won't RTFA, so he puts all the relevant details in the /. summary.

Not surprisingly, he has a 4-digit Slashdot UID.

but when you don't have a busload of passengers ..

[reiisi]

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

Apple ditched on us, not just on RISC.

[reiisi]

Apple bailed, not on the PPC, but on Motorola and IBM's SOC ideas.

Jobs kept talking about the road-map during the switch. Not the CPU, the road map. Intel's (still vaporware) pseudo-UWB, on-chip peripherals dedicated to desktop functionality, etc.

Mostly they ran scared from real UWB, but that's a bit of history that Intel has effectively erased. (A little strong-arm here, a little bribe there, .... Maybe a little help from the government.)

Shoot, my single core Atom ultra-lightweight is about as slow as my (unfortunately dead) iBook G4 on most of the real-world loads I put on it. (Well, some, at least.) The Atom is no improvement over the G4 in battery use, either.

Intel really hasn't kept any of their promises, so we can see that all Jobs really got was road-map into the mists, and the approval of a bunch of lemmingeeks.

Try this for a reality check.

[reiisi]

Use bc to compute pi on a single-core Atom. (Relatively recent, right?)

Do the same on a G4 iBook. (Ancient, right? waaaaaaaay slow FSB, right?)

Now compare the time between charges.

Gives you something to think about.

Re:Try this for a reality check.

[smash]

Because calculating Pi is the primary criteria people look for in a mobile CPU.

IA64?

[reiisi]

I think the people who designed the Itanium seemed to think you could optimize all conditionals out of your code with the right compiler.

Pushing things way too far to the extreme does not prove much about more normal designs.

Re:IA64?

[kenorland]

Itanium was designed by top hardware and software designers and companies sunk a lot of money into it. What this tells you is that even if you put together smart and experienced engineers and give them large amounts of resources, they still get it wrong. And Itanium is hardly the first such failure. Hence, I don't put much stake in anybody's opinion about what a good or bad processor architecture is for a particular application.

More oversimplified stuff, but, ...

[reiisi]

Just for kicks, I tried comparing my recent single-core Atom with my ancient G4, using bc to compute pi an easy way.

Not conclusive by any means, but food for thought.

such a waste

[reiisi]

Sure, Intel will pour more money and manufacturing and silicon into maintaining their monopoly.

But it's such a waste.

Gross oversimplification, and incorrect at that

[Anonymous Coward]

Same order of magnitude of nonsense as tubes.

Please elaborate?

[Medievalist]

...this additional complexity increases the amount of possible errors (Intel and AMD processors have hundreds of unfixable errors that must be coded around.

"Coded around" where? I don't have any special instructions in my code to handle processor errors.

Re:Visual Studio is great, but what about MyCleanP

[CRCulver]

I wasn't spamming, I was repeating a classic troll post in order to lampoon the OP's obvious shilling. And I didn't format the link correctly because I didn't want to help that particular company with SEO.

RISC ha ha you gotta be kidding...

[Anonymous Coward]

RISC was based on small die sizes due to small instruction set providing more chips per wafer. It was also based on fast external memory.
x86, x64 and ARM are hardly true RISC chips!!! Go read about RISC chips with no floating point or multiple instructions and see that RISC
failed and the name was perpetuated by the losers!!!

Re:CISC is not the silver bullet

[Anonymous Coward]

Apple ditched the CISC-type Motorola for the RISC-type PowerPC architecture, only to switch to X86 after the millennium.
Other CISC architectures are IBM's System/Z and Digital's VAX-11. Intel has made RISC processors like i860 and i960 and
XScale, and I suppose the i432 chip set was CISC. it also makes VLIW or EPIC processors called Itanium.

Before the advent of CISC architectures, with general-purpose register sets and orthogonal addressing modes, in the sixties there were simpler architectures, which typically used a single accumulator. The Intel 4-bit 4004 is a late example of this class, which was upgraded to the 8-bit 8080, the 16-bit 80286, the 32-bit 80386 and the '64-bit' Core2000. Even though the microarchitecture resembles a RISC processor, Intel has not made CISC processors for years; calling the PC-architecture CISC is just silly.

Corrections...

[TemporalBeing]

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.

Okay, they got this part right. But...

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.

...they got that wrong. First, RISC instructions would be over-generalized, which CISC instructions are more specific to various tasks requiring more instructions in general. Now, a compiler may be able to optimize performance on a RISC processor in some situations with more instructions than a CISC processor could with its more complex instructions; but it will probably work out about even if not in favor of CISC for performance in general - 4 instructions that run in 4 cycles are always slower than 1 instructions that runs in few cycles, which is the difference between RISC and CISC.

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

Yes RISC instructions are more likely to run in a single processor cycle, but that instruction does less than the CISC instructions that may run in a couple instructions cycles.

For instance, on a RISC system you have to retrieve a value from memory (1 cycle), operator on it (1 cycle), and then store it back to memory (1 cycle) - so you have a minimum of 3 cycles. Comparatively some CISC instructions (e.g. IA32) can in the single instruction retrieve, operate, and store in the same instruction and may operate in up to the same number of cycles.

Now, here's the kicker - Intel chips are no longer pure CISC chips. At the normal programmer level writing Assembly or a higher level language it still uses the same interface. However, under the hood Intel chips convert a number of those CISC instructions to RISC instructions and then optimize it again. That's what their Micro-code code, and anything newer than a Pentium Pro does it.

Re:But x64 is RISC, not counting 32-bit instructio

[Guy Harris]

Also, in the x64 version of the x86, both AMD and Intel have left out certain instructions that were there in the 32-bit mode - which made it more CISCy.

And left out neither any of the register-memory arithmetic instructions that were there in the 32-bit mode nor the CALL instruction, which also made it more CISCy.

As it is, more & more software is now win64 and same on the Linux side as well. As 8GB becomes the minimum memory density available, both Intel & AMD can drop support for 32-bit instructions completely, @ which point the x86 would be a pure RISC architecture - just like MIPS and POWER

...unless you consider "load/store architecture" to be an inherent characteristics of a "pure RISC architecture".

Re:but when you don't have a busload of passengers

[Anonymous Coward]

Hey guys! I live in Japan! Let me give an irrelevant story that show that I live in Japan! Japan!

Oh yeah, something about computers.

ITT...

[Anonymous Coward]

Butthurt lintards that know deep down inside something that will not run linux is going to be successful.

big bias no whammies

[FyberOptic]

I don't think this post could be loaded with any more blatant bias if they tried. Instead of simply informing people of the information, it essentially went on a rant on why Intel sucks, why ia32 sucks, and that ARM is simply better in every way imaginable, so who needs that stupid stinky Intel meanie head anyway?

Next time, leave the crying for the comments.