The Linux-Proof Processor That Nobody Wants

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

Nice advertisement for RISC architecture.

Sure it has advantages, but obviously it's not all that great. After all Apple ditched the RISC-type PowerPC for CISC-type Intel chips a while back, and they don't seem to be in any hurry to move back. It seems no-one can beat the price/performance of the CISC-based x86 chips...

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

Like I posted elsewhere, intel hasn't made real CISC processors for years, and I don't think anyone has.
Modern Intel processors are just RISC with a decoder to the old CISC instruction set.
RISC beats CISC in price performance trade-off, but backwards compatibility keeps the interface the same.
Re:RISC is not the silver bullet by stripes · 2012-09-16 02:49 · Score: 2, Informative
Apple ditched the RISC-type PowerPC for CISC-type Intel chips a while back, and they don't seem to be in any hurry to move back
FYI, all of Apple's iOS devices have ARM CPUs, which are RISC CPUs. So I'm not so sure your "don't seem to be in any hurry to move back" bit is all that accurate. In fact looking at Apple's major successful product lines we have:
1. Apple I/Apple ][ on a 6502 (largely classed as CISC)
2. Mac on 680x0 (CISC) then PPC (RISC), then x86 (CISC) and x86_64 (also CISC)
3. iPod on ARM (RISC), I'm sure the first iPod was an ARM, I'm not positive about the rest of them, but I think they were as well
4. iPhone/iPod Touch/iPad all on ARM (RISC)
So a pretty mixed bag. Neither a condemnation of CISC nor a ringing endorsement of it.
Re:RISC is not the silver bullet by wvmarle · 2012-09-16 03:02 · Score: 1

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 by vovick · 2012-09-16 03:02 · Score: 3, Interesting

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

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.

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:RISC is not the silver bullet by UnknowingFool · 2012-09-16 03:14 · Score: 5, Informative

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

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

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

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 by Anonymous Coward · 2012-09-16 03:21 · Score: 1

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 by stripes · 2012-09-16 03:23 · Score: 2

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

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:RISC is not the silver bullet by stripes · 2012-09-16 03:34 · Score: 5, Interesting

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

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

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 by tolkienfan · 2012-09-16 04:15 · Score: 2

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

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

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

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 by KingMotley · 2012-09-16 05:05 · Score: 1

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 by LostMyBeaver · 2012-09-16 05:14 · Score: 3, Informative

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

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

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

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

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

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 by yoshman · 2012-09-16 05:59 · Score: 2

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

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 by Bengie · 2012-09-16 07:38 · Score: 1

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 by Bill_the_Engineer · 2012-09-16 07:44 · Score: 1

Ah! You might find CISC dominant in radiation hard environments.
I've used PowerPC based CPUs in radiation environments without issues.

--
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Re:RISC is not the silver bullet by ZosX · 2012-09-16 08:12 · Score: 1

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.

--
zosxavius photography
Re:RISC is not the silver bullet by stripes · 2012-09-16 08:58 · Score: 1

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 by gagol · 2012-09-16 09:49 · Score: 1

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!

--
Tomorrow is another day...
Re:RISC is not the silver bullet by viperidaenz · 2012-09-16 11:35 · Score: 1

Modern? It's been that way for nearly 20 years
Re:RISC is not the silver bullet by viperidaenz · 2012-09-16 11:43 · Score: 1

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 by ZosX · 2012-09-16 11:55 · Score: 1

PPC is over 5ghz now. Quite competitive!

--
zosxavius photography
Re:RISC is not the silver bullet by tolkienfan · 2012-09-16 12:09 · Score: 1

What was I comparing?
Re:RISC is not the silver bullet by hajile · 2012-09-16 12:27 · Score: 1

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 by Pseudonym · 2012-09-16 12:33 · Score: 2

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

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:RISC is not the silver bullet by Snorbert+Xangox · 2012-09-16 14:19 · Score: 1

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

--
-Snorbert, somewhere in the antipodes
Re:RISC is not the silver bullet by unixisc · 2012-09-16 14:34 · Score: 1

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 by unixisc · 2012-09-16 14:43 · Score: 1

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 by unixisc · 2012-09-16 14:46 · Score: 1

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 by smash · 2012-09-16 14:54 · Score: 1

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.

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

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 by smash · 2012-09-16 14:55 · Score: 1

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

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

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 by LordLimecat · 2012-09-16 16:31 · Score: 1

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 by LordLimecat · 2012-09-16 16:32 · Score: 1

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 by reiisi · 2012-09-16 20:13 · Score: 1

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.

--
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Re:RISC is not the silver bullet by UnknowingFool · 2012-09-16 20:34 · Score: 1

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.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:RISC is not the silver bullet by dfghjk · 2012-09-16 23:50 · Score: 1

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 by dfghjk · 2012-09-16 23:53 · Score: 1

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 by dfghjk · 2012-09-16 23:59 · Score: 1

"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 by dfghjk · 2012-09-17 00:13 · Score: 1

"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 by dfghjk · 2012-09-17 00:27 · Score: 1

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 by Bengie · 2012-09-17 00:35 · Score: 1

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 by dfghjk · 2012-09-17 00:42 · Score: 1

"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 by dfghjk · 2012-09-17 00:43 · Score: 1

It's easy to say these things when you don't know anything.
Re:RISC is not the silver bullet by dfghjk · 2012-09-17 00:47 · Score: 1

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 by FrangoAssado · 2012-09-17 04:01 · Score: 1

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 by Guy+Harris · 2012-09-17 07:45 · Score: 1

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 by Guy+Harris · 2012-09-17 07:47 · Score: 1

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 by Guy+Harris · 2012-09-17 07:55 · Score: 1

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 by Guy+Harris · 2012-09-17 08:06 · Score: 1

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 by Guy+Harris · 2012-09-17 08:12 · Score: 1

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 by Guy+Harris · 2012-09-17 08:19 · Score: 1

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 by Guy+Harris · 2012-09-17 08:34 · Score: 1

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 by gagol · 2012-09-17 17:52 · Score: 1

Apple products with a mainframe.

--
Tomorrow is another day...
Re:RISC is not the silver bullet by Pseudonym · 2012-09-17 19:11 · Score: 1

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.

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Re:RISC is not the silver bullet by tolkienfan · 2012-09-18 00:22 · Score: 1

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 by gweihir · 2012-09-18 10:22 · Score: 1

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.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:RISC is not the silver bullet by Stuarticus · 2012-09-19 00:48 · Score: 1

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

--
If you think someone isn't free to have a different definition of "freedom" you may be a tyrant.

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

I'm glad Visual Studio also runs perfectly on Wine (I'm also making sure to have a party with my friends on Visual Studio 2012 Virtual Launch Party, where thousands of geeks around the globe connect together to party the release of latest Visual Studio).

