The Quest for More Processing Power

Hack Jandy writes "AnandTech has a very thorough, but not overly technical, article detailing CPU scaling over the last decade or so. The author goes into specific details on how CPUs have overcome limitations of die size, instruction size and power to design the next generation of chips. Part I, published today, talks specifically about the limitations of multiple cores and multiple threads on processors."

There can only be one

[2.7182 (819680)]

the quantum computer!! Until then we'll have to suck it up with these Si things.

Re:There can only be one

[2.7182 (819680)]

Actually, quantum mechanics is already modelled with an infinite dimensional Hilbert space, which is why quantum computing is so fast.

Re:There can only be one

[2.7182 (819680)]

You mean like something useful ? How about modelling weather or geophysical phenomenon or solving Maxwell's equations ? There are a zillion things like that could be amazingly better if we could speed them up. People forget too easily about scientific computing!

We don’t need more “power”

[Pan T. Hose (707794)]

What we need is a better architecture which would allow for a better implementation of algorithms. Will we ever have an MMIX [stanford.edu]-like processor with 256 general-purpose 64-bit registers that each can hold either fixed-point or floating-point numbers? That is what I am waiting for, not more "power," whatever that means.

Re:We don’t need more “power”

[LiquidCoooled (634315)]

Didn't the powerpc have something approaching this.
I remember the old motorola 68000 range having 16 32bit regs for general coding, and one of the prime benefits of the ppc was the vastly greater registry capacity.

I stopped coding assembler when I moved to x86 - what a horrible cludge of a stack stack biased platform it is.

Re:We don’t need more registers

[cnettel (836611)]

Ok, classic x86 is cramped and the CPU does a lot of register renaming to get around it. I don't agree that more registers would actually do that much good.

What kind of algorithm are you imagining would benefit from 256 fields of non-vectorized data?

Of course, those registers could be used in larger things for everything that's worthy of a local variable, but as soon as you run into a stack operation you'll either only want to push a subset of the registers to the stack, or face a harder blow of memory access times by making each function call a 2048 byte write to memory.

Explicit encoding of parallelism, hints to branch prediction, and similar stuff, seems far more appropriate.

Again, few single functions in an imperative language have 256 separate variables, without involving arrays of data. Unless the register file is addressable by index from another register (basically turning it into a very small addressed memory, which is whta you try to avoid with registers), you have little use for 256 of them. Take for example a trivial string iteration algorithm, most of those registers would be completely useless. The same holds true for common graph algorithms.

Re:We don’t need more registers

[Jeff DeMaagd (2015)]

Ok, classic x86 is cramped and the CPU does a lot of register renaming to get around it. I don't agree that more registers would actually do that much good.

It does. Take a look at x86-64. The 98% reason 64 bit x86 code is faster when you are using less than 4 gigs of RAM is the fact it has double the registers. With the same number of registers, 64 bit code normally slows things down measurably because the pointer size doubled. The instruction word length doesn't change.

256 registers goes a bit far unless half of them are predication bits.

Re:We don’t need more registers

[cnettel (836611)]

Read my own clarification response above yours, I intended to write that x86 is cramped by its register count (and the further restrictions on what to use when), but that 256 is very, very much.

The Itanium has a huge file with, IIRC, even more registers in total. They are not inter-changeable, though, but the (almost) only point in that would be to keep the total number of registers down, while being flexible for most types of code. As I think that it's generally actually easier to make them separate for different execution units, that's not very interesting. Also, note that the Itanium currently has a 2-cycle (again, IIRC) register access time! They tried to be visionary, adding a huge register set, in addition to some parallelism encoding and other things I mentioned in the parent, but they traded (what seems to be) far too much to get it.

A huge (defined as MMIX-like, not AMD64-like)register file might be great, but you need selective register pushing to stack to get away with it, unless you or the compiler are performing very aggressive inlining. What's easier, if you're doing assembler -- calling a function and put a local on the stack or writing a huge fricking implementation of your main algorithm, taking great care to use all different registers in each function inlining?

