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/
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
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
> 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);
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'