I'm happy for you that you can develop more efficiently with Visual Studio, but I'm piffed that MyCleanPC still isn't available for Linux. I mean, I'm looking at my friend on his Windows box, and ever since he installed MyCleanPC, his gigabits are running faster than ever!

Plus, MyCleanPC completely eradicated any viruses on his computer, sped up his internet connection and gave him some peace of mind! We desperately need a Linux port of such outstanding software as MyCleanPC!

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

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

The x86 instruction set is pretty awful and Atom is a pretty lousy processor. But that's probably not due to RISC vs. CISC. IA32 today is little more than an encoding for a sequence of RISC instructions, and the decoder takes up very little silicon. If there really were large intrinsic performance differences, companies like Apple wouldn't have switched to x86 and RISC would have won in the desktop and workstation markets, both of which are performance sensitive.

I'd like to see a well-founded analysis of the differences of Atom and ARM, but superficial statements like "RISC is bad" don't cut it.

Re:oversimplified by PCK · 2012-09-16 03:02 · Score: 1

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 by aaron552 · 2012-09-16 03:03 · Score: 2

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

--
I had a sig once. It was lost in the great storm of '09.
Re:oversimplified by postbigbang · 2012-09-16 03:08 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by postbigbang · 2012-09-16 03:10 · Score: 1

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

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Anonymous Coward · 2012-09-16 03:13 · Score: 3, Interesting

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

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

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

Ok oddly enough this I agree with.
Re:oversimplified by gadzook33 · 2012-09-16 03:18 · Score: 2

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

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

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

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Re:oversimplified by postbigbang · 2012-09-16 03:26 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by lkcl · 2012-09-16 03:34 · Score: 5, Insightful

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

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 by MindlessAutomata · 2012-09-16 03:48 · Score: 1, Informative

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 by Zero__Kelvin · 2012-09-16 03:53 · Score: 4, Informative

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

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

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

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

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

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 by postbigbang · 2012-09-16 04:17 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by cheesybagel · 2012-09-16 05:30 · Score: 1

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 by Anonymous Coward · 2012-09-16 05:30 · Score: 1

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 by cheesybagel · 2012-09-16 05:31 · Score: 1

Servers, smartphones, and soon tablets.
Re:oversimplified by kenorland · 2012-09-16 06:05 · Score: 4, Interesting

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

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.

--
Bruce Perens.
Re:oversimplified by Bruce+Perens · 2012-09-16 06:30 · Score: 1

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.

--
Bruce Perens.
Re:oversimplified by Bruce+Perens · 2012-09-16 06:36 · Score: 1

Think of it: an S/360 mobile processor!

--
Bruce Perens.
Re:oversimplified by PCK · 2012-09-16 06:52 · Score: 2

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

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

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

but, if intel and AMD don't come out with a RISC-based (or VILW or other parallel-instruction) processor soon, they'll pay the price. intel bought up that company that did the x86-to-DEC-Alpha JIT assembly translation stuff (back in the 1990s) so i know that they have the technology to keep things "x86-like".
Erm, Intel had VLIW, remember Itanium? Other than in highly parallel number crunching workloads it was being outperformed by Intels own x86s. For general computing VLIW sucks, program execution is just too dynamc.
Re:oversimplified by ServereNerd · 2012-09-16 06:59 · Score: 1

"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 by marcosdumay · 2012-09-16 07:16 · Score: 1

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.

