Slashdot Mirror
Ask Slashdot: Why Are There No Huge Leaps Forward In CPU/GPU Power?
dryriver writes: We all know that CPUs and GPUs and other electronic chips get a little faster with each generation produced. But one thing never seems to happen -- a CPU/GPU manufacturer suddenly announcing a next generation chip that is, say, 4-8 times faster than the fastest model they had 2 years ago. There are moderate leaps forward all the time, but seemingly never a HUGE leap forward due to, say, someone clever in R&D discovering a much faster way to process computing instructions. Is this because huge leaps forward in computing power are technically or physically impossible/improbable? Or is nobody in R&D looking for that huge leap forward, and rather focused on delivering a moderate leap forward every 2 years? Maybe striving for that "rare huge leap forward in computing power" is simply too expensive for chip manufacturers? Precisely what is the reason that there is never a next-gen CPU or GPU that is, say, advertised as being 16 times faster than the one that came 2 years before it due to some major breakthrough in chip engineering and manufacturing?
Dude gamer GPU's are increasing in performance incredibly fast. THey double in speed every 2 years. The only reason desktop is not innovating is because Intel has a monopoly and won. But that is changing starting with Kaby Lake thanks to AMD Ryzen. It is back to 15% every year again and maybe even more as graphics shows no slow downs anytime soon.
Shoot for $185 you can get what a $399 did just in late 2014/2015 at all max settings in games.
http://saveie6.com/
This question lacks context. In terms of desktop PCs and common everyday usage, we don't NEED more speed or power. Nothing is going to speed up webpages or Facebook or whatever people typically do on their PCs. And even if you did, then you become constrained by the speed of the internet and there won't be much perceived benefit.
On the mobile side, there is room for more speed but it comes at the expense of power and is still constrained by connection speeds and website performance on mobile devices, which often sucks. Throwing faster and more processing isn't necessarily the fix that is needed.
There are cases where rendering and other heavy duty uses might benefit but the vast majority of people never use those things. Even gaming is usually constrained by other things like the GPU, the game engine, connection speed, and human performance.
The major places where computing power is much more important are in things like supercomputing but those machines don't run desktop programs and don't work the same way. Only the people directly using those machines would ever have any idea how fast they are or how much faster they wish they could be.
So, to recap, desktop PCs are adequate, mobile devices are still finding a balance between power and power usage, gamers are off on their own island but sheer CPU isn't a magic fix, and supercomputing, where extra power would matter, is so far removed from everyday users, there is no way to relate to it.
Sig for hire.
Huge breakthroughs happen when some option has not been tried due to lack of funds, vision, laziness, monopoly markets or some other crap. In a field where smart people have been exploring all options at the cutting if not bleeding edge there wont be an overlooked angle which can suddenly give a 16x jump.
In short a huge breakthrough is not a sign of greatness rather it is a sign that there was something wrong with the field and someone figured out how to fix it.
Huge breakthroughs will never happen in a healthy industry/research field.
**Life is too short to be serious**
Something about less distance making for faster signaling
Actually, it has very little to do with the distance. The single biggest speed improvement in die shrink comes because the gate capacitances are smaller due to smaller footprint, and as such the gate charge / discharge time is shorter. The shorter distances does have a small effect as well, but the primary effect is due to the gate capacitance.
I wish I had a good sig, but all the good ones are copyrighted
For a long time, Intel and Microsoft Windows have rules the computing world. The platform has been at the bottom, Intel's instruction set architecture.
Intel leaped from 16-bit to 32-bit architecture and then from 32-bit to 64-bit but the basic execution model remains the same. Most of the advances that Intel have done from the Pentium onwards in the early '90s have been stopgaps to get as much out of the execution model, but still being limited by it.
There are other processors out there, DSPs, that are much faster than x86 at specialized tasks by making them pipelined and parallel. GPUs could be seen as massively parallel DSPs.
But raw computing power is not the problem. The problem is to run general-purpose code well - and general-purpose code has many branches between code paths and that can't be parallelized.
A company called Mill Computing is working on a general-purpose CPU architecture inspired by DSPs and from what they think that the Intel IA-64 (Itanium) should have been.
By being vastly different in several significant ways from x86, they claim to be able to achieve a significantly higher performance per watt and performance per clock overall than Intel and AMD's x86.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
The gates are now so small that the electron wave function has a pretty high probability of being "on the other side" of the gate. As gates shrink, leakage power goes up very rapidly. Even when they're "off", the gates are consuming too much power (leaking it to ground.)
Also, think about 5 Ghz, IBM's fastest chips. At 5 Ghz, the clock speed is 200 picoseconds, and a 10 deep pipeline can allocate about 20 ps to each gate transition. That's a lot to ask, given that resistance and capacitance don't scale down linearly with dimensions. You also have to populate your chip with a lot of decoupling capacitors in order to hold the charge locally for each transition (because you can't get the power from off chip in 20 ps.) To fight the increased RC load (proportionally) you're putting in more buffers (big amplifiers).
As if that weren't enough, you have the fact that a 14 nm gate is about 20 silicon atoms across. When you start doping the substrate, your actual behavior is all over the place because one or two more dopant atoms represent a 10-20% shift, up or down (total shifts of 40-50%.)
So, your gates are too small, they all behave differently, they have to drive a relatively larger load, and the suckers are too hot.
While the "end effect" is true, it has nothing to do with laziness.
Paying a programmer is expensive. The employer have you rather finished quickly and sells your work early with "drawbacks" e.g. more memory usage and less speed.
And the real culprits are the marketing droids that think programs and OSes need a new UI experience every few years. A huge deal of programming efforts and bloat is wasted and does not bring any value to the users.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Intel is up to their shady tactics again with AMD's new Ryzen release. Maybe not out right paying off computer makers, just now they are sponsoring reviewers. The reviewers jump through all kinds of hoops to make sure that Intel is on top of the benchmark graphics and read like a Intel marketing brochure. None of the reviewers disclose that they are sponsored by Intel.
Examples of oddities from reviewers that are sponsored by Intel.
1) Tom's Hardware: Complains about the power consumption being higher than spec, leaves out that the result was from a overclocked test and an MSI board that has an additional CPU power.
2) GamersNexus (one worst of them)
a) Had to compared the 1800x to 6 different Intel processors that were overclocked with the 6900k overclocked by 700Mhz.
b) Only one AMD processor was OC by -100Mhz(yep) . There OC vs stock were almost exactly same.
c) Makes the 6900k pop on the top of the benchmarks.
d)1800X only loses 6 vs 8 to the Intel 6900k at stock speeds. With only 2 benchmarks with the 1800x losing by more than 7fps.
e)Pretty much all benchmarks by the same author never included OC tests, but suddenly he had to compare it to 6 different OC benchmarks. http://www.gamersnexus.net/gam... http://www.gamersnexus.net/gam...
f) Out right lied saying AMD told him not to benchmark Ryzen at 1920x1080. AMD just asked him to benchmark at multiple resolutions , not just 1080P.
It's really capacitor charge time. In CMOS technology, you basically have a metallic plate (the gate) sitting on some semi conductor (separated by an insulator).
As electrons flow into the 'plate', they accumulate. This creates an electric field which pushes electrons in the semiconductor away creating a channel of 'holes'. It's through this channel that electrons can flow (drain to source). Note that the electrons moving through the CMOS gate are typically sent to another transistor. And as soon as that plate fills up with electrons, current stops flowing through the device. And since power = current x voltage (IxV), you only dissipate power while the device is switching and this is why there is more current drain (and heating) the faster that you switch. Leakage current blah blah disclaimers.
CMOS Transistor
The smaller the transistor, the smaller the metal plate (the gate), so it charges faster, creating the channel faster allowing for faster switching times.
> trying to teach some of the programmers out there how to program effectively on the various parallel platforms is harder than trying to alter physics.
Which could also be phrased as:
So far, many of the parallel platforms available are much harder to learn.
Programmers can and do learn new and different ways of working, provided that the new ways don't suck.
C, Java, etc are all imperative, scalar and object based languages. SQL is a completely different paradigm, declarative and set-based. In other words, in most programming languages the programmer tells the computer how to do some task, with some value. In SQL, the programmer tells the computer what the result must be - without specifying how to do it, and all fundamental operations work on sets, not individual values. Yet most programmers can ans often do learn the declarative, set-based way of programming just as well as they learn the classic imperative way. They learn two very different ways of thinking and programming, because SQL is reasonably good - it's quite learnable, with or without understanding the underlying mathematical concepts.
There's no fundamental reason you can't have a parallel programming language or library for general purpose programming that's roughly as easy to use as SQL. In fact, SQL may point the way in many respects - besides being a learnable paradigm, it's fundamentally parallelizable precisely because the fundamental operations all use sets as input and output. All the major operations could easily be completely parallelized behind the scenes and the user (programmer) wouldn't have to know or care.
Maybe that's the way to go, since we know programmers can and do use sets - introduce a set-based general purpose language. To avoid leading programmers into temptation, the language should have no loop constructs. With no capability to run this:
foreach blah in group {
result[i++] = do_stuff(blah);
}
programmers will quickly learn to instead write:
results = do_stuff(group);
My girlfriend asked what laptop she should buy. There was a time when I would have had all kinds of answers, maybe even fixup her old laptop with Linux or something to squeeze a couple more years out of it. That was then.
To save trouble, I just gave her a Chromebook. I know very little about them. But I know they just work, at a fraction of the cost of anything else. She can check her work schedule, do online shopping, watch Netflix, etc. And I don't have to be bothered!
I don't have to mansplain to her, figure out why her network connection wasn't working, or how to install extensions so she can browse safely, or one of a million things that happen when an ordinary person uses a real computer and real OS. I could have given her a top of the line, tricked out Dell, or Asus, or whatever. She wouldn't have been any happier or any more satisfied.
So now my stock answer when anyone (other than a STEM student) asks about what computer they should buy, my answer is Chromebook.:
Moore's Law is merely an observation about the NUMBER OF TRANSISTORS on a die, not computing power.
In theory, Intel and AMD could probably make 64-core CPUs a retail reality within a year or two... but with current programming languages, it would be almost pointless. Multithreading exists, of course... but few apps besides raytracing can genuinely put it to good use. As a practical matter, 99% of the benefit from having multiple cores comes from being able to run Windows UI threads on one core, and whatever app is in the foreground on the second. With Windows itself spinning off API calls from the app onto cores 3 and beyond when it gets the chance to do so.
Windows does a decent job of passively putting multiple cores to good use, but its ability to do that mostly depends upon having access to the benefits of x86/AMD64 architecture at its disposal. Historically, Linux has done a TERRIBLE job of passively putting multiple cores to good use without explicit multithreading attempts by the app's programmer, due to two main lines of reasoning:
a) If the developer intended for the program to multithread, he would have written it that way... IMHO, more of an excuse, because the fact is, current programming languages aren't all that great at handling concurrency without major gymnastics. 25 years ago, we had spaghetti code as an anti-pattern. Now, we have a rat's nest of spaghetti async threads that are almost impossible to grasp without referring to a wall-sized UML diagram.
b) Many of the things Windows does to passively put multiple cores to good use depend upon the "strong" memory model of x86/AMD64 CPUs. I believe this is actually the biggest current reason why Linux doesn't try as hard as Windows to passively multithread apps written to be single-threaded... and the reason why there were several entire generations of multi-core Android phones that didn't actually do a single damn thing with the extra cores besides brag about them in the marketing literature. Basically, on x86/AMD64, if thread #1 updates a byte of ram, thread #2 running on another core attempts to read it, the CPU will automagically make the change instantly visible to the second core. On ARM, that's rarely/never the case. With a language like Java, x86/AMD64 hides lots of programming sins that will cause the exact same code to crash and burn on ARM.
TL/DR: we COULD have CPUs with a lot more cores than 4, 6, or 8... but current software wouldn't put them to good use, so there's almost no real market for them besides servers and mainframes.
- Yields of working units are going down significantly as the die shrinks, and it's taking a lot longer to figure out how to bring yields back up.
In the end, every material has its limits, and we're starting to run into them with Silicon, and there isn't a material that 'stands out' as worth betting the business on.
So, Moore's Law is dead.
Moore law remains a remarkably correct prediction. However the prediction is concerning both feature size and cost and it predicts the costs rising in pretty much the fashion they have. It's exponential.
However in terms of computer power, the vast majority of the increases in computer power have been architectural, not from process improvements. If we stopped at 10nm and never went below that, computers would continue to get faster. I am aware of techniques that will continue to improve the processing speed of CPUs. They are not feature size improvements. They will come out in due course. But feature size is not limited by our ability to push feature size. It's limited by the cost of reducing it. Who's going to drop $100,000,000,000 on a fab in 5 years to get below 5nm? Other technique become more effective per unit dollar.
We push these things on all fronts. I've seen some pretty crazy schemes and I've seen some fail and some succeed.
My personal opinion as someone who works on these CPUs is that the recent (4-5 years) slowing of CPU power increase (note that improvement in instructions per Joule hasn't slowed) is going to change. New things will come down the line that will dramatically increase the speed of doing stuff. It's happened with specific workloads like graphics, or crypto or RNGs or disk I/O. Other things will continue to improve as attention is spent on improving them.
Notice how your CPU isn't awesome at DSP, but there are plenty of DSP oriented CPUs that blow any general purpose CPU out of the water on those tasks. There are datapath oriented architectures that can move data faster than any general purpose CPU sitting in big iron routers everywhere. As the demand for specific workloads change, the general purpose CPUs will follow.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
The timeline for carbon electronics is really, really long, predating transistors and silicon by decades. Carbon based electronics has had more than enough R&D for us to understand the basic properties and scaling challenges. The proof of this is that there are commercial products out there using these materials, made in commercial fabs. You just don't hear about them, because they have very little to do with the digital world (right now). Typically, you'll find these products in sensors and analog components. The particular strengths of carbon based electronics are an ability to carry lots of current in small channels (this is not just about resistivity, but also relates to chemical stability and thermal conductivity), and an ability to integrate seamlessly with biological material (this was initially just about carbon-carbon chemistries, but has grown to also encompass superior integrations of electronics with living systems).
These are different kinds of transistors, and don't operate the way (digitally) MOSFET silicon transistors do.
Diamond is a wide bandgap semiconductor (that's physics for insulator). In special conditions, it can perform well, but those conditions (ranges for temperature, humidity, and field strength) are not practical for consumer devices. Doping diamond is possible, but very difficult, and it still results in a material that is a pretty good insulator. Sorry, it's going to be a lab toy for a long time.
Graphene is a zero-bandgap semiconductor. That means that it never turns off, it just has varying amounts of "on." It's got great numbers on paper (resistivity, mobility). Doping graphene is something immoral scientists talk about doing. The reality is that doping graphene creates a different material that lacks the speed and chemical stability of normal graphene. Your conduction mechanism changes, your gating mechanism changes, your noise sources change. It's a mess. Also, it's really easy to dope graphene on accident and lose your high-end performance. It's the newest material in this space, and the one least understood in the manufacturing realm (despite that, it forms the basis for the commercial product linked above, so obviously it's understood well enough).
You didn't mention carbon nanotubes, but I will, because what was the point of getting a PhD in carbon nanotube electronics if I can't talk about them on Slashdot?! Carbon nanotubes remain the unattainable holy grail of digital electronics. You can have it all: the speed of graphene, the on-off ratio of silicon, low power requirements... It's just that you almost need to assemble your circuit by hand. It's been >25 years we've been working with these materials, and we still don't know how to properly control where they go on a wafer (well, maybe these guys know). The problem is that nanotubes want to make a heterogeneous mixed metal-semiconductor plate of spaghetti on the wafer, when you want clean rows of uniform semiconductor. The best guys in the world at this are up to producing postage stamp sized patches in the middle of the wafer. So... there's some work to be done there before anyone starts designing a processor.
In a way, process limitations are a welcome obstacle, that should motivate reflection on legacy decisions, and perhaps finally allow the x86 architecture to be put to rest. Many consider x86 "good enough", but the problems with legacy hardware run a lot deeper than performance, and are largely responsible for the horrific state of computer security today.
The main problem isn't legacy hardware, but legacy software. The x86 architecture is already dead, and most of what we see is a hardware translation of x86 to a CPU architecture that isn't accessible to the coder.
I believe that the only way out of this is for us to start making more heterogeneous parallel chips. At the moment, this only really exists in the form of packages of CPU+GPU on a single chip. But if we had (for example) ARM+x86+GPU, we'd be able to run an ARM-based Linux or Windows environment, but power up the x86 core as required to run any vital legacy apps. This would mean it would slowly become more and more economical to develop for ARM (or whatever your chosen architecture is) and we'd be able to start thinking about retiring x86 sooner. And hell, it's not like even Intel are really fans of x86 themselves -- they've already tried to ditch it once (remember Itanium?), and in the end it was AMD who extended the x86 architecture to 64-bit, not Intel. Intel wants away from x86, the market wants a better architecture, we just need a stepping stone that guarantees legacy software compatibility, and when so many multiple cores lie idle, I don't see why heterogeneous multicore isn't recognised as the solution.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'