Re:We don’t need more “power”

[dnoyeb (547705)]

True. These dual core CPUS are an indication that they are having difficulty increasing their CPU throughput.

As with dual CPU motherboards, you go to dual, when you cant get anything else out of the single...

10GHz CPU, lol. Why not release one that requires a 100GHz clock? If its only processing every 30th cycle, whats the big deal? Oversimplification I know, but that is the essence of Intels laughable strategy. Consumer ignorance vs. product innovation. Well take the ignorance. How long can it las

Re:We don’t need more “power”

[Leroy_Brown242 (683141)]

Smart power, not more power? How unamerican!

TERRORIST!

More power will lead to more bloat..

[klang (27062)]

That's what's been happening the last 10-15 years. Where are the indications that "time to market" and "sloppy programming" will suddenly vanish?

Pun

[2.7182 (819680)]

From my point of view, chips lead to more bloat.

Re:More power will lead to more bloat..

[Rinikusu (28164)]

Because, overwhelmingly, no one really cares but a handful of people. The days of hand-tweaked, ASM optimized code are pretty much over for consumer code. Yes, there will always be a market, but it is ever diminishing with the size of market expanding. To use analogies, look at furniture. Go to just about any furniture "gallery" positioned for the great American unwashed and you'll find several hundred, almost identical mass-produced fat-ass-cliners, some with machine stitched leather, some with vinyl, some with cloth, etc. Dressers and other cabinetry are stapled, nailed, screwed and glued with machine precision accuracy. The demand for hand-built, crafted furniture has dropped tremendously (and the prices for these craft pieces seems to have gone up.. ). Yes, a "hand-tweaker" coder will probably find work with a small shop somewhere, or create their own consultancy for constituents who demand that kind of programming, and chances are that coder will make quite a bit more than the average, churn and burn programmer (people like me), but for the overwhelming majority, it's overkill.

(Here's a simple cost analysis: We can pay this guy $100k/year to do hand-optimized tweaks on this code that then becomes a liability for future maintanence if that coder dies, quits, or whatever. Or, we could add another stick of $100 RAM, and buy a new processor next year for a fraction of his cost and get a similar performance bump... The math doesn't add up...)

Re:More power will lead to more bloat..

[EvilTwinSkippy (112490)]

Hey, I shop at Ikea. The stuff isn't event assembled. It's a flat box full of precision cut boards with bolts and one of those funky allen keys.

Getting back to your point, there is still a market for hand-coders. With most consumer electronics, I'm talking kid's toys, alarm clocks, talking dolls, you try to shave off every penny you can in manufacturing costs. Plus, once you start a product line, you run it out for years.

In that case, of high volume and low cost, it is easy to absorb the cost of a $100,000 hand coder. Especially if he can save you $0.10 a unit on lines where volume is measured in the millions of units.

Besides, most of the "hand coders" I know work more in the $36,000 dollar range.

Re:More power will lead to more bloat..

[Kjella (173770)]

From what I've gathered OS X has been cleaning up and improving speed on their code. A few select open source products have also reached a "stable" feature set and are working on smoothing things out. On the whole though, not all of it has gone to bloat. Much of it has gone to abstraction, reuse and consistency. I'd rather they reused a known, tested component that's 10% or 20%, or depending on the application, 1000% slower than to rewrite a new custom piece that'll have new bugs.

Speed is rarely an issue t

Quick answer

[LiquidCoooled (634315)]

Run old software.

Its only new software thats sucking up all the extra processing power.

Remember back with really sluggish 33mhz 486s etc (and a lot lower) and thinking of the ultimate computer being a whole 50mhz.
Well now you got a computer thats over 10 times faster with practically infinate capacity.

Fire up that old operating system and run you original software, you will be in heaven!

x86 centric

[by Anonymous Coward]

Might want to point out that the article is x86 centric. Not that it only applies to x86, indeed many/most of the issues are just generally related to processors (single vs multi-core, trace lengths, etc), but the article definitely focus' on these issues as applies to the x86.