--
Rethinking email
Re:oversimplified by Carewolf · 2012-09-16 07:21 · Score: 1

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 by ghettoimp · 2012-09-16 07:22 · Score: 1
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 by Anonymous Coward · 2012-09-16 08:18 · Score: 3, Informative
For example, x86 has to implement memory snooping on page tables to automatically invalidate TLBs when the page table entry is modified by software, because there is no architectural requirement that software invalidate TLBs (and in fact no instructions to individually invalidate TLB entries, IIRC). Similarly, x86 requires data and instruction cache coherency, so there has to be a bunch of logic snooping on one cache and invalidating the other.
Err... Not quite:
- x86 TLBs aren't coherent with main memory; you need to do an explicit invalidate every time you change a PTE.
- The instruction to invalidate individual TLB entries is called invlpg, and was introduced with the 486. Admittedly, it's quite slow, so it doesn't get used much, but it is there.
- x86 has only very limited I-D cache coherence. You need to issue a serialising instruction whenever you modify anything which might have been cached in the I-cache.
Basically, there's nothing in the x86 architecture which is both frequently used and extravagantly difficult to implement performantly, at least on uniprocessor systems (although admittedly that's partly because Intel and AMD have spent an enormous amount of research effort solving all the hard problems). On the other hand, x86 does really suck for large (>64-ish core) SMP systems, because it mandates a very strong memory ordering model, and that is difficult to implement efficiently in very large systems (and there's good reason to suspect from the theory that that won't get much better in the near future).
Re:oversimplified by Olorion · 2012-09-16 08:34 · Score: 2

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

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.

--
I'm not a lawyer, but I play one on the Internet. Blog
Re:oversimplified by postbigbang · 2012-09-16 08:52 · Score: 3, Funny

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

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by postbigbang · 2012-09-16 09:07 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Nivag064 · 2012-09-16 09:37 · Score: 1

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 by Daniel+Phillips · 2012-09-16 09:45 · Score: 1

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.

--
Have you got your LWN subscription yet?
Re:oversimplified by kenorland · 2012-09-16 10:01 · Score: 1

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 by kenorland · 2012-09-16 10:07 · Score: 1

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 by MindlessAutomata · 2012-09-16 10:23 · Score: 1

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 by Daniel+Phillips · 2012-09-16 10:34 · Score: 1

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.

--
Have you got your LWN subscription yet?
Re:oversimplified by Bruce+Perens · 2012-09-16 10:39 · Score: 1

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.

--
Bruce Perens.
Re:oversimplified by Bengie · 2012-09-16 13:45 · Score: 1

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 by Bengie · 2012-09-16 14:03 · Score: 1

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 by Snorbert+Xangox · 2012-09-16 14:35 · Score: 1

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.

--
-Snorbert, somewhere in the antipodes
Re:oversimplified by kenorland · 2012-09-16 15:01 · Score: 1

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 by kenorland · 2012-09-16 15:04 · Score: 1

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 by Bruce+Perens · 2012-09-16 15:59 · Score: 1

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.

--
Bruce Perens.
Re:oversimplified by Bruce+Perens · 2012-09-16 16:36 · Score: 3, Informative

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

--
Bruce Perens.
Re:oversimplified by Daniel+Phillips · 2012-09-16 16:49 · Score: 1

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.

--
Have you got your LWN subscription yet?
Re:oversimplified by kenorland · 2012-09-16 17:00 · Score: 1

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 by kenorland · 2012-09-16 17:14 · Score: 1

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 by shiftless · 2012-09-16 17:18 · Score: 1

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 by Bruce+Perens · 2012-09-16 17:49 · Score: 1

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.

--
Bruce Perens.
Re:oversimplified by Ash-Fox · 2012-09-17 03:49 · Score: 1

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?

--
Change is certain; progress is not obligatory.
Re:oversimplified by kenorland · 2012-09-17 04:31 · Score: 1

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 by Bruce+Perens · 2012-09-17 05:27 · Score: 1

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.

--
Bruce Perens.
Re:oversimplified by Guy+Harris · 2012-09-17 08:42 · Score: 1

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 by Guy+Harris · 2012-09-17 08:53 · Score: 1

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 by postbigbang · 2012-09-17 09:08 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Guy+Harris · 2012-09-17 10:10 · Score: 1

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 by postbigbang · 2012-09-17 10:22 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Guy+Harris · 2012-09-17 10:40 · Score: 1

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 by Nivag064 · 2012-09-17 10:55 · Score: 1

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 by postbigbang · 2012-09-17 10:55 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Altrag · 2012-09-17 17:20 · Score: 1

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 by Phantom+Gremlin · 2012-09-17 19:11 · Score: 1

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 by aaron552 · 2012-09-18 01:29 · Score: 1

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.

--
I had a sig once. It was lost in the great storm of '09.
Re:oversimplified by postbigbang · 2012-09-18 12:09 · Score: 1

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.

--
---- Teach Peace. It's Cheaper Than War.
Re:oversimplified by Bert64 · 2012-09-21 10:49 · Score: 1

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.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Re:oversimplified by kenorland · 2012-09-21 20:49 · Score: 1

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 by Bert64 · 2012-09-23 02:04 · Score: 1

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.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Re:oversimplified by kenorland · 2012-09-23 14:35 · Score: 1

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.

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

