22 ms·
Why has CPU frequency ceased to grow? (2014)
- Majora320 9y ago(2014)
- sctb 9y agoThanks! Updated.
- vdfs 9y ago> But there are also strong concerns that the increased frequency will raise the CPU temperature so much that it will cause an actual physical melt down. Note that many CPU manufactures will not allow a meltdown to happen
- MaxBarraclough 9y agoIt's there if you want it, but liquid helium doesn't come cheap.
- nothis 9y ago"Only you can prevent overclocking fires!" Nicely written. Seems like the intended headline was "why it's bad to overclock", though!
- slivym 9y agoSeems like an incredibly long winded way of saying 'To go faster you either need to split up each instruction into lots of parts or increase the voltage for the transisters. We've split the instructions as much as we can, and power consumption is proportional to Voltage cubed, so it's not a scalable plan.'
- IIAOPSW 9y agoMore importantly than mere power consumption, we don't have a way to remove the waste heat generated. Dennards law (like Moore's law but for power consumption per transistor) ended 10 years ago. Exactly the same time clock speeds stopped improving. There are actually a few computers out there that run around 10Ghz but they all have impractical cooling systems. If there ever were a return to exponential scaling, we would very soon run into the Launder limit.
- inspector-g 9y agoFor those who are curious, see the Wikipedia article on Landauer's Principle [1] I hadn't heard of this before, but it sounds like we are a long way off from reaching the limit; as the article states, modern computers use millions of times more energy than what Landauer's Principle implies is the lowest possible amount. 1: https://en.wikipedia.org/wiki/Landauer%27s_principle https://en.wikipedia.org/wiki/Landauer%27s_principle
- deepnotderp 9y ago> If there ever were a return to exponential scaling, we would very soon run into the Launder limit. No we wouldn't. We're around ~10,000X off and would run into thermal danger zones long before.
- IIAOPSW 9y agoBUT....The Launder limit is over optimistic because unless your computer runs at absolute zero you need to keep redundant copies of each bit for error correction. Transistors are implicitly error correcting in the sense that each bit is represented by a current of a few thousand electrons. Factoring in the redundancy requirement we are likely only off by somewhere between 100x and 1000x. If there were ever a return to exponential technological improvement, we would run out of road after a few years.
- mjfl 9y agoI took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardware system to exploit it to keep things going forward. I find the apparent stagnation extremely depressing.
- quadcore 9y agohttps://golang.org/ https://golang.org/ In case you dont know, Golang goroutines are a marvel of parallelism. They are coroutines which are dispatched on a few OS threads. So you can use 100% of a multi-cores CPU and yet, spawn, say, 10K of those light threads without worrying about context switches PLUS have them all run concurrently. I've found that golang is one of those rare language, like Lisp, that actually change the way you think about programming. Makes you feel really more powerful. If you dont know that language, I suggest to run the following and watch your cpu activity and memory (or any metric): import "time" func main() { for i := 0; i < 10000; i++ { go func() { for { time.Sleep(time.Second) } }() } }
- dx034 9y agoAnd yet, Go's standard map doesn't allow concurrent access. They recently added a concurrent map feature but it's probably easier to add a lock to your code than refactoring it with the new map type. I would've preferred if they had introduced a map type that can be used exactly as the standard one (i.e. without function calls). Calling functions via go func() is really easy but handling data between goroutines can still cause headaches and is something that could be improved.
- ta2384428 9y agoIf you squint a little, you'll notice that go is pretty big on not hiding complexity. There are obvious exceptions to this such as the garbage collector, and heap/stack control. I'm unsure if the intent of not including a map function was due to this, however with a for loop such as for x := range ch { slice = append(slice, x) } , it is immediately obvious there are allocations happening in the background. The fact that map access, and slice access is not thread safe means there is no trickery going on in the background. The fact that it is not threadsafe means I don't need to worry about a lock if I only write to a map when it's created. Sure the compiler could take care of this - they have the race detector after all, but the compile speed is one of the design goals of go. I really like being able to compile in less than 1 second. `sync.Map` however calls a function which implies there is more going on in the background. If you follow the go mantra of share memory by communicate, don't communicate by sharing memory - handling data becomes a whole lot easier. It does allow you to share memory in case you do need the extra speed. Like most things, all designs are a matter of trade offs. Sacrifice one thing for another. There are other languages that provide the functionality you desire - but I understand the frustration when one thing is 90% what you want. Go obviously has room for improvement, and perhaps a native threadsafe map is one of those areas.
- swarnie_ 9y ago"CPU manufactures will not allow a meltdown to happen." No one in the office understands why i'm laughing....
- minibob 9y agoFINALLY REVOLT RELEASES DragonBallFighterZ Crack https://is.gd/5oEE8T https://is.gd/5oEE8T
- hackme1234 9y agoThe spectre of meltdown is haunting CPU manufactures.
- krylon 9y agoGreat, now I have to clean all that tea off of my display. ;-P
- MichaelMoser123 9y agoand i thought that humor is verboten around here... Does HN have an exception in the book that applies to Intel ?
- krylon 9y agoThe guidelines do not mention humor as such. It is often frowned upon, but I think the delicious irony in this case warrants an exception. ;-)
- chimprich 9y agoI don't think humour as such is frowned upon on HN - if I was to attempt to write down the unwritten, I would say that posts that are just jokes tend to go down badly, but jokes that make a point or serious posts that are written with some wit are generally accepted.
- deleted 9y ago[deleted]
- ksec 9y agoUntil we have another material that could replace silicon. Not sure if we will see this happen in the next ten to twenty years.
- hackme1234 9y agoGraphene. The material of the future.
- mtgx 9y agoTeraHertz CPUs would be nice.
- kowdermeister 9y agoCrank them up a little more and they will glow due to reaching visible light territory :)
- v_lisivka 9y agoCrank them up a little more and they will go into deep ultraviolet. Problem solved.
- kowdermeister 9y agoThere is no problem here, marketing folks would love it :)
- LaikaF 9y agoSo would gamers. "Nice LEDs bro" "Nah that's my CPU"
- mcbits 9y agoPerhaps leading to little pixel-sized photovoltaic cores that absorb light on one side, do a bit of computation at 400-800 THz and emit light on the other side, merging the display with the CPU. I've heard that VR goggles with 8K resolution per eye would be approaching the limit of the human eye's resolving power, which would be about 66 million cores.
- M_Bakhtiari 9y agoThey fail to mention that dividing instructions into more pipeline stages means greater branch penalty which in turn prompts reckless speculative execution schemes to compensate.
- mozumder 9y agoAsynchronous CPUs or bust. Or, better yet, wave pipelining...
- simias 9y agoI find their explanation of the pipelining issue slightly confusing, probably because they tried to simplify it to the extreme: >One could object to this and note that due to shorter clock ticks, the small steps will be executed faster, so the average speed will be greater. However, the following diagram shows that this is not the case. Said diagram shows that the two-clock-tick step locks the pipeline, that is you can't execute the first clock tick for the next instruction if you're still running the 2nd part of the previous one. When would this be the case? Isn't entire point of pipelining to divide a function into smaller steps that can be run in parallel? If you can split "step 3" across two clock cycles, couldn't you effectively subdivide it into two steps that could run in parallel? I suppose that eventually you run across the issue that adding additional pipelining stages increases the logic size which in turn causes it to run slower or something like that. I wish the document was a little more specific, after all it doesn't hesitate to throw the physical formulas for power dissipation in the 2nd part so clearly it's not afraid to dig into technical details.
- til 9y ago> If you can split "step 3" across two clock cycles, couldn't you effectively subdivide it into two steps that could run in parallel? There is a difference between splitting "step 3" across two clock cycles and splitting "step 3" into two separate steps. The underlying assumption here is that "step 3" is indivisible. E.g. say "step 3" was memory access and the latency for that is 500 picoseconds, it's not like you can just split it into two steps and make it load faster.
- rbobby 9y ago> But remember, wrong overclocking can harm not only processor but you as well. Don't date robots!
- logicallee 9y agoguys, I'll be honest: I found it really odd that the article didn't talk about the speed of light, and die size constraints. (c / 4 ghz = 7.49 cm only, if you double that frequency you have half that size to put components it between any two clock ticks.) But there are limits to my hubris - this is on intel.com, so I'm going to go with "I'm the one missing something". Is the speed of light and number of transistors you can put in that path (due to die size) just not a practical constraint? Neither is mentioned.
- pjc50 9y agoThe key factors in integrated circuit delay are more to do with capacitance; in order to change a gate's transistor from off to on, the driving gate has to charge the capacitance of the driving wire and the driven gate. Making features closer together increases their mutual capacitance. (source: worked on this for a chip design software company. The delay approximation was based entirely around R/L/C modelling and had no terms for the speed of light per se. If I remember rightly it was calculated in integer pico-meters; I definitely remember it emitting an error message if you had more than 2cm of wire in any one net!)
- v_lisivka 9y agoI.e. the problem is the state of processor, which need to be erased. So we can make stack of stateless processors, which will readily accept fresh data, because they will need to fill capacitors only, not discharge, and then discharged after use. Kind of multicore design, but with each core used for only 1/n of time at e.g. 1Thz frequency. Unlike parallel system, sequential calculation will work faster in such setup.
- smnscu 9y agoLet me take the opportunity to plug my favorite computer architecture course from ETH, who was published here recently. https://www.youtube.com/playlist?list=PL5Q2soXY2Zi9OhoVQBXYFIZywZXCPl4M_ https://www.youtube.com/playlist?list=PL5Q2soXY2Zi9OhoVQBXYF... https://safari.ethz.ch/architecture/doku.php https://safari.ethz.ch/architecture/doku.php
- dschuetz 9y agoThe rule of thumb in chip design: your chip clock is as slow as your slowest logic pipe. Complex logic circuitry slows down potential clock rates significantly. You can make your logic gates switch faster, thus allowing longer signal paths, but it has a huge energy trade-off, as the article states. Multi-core design seems now to compensate for slower clock rates, but it also has its trade-offs. It makes software more complex. In case of the CISC arch Intel established it's a huge trade-off, since CISC is supposed to make its processors easier to program, as opposed to RISC. I don't think that CISC is a good choice when it comes to massive parallelism. But, since chip design is so expensive and is considered state of the art high-tech, we'll need to deal with everything that chip makers throw at us. Or do we?
- pjc50 9y agoThe RISC/CISC "tradeoff" is mostly a non-issue at the higher end of processor design: everything is now a hybrid. You have ARM64 with its SIMD and floating point extensions that hardly qualifies as "reduced" on one side, and Intel systems that have a suspiciously RISC-like internal architecture fed by decoder of the "legacy" CISC instruction set. It still matters at the small end, which is why Cortex-M exists. > Or do we? A startup can design its own chips, but good luck getting anyone to use it.
- userbinator 9y agoI don't think that CISC is a good choice when it comes to massive parallelism. On the contrary, I think the increased code density (reduced fetch bandwidth --- very important for multiple cores) and greater semantic information of CISC instructions is crucial for parallelism. Large operations can be broken up into individually scheduled uops inside the core, and those uops can then be parallelised, without the equivalent of fetching all those uops from memory as might occur in a classic RISC. In fact, even modern ARMs use this uop-based "instruction splitting" in their microarchitecture.
- ponyous 9y agoThere is a new relevant episode of changelog's podcast that talks about CPU advancements. https://changelog.com/podcast/284 https://changelog.com/podcast/284
- whoisthemachine 9y agoMy senior design course focused on asynchronous (clock-less) cryptography circuits; after learning of these, I looked into asynchronous general purpose processors, and learned that ARM actually designed an asynchronous processor back in the 2000's [0]. While they've never quite taken off (the extra gates decrease speed and our harder to manufacture), with the recent side-channel attacks on processor pipelines, I've been hopeful that I would see something pop up. Imagine a world where our processors run without a clock! [0] https://www.eetimes.com/document.asp?doc_id=1299083 https://www.eetimes.com/document.asp?doc_id=1299083
- rcxdude 9y agoWouldn't asynchronous CPUs increase the amount of side-channels? AFAIK in an asynchronous circuit every aspect of the calculation may affect the time it takes to complete.
- whoisthemachine 9y agoThe attacks I'm aware of use processor timings to measure the effects their programs are having. However, because an asynchronous circuit doesn't complete tasks in a reliable cycle, you can't measure how the pipeline is being effected by your program in the same way. You could find new ways to force the processor to act in a reliable manner that you could measure, but that may change quite randomly from processor to processor, or even from moment to moment, depending on external environmental factors.
- deepnotderp 9y agoNope. In fact EMI and differential power analysis based approaches are actually heavily mitigated in asynchronous, as is bus snooping.
- pjc50 9y agoOne of my CS lecturers worked on this: https://www.cl.cam.ac.uk/~rja14/Papers/micromicro2003.pdf https://www.cl.cam.ac.uk/~rja14/Papers/micromicro2003.pdf It turns out that the advantages are not so great as might appear, and the situation gets worse as DRAM delay dominates. Also logic designers are a conservative bunch and getting everyone to replace the industry standard design toolchain is a big ask.
- mysterypie 9y agoThe article doesn't answer the question at the fundamental level. The closest it gets is this: "Increased frequency depends heavily on the current level of technology and advances cannot move beyond these physical limitations." Certainly, Moore's law is just an observation and cannot go on forever. Would it fair to say that we've simply reached the point where we can no longer "keep up" with Moore's observation because the technology is getting harder and not because we've actually reached any limit of physics?
- abpavel 9y agoIndeed, that's what I looked for too. The current transistor gate pitch is approaching atomic sizes, which results in electrons leaking through by quantum tunneling. I was hoping to understand more about how speed of light and quantum behavior is preventing further progress. Article only mentions transistor switching speed.
- Sammi 9y agoBecause the subject of the article is explicitly about clock speed and not about making transistors smaller.
- Sammi 9y agoYou're skipping over the main point of the article, which is that the reason it's hard to increase the clockrate is because it is dependent on the slowest instruction that can be done in one tick. And the main method of making an instruction faster is by splitting it, but all instructions have now already been split as much as is possible, while still having them operate correctly.
- hinkley 9y agoBut this shouldn’t be true for a superpipelined processor, right? Or put it another way, let’s say phase 3 contains several important instructions that cannot be reduced to a length of less than 1.7 clock ticks. If the pipeline stalls you have other pipelines that won’t. Or you get crazy and put in 2 copies of the slow paths of phase 3 and one takes the even ticks and the other the odd ones.
- otabdeveloper1 9y agoExponential growth can't be infinite. Who knew! Mind blown!
- stringer 9y agoI've been looking at Haskell, Rust and Go for helping with parallelism but decided to go with a less known language: Pony. Not used actors a lot right now but looks really promising.
- lmm 9y agoParticularly given you haven't used actors, what advantages does Pony give you over Haskell?
- stringer 9y agoRight now I found Pony more approachable than Haskell. Maybe because that I never fully grok monads (probably my fault not persevering enough), I always had problems composing monads. Also the promise of Pony is a garbage collection that is concurrent with program execution and since I want to write low latency server code this feature sounds very appealing.
- mitchtbaum 9y agoRust has an actor framework among other great projects in its ecosystem: https://github.com/actix/actix https://github.com/actix/actix
- tagrun 9y agoI understand that companies heavily invested in silicon would like to portray it that way, but CPU frequencies haven't ceased to grow. DARPA manufactured a THz transistor made of InP back in 2014. Silicon isn't the only semiconductor in nature, and others are actively being researched. Also, "when you increase the frequency you increase the power" (which is their argument) doesn't explain why they can't increase the frequencies. That was always the case even back in 1960s. What they actually need to explain is why they can't make the silicon more power-efficient anymore; all toy-physics arguments (such approximations/linearizations work only for a very limited range of frequencies, if they do at all, anyway meaning their scaling-relations aren't universal like they're trying to portray and those coefficients they ignore aren't constant across voltage, frequency, materials, ... either; you almost never get such simple and universal answers in condensed matter physics even for much simpler problems) mentioned there could have been made 50 years ago as well, but silicon CPU frequencies did go up.
- tarlinian 9y agoTransistor switching frequency has almost nothing to do with processor clock speeds which are almost entirely limited by wire RC delay. You will get increased drive currents by switching to higher mobility materials but the performance improvement over strained silicon isn't that large.
- tagrun 9y agoThat's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. But if your switching frequency is slow, it doesn't matter if you use a superconductor for wires. It is the switching frequency that truly determines the limits for gate times, which in turn determines how fast your CPU is. For the record, SiGe is also very promising in terms of switching speeds. There were experiments which shows near THz frequencies.
- deepnotderp 9y ago>That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. No it's not. What is this magical material with ultra low resistance? And how do you plan to reduce capacitance? Btw, manufacturing terahertz speed transistors is very difficult. There are Mott FETs which will switch at 10 terahertz, but they're incredibly hard to manufacture and very power hungry.
- yAnonymous 9y ago>temperature Using a proper thermal interface material in their CPUs would be a start... When you can decrease the temps of Intel CPUs by 20°C with delidding, the heat argument seems quite constructed.
- navjack27 9y agoRe: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it on. We have 8 physical cores. We also have two separate dies. Each die has four cores. Each die module has their own level 3 cache. As you use your system and you are also folding, even in the newest Linux kernel, data and instructions might get evicted and bounced around and take latency hits and thus performance hits. Nothing really locks the work to the cores or threads taking into account locality. You can adjust this with HTOP and set each thread of folding manually. Beyond AMD, even Intel has similar issues still with the 8700k. Hell, in general just efficient multithreading seems like a tough compromise for OS development. "Users" want things to be smooth upon interaction, so you have preemption. Work wants to get done but it also wants to be a good citizen to the rest of the system. Developers are going to have to learn about, and keep up to date with, much more then a fancy new language. You're going to have to learn each new CPU inside and out and how each OS treats it.
- vondur 9y agoHow did the BeOS designers make the BeOS so good at multiprocessing? I remember how well the operating system scaled with more than one CPU.
- da_chicken 9y agoProbably because it ran on PowerPC. If I remember my systems design class from 20 years ago, RISC makes implementing or scaling multiprocessing easier.
- nradov 9y agoIntel processors essentially are RISC now internally. They just expose more complex instructions as a higher level API.
- Symmetry 9y agoThat was a bit misleading in some ways. First, in pipelining you'll typically measure how long a pipeline steps in FO4s, which is to say the delay required for one transistor to drive 4 other transistors of the same width. Intel will typically design its pipeline stages to have 16 FO4s of delay. IBM is more aggressive and will try to work it down to 10. But of those 10, 2 are there for the latches you added to create the stage and 2 are there to account for the fact that a clock edge doesn't arrive everywhere at exactly the same time. So if you take one of those 16 FO4 Intel stages and cut it in half you won't have a two 8 FO4 stages but two 10 FO4 stages. And since those latch transistors take up space and energy you're got some severe diminishing returns problems. One thing that's changed as transistors have gotten smaller is that leakage has gotten to be more of a problem. You used to just worry about active switching power but now you have to balance using higher voltage and lower thresholds to switch your transistors quickly with the leakage power that that will generate. And finally velocity saturation is more of a problem on shorter channels making current go up more linearly with the gate voltage than quadratically.
- nullbyte 9y agoHow do you know all this stuff?
- Symmetry 9y agoGot my master's in it, before ending up in sensors then robotics instead. And a continued interest, I guess. Here are some free relevant courses. You might have to go back and take the pre-reqs. https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-374-analysis-and-design-of-digital-integrated-circuits-fall-2003/ https://ocw.mit.edu/courses/electrical-engineering-and-compu... https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-720j-integrated-microelectronic-devices-spring-2007/ https://ocw.mit.edu/courses/electrical-engineering-and-compu...
- kickopotomus 9y agoThank you for this! I have been looking for IC design MOOCs for awhile.
- jedbrown 9y agoNotably, single-thread performance of code that is not friendly to vectorization has not stagnated despite stagnant clock frequency. Indeed, SPECint performance continues to grow exponentially, albeit more slowly since ~2004. https://www.karlrupp.net/2018/02/42-years-of-microprocessor-trend-data/#more-760 https://www.karlrupp.net/2018/02/42-years-of-microprocessor-...
- Retric 9y agoDepends on the code, you can write ASM that's as fast on an old P4 as a modern i7. Just access random RAM locations and modern CPU's suck.
- jedbrown 9y agoIncreasing CPU clock speed also does not reduce DRAM latency.
- Retric 9y agoWe are talking about the sum of latency's. The CPU needs to do something AND you need to fetch from DRAM. Modern CPU's have increased the worst case overhead to fetch form DRAM to decrease the average case. That's usually a good trade-off until someone wants to make your CPU look terrible.
- darkmighty 9y ago> Indeed, SPECint performance continues to grow exponentially, albeit more slowly since ~2004 Interesting chart! However that looks like moving goalposts. If you allow functions to still be exponentials when the rate repeatedly diminishes, any monotonic function can be an exponential: f(x) = x is an "exponential" with diminishing growth rate log(x). That curve looks approximately logistic to me, as most technologies usually do. Actually I believe speculative execution theoretically allows increasing linearly single-threaded performance for exponentially more multi-threaded performance -- so a transistor price Moore's law (if not power/density) should allow a continued linear single-threaded growth. The problem is that without power (inverse) scaling, this would also cost exponentially more power. It seems the slight increase in power visible in that chart could account for a fraction of increased single-threaded performance (other factors would be improved efficiency and architectural gains); expect those factors to also stall soon (which would fulfill the "logistic prophecy").
- jacksmith21006 9y agoIn some cases because not necessary. Take the Gen 1 Google TPUs. They use a 700 mhz clock rate but are processing 65535 things at the same time. Very simple instructions. Here is a great paper on comparing to silicon using far higher clock rates. https://arxiv.org/ftp/arxiv/papers/1704/1704.04760.pdf https://arxiv.org/ftp/arxiv/papers/1704/1704.04760.pdf Now what will be interesting is this new architecture can be used for more traditional CS functions. I love this paper from Jeff Dean on using the TPUs instead of a CPU to replace a b-tree for example. https://research.google.com/pubs/pub46518.html https://research.google.com/pubs/pub46518.html This also solves our multi-thread issue. Basically it done in a multi-thread manner from the ground up. We get a round peg for a round hole.
- chx 9y agoIt's a matter of cost and cooling really, IBM z13 is 5GHz, z14 is 5.2GHz.
- jacquesm 9y agoNo, it's a matter of economics. Those zXX chips are not cheap, nor is what they interface to.
- AlfeG 9y agoFunny to read comment section in russian source article. People argue about need of multicore processors in a desktop pc. Especially when I read those comments from 16 core machine.
- drudru11 9y agoAre there any CPUs out there with FPGAs tacked on that are available to the hobbyists/gamer/build your own PC crowd?
- TickleSteve 9y agoNot really, the market for combined processor/FPGAs are basically the opposite, FPGAs running a soft-core processor. Same effect tho.
- rphlx 9y agoThere are some hobbyists using the 28nm Xilinx Zynq, a hardened circa-2009-cell-phone dual-core ARM with on-die FPGA. One popular board is the https://www.crowdsupply.com/krtkl/snickerdoodle https://www.crowdsupply.com/krtkl/snickerdoodle
- api 9y agoCost/benefit AFIAK-- higher clock speeds require advanced cooling, use more power, etc., and it's been possible to get more speed by increasing transistor count instead at lower cost.