Adaptive Clocking in AMD’s Steamroller
realworldtech.com
Adaptive Clocking in AMD’s Steamroller
1–10 of 15 posts
Re: Adaptive Clocking in AMD’s Steamroller
#2Tech Report [1] says the FIVR (Fully Integrated Voltage Regulator) is for:
• higher efficiency, lower voltage ripple
• cleaner power delivery [closer to the load, and controlled by Intel]
• very high frequency, to 140 MHz. This one seems relevant, reacting faster to dI/dt events
• the only apparent downside is that with more things in one package the thermal load is higher, but bear in mind haswell's very low overall power usage
[1] http://techreport.com/news/24802/leaked-slides-expose-haswel...
Re: Adaptive Clocking in AMD’s Steamroller
#3The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing.
With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change the AER (allowable error rate) register, which also will be a thing for simulations that don't matter like games and that do matter like Excel handling your payroll.
Re: Adaptive Clocking in AMD’s Steamroller
#4This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
Re: Adaptive Clocking in AMD’s Steamroller
#5This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
Sorry if I've misunderstood you, but I can't imagine many/any programs (even games) which function, well, at all if random transistor error is introduced.
Re: Adaptive Clocking in AMD’s Steamroller
#6How literal is the 'warm up' for the vector units? I've occasionally seen this effect mentioned with regard to microbenchmarking, but never understood why this might be. Are vector units actually slowly activated over several cycles so as to reduce voltage droop?
Re: Adaptive Clocking in AMD’s Steamroller
#76. Microarchitectural throttling to reduce current draw (e.g., Itanium processors issue fewer instructions during dI/dt events and vector units often take many cycles to ‘warm up’); this reduces IPC and can cause instruction scheduling challenges. How literal is the 'warm up' for the vector units? I've occasionally seen this effect mentioned with regard to microbenchmarking, but never understood why this might be. Ar…
There can be many other kinds of run-ups to steady state happening in processors for microbenchmarks. Caches/TLBs, branch predictors, clock gating, macro scale voltage/frequency scaling, memory prefetching, power management in the system outside cpu, etc.
Re: Adaptive Clocking in AMD’s Steamroller
#8Re: Adaptive Clocking in AMD’s Steamroller
#9This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
In general, this concept is called "good enough computing"; periodically, people think about it, and then brush it by the wayside. But it is a neat thought experiment, even if nothing else!
Re: Adaptive Clocking in AMD’s Steamroller
#10This is just the start. Next phase is to over clock while transistor error budget is within bounds, need to have heat and error sensors all over the die. The other one is having functional instruction packet transactions that they can retry somewhere else if they fail during processing. With these changes, the CPUs will always be operating at some pre determined error rate regime. No more over clocking, just change t…
This is not so far from reality. Ben Zorn has done some work on this -- in particular, his work on "Flikker" might be interesting to you. The paper ( http://research.microsoft.com/en-us/um/people/moscitho/publi... ) was published at ASPLOS'11. In general, this concept is called "good enough computing"; periodically, people think about it, and then brush it by the wayside. But it is a neat thought experiment, even if…