Hell, I remember using an Archimedes in 1988. Odd to think that my phone now has four of them.

Back to the topic, the border between RISC and CISC is a bit fuzzy these days. Every modern CISC chip is basically a dynamic translator on top of a RISC core. But even high-end ARM chips can do some of this with Jazelle.

To be fair, CISC does have a few performance advantages when power consumption isn't (as big) an issue. The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely. ARM chips generally don't do out-of-order scheduling and retirement; that uses a lot of power, and is the main architectural difference between laptop-grade and desktop/server-grade x86en).

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

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

Re:The Year of Linux on Desktop Is Now by Goodyob · 2012-09-16 02:44 · Score: 1

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 by sunderland56 · 2012-09-16 02:45 · Score: 1

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 by Alex+Belits · 2012-09-16 03:16 · Score: 2

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

--
Contrary to the popular belief, there indeed is no God.
Re:Windows developers by Guy+Harris · 2012-09-17 09:03 · Score: 1

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 by UnknowingFool · 2012-09-16 02:47 · Score: 4, Interesting

Some here were immediately crying anti-trust and not understanding why Intel won't support Linux for Clover Tail. It's not an easy answer but power efficiency for Intel has been their weakness against ARM. If consumers had a choice between ARM based Android or Intel based Android, the Intel one might be slightly more powerful in computing but comes at the cost of battery life. For how tablets are used for most consumers, the increase in computing isn't worth the decrease in battery life. For geeks, it's worth it but general consumers don't see the value. Now if the tablet used a desktop OS like Windows or Linux, then the advantages are more transparent; however, the numbers favor Windows are there are more likely to be desktop Windows users with an Intel tablet than desktop Linux users with an Intel tablet. For short term strategy, it makes sense.

Long term, I would say Intel isn't paying attention. Considering how MS have treated past partners, Intel is being short-sighted if they want to bet their mobile computing hopes on MS. Also have they seen Windows 8? Intel based tablets might appeal to businesses but Win 8 is a consumer OS. So consumers aren't going to buy it; businesses aren't going to buy it. Intel may have bet on the wrong horse.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.

Re:Short term vs Long term thinking by Anonymous Coward · 2012-09-16 03:45 · Score: 1

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 by UnknowingFool · 2012-09-16 04:10 · Score: 1

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.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Short term vs Long term thinking by 0123456 · 2012-09-16 05:16 · Score: 4, Insightful

Oh, you're right. A company the size of Intel couldn't possibly spare one or two people for a few weeks to get support for their new power management into Linux.
Re:Short term vs Long term thinking by UnknowingFool · 2012-09-16 05:25 · Score: 1

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.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Short term vs Long term thinking by udippel · 2012-09-16 08:28 · Score: 1

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 by UnknowingFool · 2012-09-16 13:26 · Score: 1

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.

--
Well, there's spam egg sausage and spam, that's not got much spam in it.
Re:Short term vs Long term thinking by shiftless · 2012-09-16 17:24 · Score: 1

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 by Lisias · 2012-09-16 18:38 · Score: 1

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.

--
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org

HTML Media Capture is not widely supported by tepples · 2012-09-16 02:47 · Score: 1

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 by sgunhouse · 2012-09-16 05:21 · Score: 1

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. by guidryp · 2012-09-16 02:48 · Score: 5, Insightful

"ARM ends up being several times more efficient than Intel"

Wow. Someone suffered a flashback to the ancient CISC vs RISC wars.

This is really totally out to lunch. Seek out some analysis from actual CPU designers on the topic. What I read generally pegs the x86 CISC overhead at maybe 10%, not several times.

While I do feel it is annoying that Intel is pushing an Anti-Linux platform, it doesn't make sense to trot out ancient CISC/RISC myths to attack it.

Intel Chips have lagged because they were targeting much different performance envelopes. But now the performance envelopes are converging and so are the power envelopes.

Medfield has already been demonstrated at competetive power envelope in smartphones.

http://www.anandtech.com/show/5770/lava-xolo-x900-review-the-first-intel-medfield-phone/6

Again we see reasonable numbers for the X900 but nothing stellar. The good news is that the whole x86 can't be power efficient argument appears to be completely debunked with the release of a single device.

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

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

--
AntiFA: An abbreviation for Anti First Amendment.
Re:Sorry Bruce, but that is total nonsense. by recoiledsnake · 2012-09-16 03:25 · Score: 1

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.

--
This space for rent.
Re:Sorry Bruce, but that is total nonsense. by Truekaiser · 2012-09-16 03:51 · Score: 3, Informative

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

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. by kent.dickey · 2012-09-16 04:09 · Score: 2

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

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. by KonoWatakushi · 2012-09-16 06:19 · Score: 1

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. by Kjella · 2012-09-16 07:02 · Score: 1

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.

--
Live today, because you never know what tomorrow brings
Re:Sorry Bruce, but that is total nonsense. by symbolset · 2012-09-16 07:34 · Score: 2

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