Unbloated URL

[rylin (688457)]

http://www.anandtech.com/printarticle.aspx?i=2343 [anandtech.com].
Same article without 90% of the ad-bloat.

Eliminate Bottlenecks

[Trolling4Columbine (679367)]

Chances are that you aren't often pushing your CPU to capacity. What I'd like to see is a better way to identify bottlenecks in my system. There's no sense pumping more power into a system if it's all going to be throttled by something like a slow hard drive.

Re:Eliminate Bottlenecks

[Ironsides (739422)]

Most bottelnecks are already known. Here is a breakdown of access time when you are running at processor speeds:

L1 & L2 Cache: Almost instantanious, Picoosecond resonse time
L3 and higher Cache: A bit slower, but still pretty quick, Nano resonse time
Main memmory: Go do something else while waiting for this, Nano/Microsecond resonse time

Hard Drive: Go to lunch and come back, Milisecond resonse time

Limitations...

[MosesJones (55544)]

Ummm, my home machine has a 400MHz processor running Suse. I'm thinking of upgrading, as I have every 6 months for 5 years, but I just keep waiting for the "next" best thing rather than upgrading now.

There are mobile phones more powerful than my home PC, but it does the job.

The wonder of these future boxes is that we will STILL be able to write code that makes them run slow. Roll on Longhorn I say!

Re:Limitations...

[Kjella (173770)]

The wonder of these future boxes is that we will STILL be able to write code that makes them run slow. Roll on Longhorn I say!

Well, each version of Windows seems to bring about new hardware requirements. Most people buy a new Windows version with new hardware. It is more than just a little coincidence. I think Microsoft is well aware that most people aren't able to install Windows themselves, and that making them believe you'll need a faster box is a good idea to keep them upgrading to the "next" level, both on software and hardware.

Kjella

Not particularly good for Windows

[TheLoneCabbage (323135)]

Multi threading get's you a speed boost not necesarily on the individual application, but definetly on the OS level. That's why Sun get's away with individual CPU's that are each 1/4 the speed of cheapy x86 hardware.

Most OS's these days are not monolithic. Even MS is really a collection of smaller pieces, but not nearly to the degreee of Linux.

Linux just scales better than Windows on multiple CPUs. I have no doubt that MS will work indian programers day and night to catch up, but this is a game they are definetly playing catch up in.

Linux, in some versions is scalling past 64 CPUs now (oh the benefits of forked kernel development!), which should factor nicely when time comes that AMD ('cause may not be around then) is pushing ships with dozens if not hundreds of micro-cores.

Last I checked (and I may be out of date on this) Windows started bogging on 4 CPUs. And never mind it's assanine global message loop.

I fully realize Joe User cares more about percieved performance than real performance (long live xorg!), and explaining Linux's advanced scaling architecture will not win over the desktop, but it will have a signifigant impact on technical decision markets; from servers to embeded devices (HUGE market for these clustered chips).

just a thought

[zenst (558964)]

Now I only have a very limated understanding of the issues and electronics, given my lack of electronics experience. But couldn';t the leakage by utilised in a some form of intigrated peltier coolining to help pump the heat out of the chip and as such making it cooler help in a small way to reduce leakage. ANother, and call it wacky thought that struck me ws why not have another layer of large silicon that is powered by the leakage. It look to me that the leaked power from the 70mn process is nearly enough for the total power on the 90mn process and then the leakage from the 90 would do something just over the 180mn process. In a sence another form of heat pump :). Anyhow I'm sure I've either given you electronics guru's somthing to thing about or at the very least, laugh about. Enjoy :)

Re:Myth of the single threaded desktop

[harrkev (623093)]

There are two fundamental truths:

1) Programming for two or more processors is more work, and prone to more subtle and strange errors.
2) Most people only have one processor.
You can draw the obvious conclusions.

Fact #1 can be dealt with by proper techniquie, training, and tools.
Fact #2 is going to change due to the inability of AMD, Intel to deliver over 4GHz.