Live data from Hacker News

X86's Days as a Consumer Microarchitecture are Numbered

plus.google.com

51–60 of 81 posts

Re: X86's Days as a Consumer Microarchitecture are Numbered

#51

This is an largely vapid and meaningless prediction by someone who doesn't demonstrate anything but the most superficial knowledge of the microprocessor industry. Perhaps he knows something we don't, but as far as I can tell he's only extrapolating current market trends. Obviously Intel (once led by Andy Grove, author of "Only the Paranoid Survive") is aware of the threat posed by ARM. If someone could explain how In…

Hello, I'm the author of this article. I do not have a degree in electrical or computer engineering. I'm merely stating the trends I've seen in the PC industry over the last few years. I am, however, a Software Engineer. I know that most of the perceived lag on a modern desktop is not due to the CPU, but inefficient I/O to the hard disk or network. One must only look at the iPad 2 too see that's very possible to make…

>"Unless you know something I don't."

Based upon history, reports of the x86's death have been greatly exaggerated - since the late 1980's.

Here's a nice 1999 article from Ars: [http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html]

and the archive.org version for those without IE4 or Netscape Navigator: [http://web.archive.org/web/19991129051550/http://arstechnica...]

Floating Point operations are an example of the hurdle faced by the RISC processors such as ARM - RISC ideology suggests that dedicated FPU hardware and instructions should not be used despite the performance hit that software implementations incur.

On the other hand, the x86 CISC approach has allowed for increased integration based on changing market demands over the past 20 years (e.g. FPU integration with the 80486 in 1989 and MMX in 1996 on the Pentium).

That sort of flexibility has advantages.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#52

I think in a lot of ways this is related to the relative overpowering of desktop computers for daily use. It's been true for years now that computers are highly overpowered for what they are typically used for. Quad core machine with a million gigs of ram for email and a web browser? Sure there are LOTS of good reasons for having legitimate CPU power, but a lot of times any random Ghz level processor is going to prov…

> Quad core machine with a million gigs of ram for email and a web browser?

Sure, web browsers nowadays do much more than rendering html. It's actually among the most complex software package that your computer runs. Especially the high amounts of memory do not go to waste for a heavy web user.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#53
There are many reasons why the current status quo won't change so soon and an important one is because ARM still lacks 64-bit addressing. Servers have long made the jump to 64-bit, so has most of the consumer-grade computers.

Without 64-bit support from its competitors, Intel doesn't have much to fear, especially in the datacenter space, where performance per watt is a powerful selling point.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#54
post #42
post #38

Earlier quoted context omitted.

I know that most of the perceived lag on a modern desktop is not due to the CPU, but inefficient I/O to the hard disk or network Most perceived lag on a modern desktop comes from excessive abstraction which results in poor coding practices. You could certainly argue that IO bottlenecks or a lack of system resources will certainly have an impact but that impact wont be realized until the environment is somewhat satura…

Most perceived lag on a modern desktop comes from excessive abstraction which results in poor coding practices. This is worthless without actual numbers, which I doubt you have. Hardware people blame software, software people blame hardware, as it has always been, so mote it be, amen.

If you want numbers, try comparing the stack depth in a modern application's event handler to those from 10 years ago. Qt4 alone, for example, routinely approaches 50 calls deep just to update a canvas in response to a mouse event. Add to that a dozen or more layers between the compositing manager, window manager, X, display driver, and the kernel, and the end-to-end latency climbs through the roof.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#55

This reads like a person who has been saying "RISC beats CISC" since the Apple-on-PowerPC days because of ideological opinions about elegance, and is looking for any excuse to re-express that viewpoint. Look, I still think microkernels are better than monolithic kernels, but you don't see me claiming Linux is doomed just because the L4 microkernel is running on 300 million mobile phones worldwide ( http://en.wikipedi…

X86 is not going away, I agree, but Intel can hardly exercise the kind of dominance they've enjoyed for the last several years when they're facing serious threats at both the low and high end. At the low end, ARM simply beats x86 for anything with a battery. Intel has already lost the phone and tablet markets, and laptops are highly likely to follow. At the high end, look at the http://top500.org/ . #1 is based on SP…

> At the low end, ARM simply beats x86 for anything with a battery.

I've seen this claim often, yet I could not find any sources that could back up this claim. Can you post a link to an article or some research that compares performance/watt (as well as actual power usage) between ARM and x86? I'm genuinely interested in this.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#56

Earlier quoted context omitted.

Leakage power is actually very significant part of the total power usage [1] and one of the bigger reasons why Intel developed the tri-gate technology [2]. Active power is the one that's related to the frequency (P ~= CV^2f). Leakage power will "leak" even if the transistor is not switching. 1. http://www.eetimes.com/electronics-news/4215605/Leakage-powe... 2. http://realworldtech.com/page.cfm?ArticleID=RWT0505111954…

Not sure what you mean by significant, but typical leakage power numbers are something like 15-30% of total power. Maybe you're referring to some papers that used to come out a few years ago which suggested that leakage power will dominate total power. As I said above, this is unlikely to happen. It doesn't make sense to operate at a combination of supply voltage (Vdd) and threshold voltage (Vt) where leakage dominat…

The papers I've seen point to values larger than 15~30% - I've seen ~50% cited for geometries as large as 65nm, only to get worse as we go to even smaller feature sizes. [1]

Threshold voltage is not really an effective knob, unless you assume that the feature size to be a knob and go against Moore's law, or that brand new, once in 10-years process innovation is a knob that designers can pick out of a hat. I don't think anyone's clamoring for return to 130nm parts on a smartphone. At each new process node, you're going to lose out on the amount of control you'll have over Vth.

This is basically what Intel did with the tri-gate transistors which gives them longer lease on life until they bump against subthreshold leakage. TSMC is on their first generation high-k metal gates, and still a process node or two away before jumping over to the tri-gate party.

1. http://www.eetimes.com/design/eda-design/4211228/Overcoming-...

Re: X86's Days as a Consumer Microarchitecture are Numbered

#57
post #48
post #25

Earlier quoted context omitted.

One rule of thumb I've seen writers on Anandtech express several times is that any given microarchitecture can cover at most about one order of magnitude for power consumption. This leads to laptop/desktop-oriented microarchitectures that can scale at most from about 13W to 130W by tweaking clock speeds and voltage. More recently, the high end has dropped down to at most about 95W for non-server chips, but it still m…

>lost a lot of ground to the Athlon 64 before they could come up with a high-performance successor to the Pentium M. You realize that Intel's EMT-64 is effectively AMD-64, right? Intel, which loathed that cross-patent deal, is now reaping AMD's rewards. Core2 and later series processors are all using AMD's intellectual property (legally).

Intel is most certainly not using AMD's architecture, they are using AMD's instruction set, yes, but they internals have nothing to do with AMD's designs. The Core series was an evolution of the Pentium M which was based on the Pentium III architecture.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#58
post #48
post #25

Earlier quoted context omitted.

One rule of thumb I've seen writers on Anandtech express several times is that any given microarchitecture can cover at most about one order of magnitude for power consumption. This leads to laptop/desktop-oriented microarchitectures that can scale at most from about 13W to 130W by tweaking clock speeds and voltage. More recently, the high end has dropped down to at most about 95W for non-server chips, but it still m…

>lost a lot of ground to the Athlon 64 before they could come up with a high-performance successor to the Pentium M. You realize that Intel's EMT-64 is effectively AMD-64, right? Intel, which loathed that cross-patent deal, is now reaping AMD's rewards. Core2 and later series processors are all using AMD's intellectual property (legally).

Yes. Intel has more than made up for the mess they were in circa 2003-2005, but the fact remains that AMD was able to truly embarrass Intel for quite some time, both by beating Intel to market with several new technologies, and by significantly eroding Intel's market share for desktop and server chips.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#59

This reads like a person who has been saying "RISC beats CISC" since the Apple-on-PowerPC days because of ideological opinions about elegance, and is looking for any excuse to re-express that viewpoint. Look, I still think microkernels are better than monolithic kernels, but you don't see me claiming Linux is doomed just because the L4 microkernel is running on 300 million mobile phones worldwide ( http://en.wikipedi…

X86 is not going away, I agree, but Intel can hardly exercise the kind of dominance they've enjoyed for the last several years when they're facing serious threats at both the low and high end. At the low end, ARM simply beats x86 for anything with a battery. Intel has already lost the phone and tablet markets, and laptops are highly likely to follow. At the high end, look at the http://top500.org/ . #1 is based on SP…

Who cares what the top supercomputers are powered by, what matters is the market. I'm fairly certain that numerical simulation systems do not dominate the high-end computer market. Instead, it's still all about servers that spend most of their time shuffling data around, which intel platforms still do quite well at.

Additionally, intel still has plenty of time to get up to pace in the mobile market. The tablet market is as yet largely untapped, especially globally. I wouldn't be surprised if next gen atom processors made their way into leading edge tablets in the next few years, for example.

Generally speaking: forecasts that require intel to roll over and take a massive beating while billions upon billions of business leaks away to its competitors don't tend to pan out in reality. The only way that works is if intel goes bankrupt the instant a competitor comes on the scene, and that's just fantasy.

Re: X86's Days as a Consumer Microarchitecture are Numbered

#60
post #42

Earlier quoted context omitted.

Most perceived lag on a modern desktop comes from excessive abstraction which results in poor coding practices. This is worthless without actual numbers, which I doubt you have. Hardware people blame software, software people blame hardware, as it has always been, so mote it be, amen.

If you want numbers, try comparing the stack depth in a modern application's event handler to those from 10 years ago. Qt4 alone, for example, routinely approaches 50 calls deep just to update a canvas in response to a mouse event. Add to that a dozen or more layers between the compositing manager, window manager, X, display driver, and the kernel, and the end-to-end latency climbs through the roof.

I hope that the end of higher Ghz processors will make it viable again to optimize for code performance instead of optimized for developer time.
Post reply on HN