--
Help stamp out iliturcy.
Re:Sorry Bruce, but that is total nonsense. by symbolset · 2012-09-16 07:37 · Score: 1

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

--
Help stamp out iliturcy.
Re:Sorry Bruce, but that is total nonsense. by Type44Q · 2012-09-16 08:04 · Score: 1

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. by udippel · 2012-09-16 08:37 · Score: 1

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. by ocularsinister · 2012-09-16 22:02 · Score: 1

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? by leromarinvit · 2012-09-16 02:49 · Score: 4, Insightful

Is it really true that x86 is necessarily (substantially) less efficient than ARM? x86 instruction decoding has been a tiny part of the chip area for many years now. While it's probably relatively more on smaller processors like Atom, it's still small. The rest of the architecture is already RISC. Atom might still be a bad architecture, but I don't think it's fair to say x86 always causes that.

Also, there is exactly one x86 Android phone that I know of, and while its power efficiency isn't stellar, the difference is nowhere near 4x. From the benchmarks I've seen, it seems to be right in the middle of the pack. I'd really like to see the source for that claim.

--
Proud member of the Ferengi Socialist Party.

Re:x86 to blame? by StripedCow · 2012-09-16 03:22 · Score: 1

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.

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Re:x86 to blame? by leromarinvit · 2012-09-16 03:35 · Score: 1

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.

--
Proud member of the Ferengi Socialist Party.
Re:x86 to blame? by Anonymous Coward · 2012-09-16 08:08 · Score: 1

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? by viperidaenz · 2012-09-16 13:44 · Score: 1

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

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

just send me the hardware.

Re:Linux-proof? Challenge Accepted! by Teresita · 2012-09-16 02:58 · Score: 1

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! by Anonymous Coward · 2012-09-16 03:06 · Score: 1

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 by PCK · 2012-09-16 02:53 · Score: 1

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:Blast in time by TheRaven64 · 2012-09-16 02:54 · Score: 4, Informative

Every modern CISC chip is basically a dynamic translator on top of a RISC core.

And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.

But even high-end ARM chips can do some of this with Jazelle.

Jazelle has been gone for years. None of the Cortex series include it. It gave worse performance to a modern JIT, but in a lower memory footprint. It's only useful when you want to run Java apps in 4MB of RAM.

The code density is better on x86 (yes, even with Thumb), which does mean they tend to use instruction cache more effecitvely

That's not what my tests show, in either compiled core or hand-written assembly.

--
I am TheRaven on Soylent News

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

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

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

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

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

.. and the reason is not efficiency or performance.. Intel enjoys huge (50%+) margins on x86 CPUs that simply will not be tolerated by the tablet or mobile device vendors. Contrast this with the pennies that ARM and their fab partners make for each unit sold. Even Intel's excellent process tech can't save them cost wise when you can get a complete ARM SoC with integrated GPU for $7.

--
For all intensive porpoises your a bunch of rediculous loosers

Steam the new Unreal Tournament?? by Andy+Prough · 2012-09-16 03:04 · Score: 1

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?? by Anonymous Coward · 2012-09-16 03:24 · Score: 2, Informative

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

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

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

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

Visual Studio

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

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

Re:Thanks by Anonymous Coward · 2012-09-16 03:22 · Score: 1

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:The Year of Linux on Desktop Is Now by thegreatemu · 2012-09-16 03:23 · Score: 1

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? by fermion · 2012-09-16 03:25 · Score: 4, Informative

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

So this OS specific chip is nothing new, and *nix exclusion is not new. Many microcomputers could not run *nix because they did not have a PMMU. The ATT computer ran a 68K processor with a custom PMMU. Over the past 10 years there have been MS Windows only printers and cameras which offloaded work to the computer to make the peripheral cheaper.

Which is to say that there are clearly benefits for RISC and CISC. MS built and empire on CISC, and clearly intends to continue to do so, only moving to RISC on a limited basis for high end highly efficient devices. For the tablet for the rest of us, if they can ship MS Windows 8 on a $400 device that runs just like a laptop, they will do so., If efficiency were the only issue, then we would be running Apple type hardware, which, I guess, on the tablet we are. But while 50 million tablets are sold, MS wants the other 100 million laptop users that do not have a tablet, yet, because it is not MS Windows.

--
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black

Come on Bruce by Anonymous Coward · 2012-09-16 03:26 · Score: 1

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... by StripedCow · 2012-09-16 03:28 · Score: 1

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

--
If Pandora's box is destined to be opened, *I* want to be the one to open it.

Intel has to go mobile by bigt405 · 2012-09-16 03:29 · Score: 1

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.

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

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

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

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

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

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

Re:Only benefits.. by Dwedit · 2012-09-16 03:39 · Score: 1

You want a good x86-only Linux program? Wine. There's a good one for you.
Re:Only benefits.. by smash · 2012-09-16 04:09 · Score: 1

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.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Re:Only benefits.. by KiloByte · 2012-09-16 04:19 · Score: 1

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

--
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Re:Only benefits.. by pclminion · 2012-09-16 04:48 · Score: 1
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.. by Bruce+Perens · 2012-09-16 05:52 · Score: 1

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.

--
Bruce Perens.
Re:Only benefits.. by Bert64 · 2012-09-20 20:35 · Score: 1

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.

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

Re:Blast in time by Truekaiser · 2012-09-16 03:34 · Score: 1

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.

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

If nobody wants it and it's a dead-end for technical and business reasons, then how come that there is a slew of x86 Win8 devices announced by different manufacturers - including guys such as Samsung, who don't have any problems earning boatloads of money on Android today?

Heck, it's even funnier than that - what about Android devices already running Medfield?

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

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

Manufacturer announced devices != customer purchased devices.

--
Bruce Perens.
Re:Reality check by marcosdumay · 2012-09-16 07:48 · Score: 1

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?

--
Rethinking email
Re:Reality check by shutdown+-p+now · 2012-09-16 14:22 · Score: 1

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 by shutdown+-p+now · 2012-09-16 14:25 · Score: 1

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 by shutdown+-p+now · 2012-09-16 14:43 · Score: 1

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 by Bruce+Perens · 2012-09-16 14:58 · Score: 1

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.

--
Bruce Perens.

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

Like I posted elsewhere, intel hasn't made real CISC processors for years, and I don't think anyone has. Modern Intel processors are just RISC with a decoder to the old CISC instruction set.

Exactly. Intel has been doing this ever since the Pentium Pro and Pentium II came out in the 1990s. Anyone who knows much at all about x86 CPUs is aware of this, and Perens certainly will be. That's why I'm surprised that that article misleadingly states:-

So, we start with the fact that Atom isn't really the right architecture for portable devices (*) with limited power budgets. Intel has tried to address this by building a hidden core within the chip that actually runs RISC instructions, while providing the CISC instruction set that ia32 programs like Microsoft Windows expect.

The "hidden core" bit is, of course, correct, but the way it's stated here implies that this is (a) something new and (b) something that Intel have done to mitigate performance issues on such devices, when in fact it's the way that all Intel's "x86" processors have been designed for the past 15 years!

Perhaps I'm misinterpreting or misunderstanding the article, and he's saying that- unlike previous CPUs- the new Atom chips have their "internal" RISC instruction set directly accessible to the outside world. But I don't think that's what was meant.

(*) This is in the context of having explained why IA32 is a legacy architecture not suited to portable devices and presented Atom as an example of this.

--
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).

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

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

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.

--
If it weren't for deadlines, nothing would be late.
Re:Misleading slant on mention of Atom's RISC core by isorox · 2012-09-16 17:51 · Score: 1

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 by reiisi · 2012-09-16 19:38 · Score: 2

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

--
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Re:Misleading slant on mention of Atom's RISC core by Guy+Harris · 2012-09-17 07:43 · Score: 1

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 by MysteriousPreacher · 2012-09-16 03:39 · Score: 3, Funny

This is better:

http://fix-kit.com/Explosive-diarrhea/repair/
http://fix-kit.com/Assassination-of-reigning-monarch/repair/

Finally, downloadable software for Windows that'll cure just about anything!

I imagine /. readers are savvy enough to realise that the site is a scam, and that downloading their software is akin to having unprotected sex with third-world prostitutes.

--
-- Using the preview button since 2005

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

So does it matter when someone sends you a .pptx file that Office 2003 freezes on? Yeah, yeah, I'm pretty sure you can get a converter, but I like telling people that if their file has an 'x' in the extension it means that it's 'experimental' and they shouldn't send it to others. They need to send the version without the 'x'.

--
Faster! Faster! Faster would be better!

Re:The Year of Linux on Desktop Is Now by MindlessAutomata · 2012-09-16 03:45 · Score: 1

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 by smash · 2012-09-16 03:45 · Score: 1

No wireless. Less space than a nomad. Lame.

I predict clover trail will be a roaring success.

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

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

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

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

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

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

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

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

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

Re:The Year of Linux on Desktop Is Now by Vince6791 · 2012-09-16 03:53 · Score: 1

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? by zman58 · 2012-09-16 03:55 · Score: 2

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

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

Re:Thanks by stripes · 2012-09-16 04:01 · Score: 1

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?

Re:Visual Studio is great, but what about MyCleanP by Anonymous Coward · 2012-09-16 04:03 · Score: 1

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

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

Getting back on topic: the last ARM architecture, ARMv8, is far from what was called "RISC" back in the '70s. E.g. it can run instructions of different sizes (16 vs 32 bit), it has 4 specialized instructions for AES, registers with different sizes (32, 64 and 128 bits), instructions for running a subset of the Java bytecode, a rich set of SIMD operations and specialized instructions for SHA-1 and SHA-256.

Similarily the architecture supported by the new Atom chips (which is AMD64/x86-64 BTW, IA32 is only present for backward compatibility) is almost universally run on RISC-like processors that have instruction translators. Considering that the increased density of the x86-64 instructions usually allows to save more cache transistors than the ones required for decoding the instructions themselves, I think that the power consumption differences that we see are more due to the implementation and different traditional focus areas of ARM vs Intel/AMD than inherent differences in the instruction sets.

--
There's a hidden treasure in Python 3.x: __prepare__()

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

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

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 by Bruce+Perens · 2012-09-16 05:19 · Score: 5, Insightful

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

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

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

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

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

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

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

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.

--
zosxavius photography
Re:ARM is not RISC and x86-64 is not CISC by Darinbob · 2012-09-16 08:52 · Score: 2

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

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 by nastav · 2012-09-16 09:24 · Score: 1

I hope somebody mods parent Insightful.

--
-- obligatory (but true) caveat: my comments my own, and don't reflect my employer or colleagues' positions.
Re:ARM is not RISC and x86-64 is not CISC by default+luser · 2012-09-16 11:23 · Score: 2

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

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

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

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.

--
Bruce Perens.
Re:ARM is not RISC and x86-64 is not CISC by WilliamBaughman · 2012-09-16 13:12 · Score: 1

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 by unixisc · 2012-09-16 13:34 · Score: 2

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

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.

--
Bruce Perens.
Re:ARM is not RISC and x86-64 is not CISC by WilliamBaughman · 2012-09-16 16:19 · Score: 1

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 by Bruce+Perens · 2012-09-16 16:30 · Score: 1

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,

--
Bruce Perens.
Re:ARM is not RISC and x86-64 is not CISC by WilliamBaughman · 2012-09-16 18:07 · Score: 1

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 by WilliamBaughman · 2012-09-17 05:58 · Score: 1

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 by KugelKurt · 2012-09-18 10:24 · Score: 1

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 by crutchy · 2012-09-18 20:21 · Score: 1

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 by crutchy · 2012-09-18 20:23 · Score: 1

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/

Re:Blast in time by YA_Python_dev · 2012-09-16 04:21 · Score: 1

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.

--
There's a hidden treasure in Python 3.x: __prepare__()

Re:The Year of Linux on Desktop Is Now by fm6 · 2012-09-16 04:22 · Score: 1

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

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

For me, the year of linux on desktops is now. With Steam coming to Linux [steampowered.com], along with Crossover and pure Linux-ported games, the inevitable has happened. I'm glad Visual Studio [microsoft.com] also runs perfectly on Wine (I'm also making sure to have a party with my friends on Visual Studio 2012 Virtual Launch Party, where thousands of geeks around the globe connect together to party the release of latest Visual Studio).

A bit of "linux on the desktop" ass-licking, followed by a big, fat Visual Studio plug.

Ladies and gents, we have a shill. A very smart one, but a shill none the less. Modded up by a few other plants, no doubt.

--
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.

Re:The Year of Linux on Desktop Is Now by hack++slash · 2012-09-16 04:31 · Score: 1

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

--
To do something right, you often have to roll up your sleeves and get busy.

Re:The Year of Linux on Desktop Is Now by kelemvor4 · 2012-09-16 04:43 · Score: 1

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 by jd2112 · 2012-09-16 04:50 · Score: 3, Funny

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

--
Any insufficiently advanced magic is indistinguishable from technology.

Re:Blast in time by TheRaven64 · 2012-09-16 04:54 · Score: 1

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.

--
I am TheRaven on Soylent News

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

Every modern CISC chip is basically a dynamic translator on top of a RISC core.

And that's the problem for power consumption. You can cut power to execution units that are not being used. You can't ever turn off the decoder ever (except in Xeons, where you do in loops, but you leave on the micro-op decoder, which uses as much power as an ARM decoder) because every instruction needs decoding.

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

Re:Visual Studio is great, but what about MyCleanP by jkflying · 2012-09-16 05:12 · Score: 1

Whoosh!

--
Help I am stuck in a signature factory!

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

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

--
To do something right, you often have to roll up your sleeves and get busy.

Between now and January 1st.. by Paracelcus · 2012-09-16 06:01 · Score: 1

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.

--
I killed da wabbit -Elmer Fudd

Linux Proof? by nitehawk214 · 2012-09-16 06:07 · Score: 1

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

--
I'm a good cook. I'm a fantastic eater. - Steven Brust

Visual Studio 2012 Has Worst UI Of All Time by Anonymous Coward · 2012-09-16 06:13 · Score: 1

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 by godefroi · 2012-09-17 04:57 · Score: 1

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.

--
Karma: Poor (Mostly affected by lame karma-joke sigs)

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

This is from an Intel rep:

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

Just quoting, believe what you want.

--
Breakfast served all day!

Re:Here is what Intel says by gl4ss · 2012-09-16 07:13 · Score: 1

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

--
world was created 5 seconds before this post as it is.

Re:Blast in time by Anonymous Coward · 2012-09-16 06:18 · Score: 1

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:The Year of Linux on Desktop Is Now by gl4ss · 2012-09-16 07:02 · Score: 1

should mod +5 funny instead of -1 troll.

virtual launch party should clue that in.

--
world was created 5 seconds before this post as it is.

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

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

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

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

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

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

not a problem by JustNiz · 2012-09-16 07:30 · Score: 1

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

Re:Visual Studio is great, but what about MyCleanP by ZosX · 2012-09-16 07:56 · Score: 1

omg..i'm dying here

--
zosxavius photography

1/4th? No... by Guspaz · 2012-09-16 08:15 · Score: 1

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 by ultrasawblade · 2012-09-16 08:22 · Score: 1

"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 by ultrasawblade · 2012-09-16 08:25 · Score: 4, Informative

Furthermore a distinguishing feature of CISC vs. RISC is number of general purpose registers. RISC always tried to do everything in registers and treat RAM as an I/O device, instead of stuff like "load accumulator with value in RAM and write it back to RAM" or "load this register with this value from RAM, multiply it with the value in this register, then store it back to RAM." - there are many instructions like this in CISC architectures that encourage treating RAM as just as good for temporary storage as registers - which, of course, it hasn't been for a long time now.

Intel has become more RISCy with MMX/SSE and now with the amd64 extensions that give it 8 more general purpose registers.

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

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

--

My sig is too lon

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

Everyone has a RISC style core nowdays because RISC essentially won. People don't understand what RISC was all about though, they tend to think it's about instruction set complexity or microcoding. No, the concept is about putting the CPU resources in places where it matters, eliminating less useful parts of the processor, discarding the accepted design wisdom of the 70s, etc. RISC wasn't even that new or radical an idea, except for the big machine makers. Seymour Cray was using some RISC concepts before the RISC term was invented.

If power consumption is not an issue then code density most likely is not an issue either. Use the space taken up by the decoder and use it for a larger instruction cache or buffer instead. The sole reason the complex decoder is there is for instruction sets that were designed to be hand written by humans. The x86 instruction set was absolutely not created with performance in mind, it was designed as a long series of backwards compatible incremental changes, starting from the original 4004 chip. Every chip since then in the ancestry kept some compatibility to make code easier to convert to the new processors.

Yes it is true that back in the 70s and 80s when this stuff was new that memory was very small and very slow and very expensive. RISC came about in the era when memory stopped being the most expensive part of a computer.

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

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

Re:The Year of Linux on Desktop Is Now by TheDarkMaster · 2012-09-16 10:59 · Score: 1

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

--
Religion: The greatest weapon of mass destruction of all time

CISC vs RISC by Chas · 2012-09-16 11:30 · Score: 1

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.

--

Chas - The one, the only.
THANK GOD!!!

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

I couldn't agree more. This is absolutely not a matter of CISC (-frontend with a RISC backend) vs. RISC; it's about Intel (and AMD?) withholding hardware specifications of a particular subsystem of their new chips. That's not a technological issue, it is a purely economic/political... and maybe even legal one in some parts of the world (antitrust behavior, anybody?).
IMHO, it looks and smells like MSFT having signed a deal with Intel and AMD to lock down the x86 tablet platform to Win8. This complements nicely the UEFI lockdown on ARM tablets they have signed with hardware manufacturers with Win8 offerings. Nothing really surprising.

--
cpghost at Cordula's Web.

Re:Blast in time by hajile · 2012-09-16 12:10 · Score: 1

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

I'm not doing things your way today by Bruce+Perens · 2012-09-16 12:17 · Score: 1, Insightful

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.

--
Bruce Perens.

Re:Blast in time by Pseudonym · 2012-09-16 12:20 · Score: 1

In my defence, I did say "generally".

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

What would a low power Alpha have been like? by unixisc · 2012-09-16 13:55 · Score: 1

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 by exomondo · 2012-09-16 14:00 · Score: 1

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 by unixisc · 2012-09-16 14:20 · Score: 1

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 by unixisc · 2012-09-16 14:28 · Score: 1

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

Re:Yes but closed-source x86 binaries usually... by smash · 2012-09-16 16:05 · Score: 1

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

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

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

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

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

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

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

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

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

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

Apple ditched on us, not just on RISC. by reiisi · 2012-09-16 20:04 · Score: 1

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.

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

Try this for a reality check. by reiisi · 2012-09-16 20:17 · Score: 1

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.

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

Re:Try this for a reality check. by smash · 2012-09-17 15:38 · Score: 1

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

--
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.

IA64? by reiisi · 2012-09-16 20:20 · Score: 1

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.

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

Re:IA64? by kenorland · 2012-09-17 04:16 · Score: 1

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, ... by reiisi · 2012-09-16 20:26 · Score: 1

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.

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

such a waste by reiisi · 2012-09-16 20:33 · Score: 1

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

But it's such a waste.

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

Re:Blast in time by TheRaven64 · 2012-09-16 20:49 · Score: 1

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.

--
I am TheRaven on Soylent News

Re:Blast in time by Alioth · 2012-09-16 21:51 · Score: 1

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.

--
Oolite: Elite-like game. For Mac, Linux and Windows

Please elaborate? by Medievalist · 2012-09-17 01:11 · Score: 1

...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 by CRCulver · 2012-09-17 02:01 · Score: 1

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.

Corrections... by TemporalBeing · 2012-09-17 07:13 · Score: 1

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.

--
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)

Re:But x64 is RISC, not counting 32-bit instructio by Guy+Harris · 2012-09-17 07:39 · Score: 1

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

big bias no whammies by FyberOptic · 2012-09-17 12:16 · Score: 1

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.

Slashdot Mirror

The Linux-Proof Processor That Nobody Wants

303 of 403 comments (clear)