4 ms·

I guess the choice thus comes down to how much potential benefits may be possible, versus what software actually needs? (I can see first-hand we don't need more

by K0SM0S 7y ago

I guess the choice thus comes down to how much potential benefits may be possible, versus what software actually needs? (I can see first-hand we don't need more single-thread performance in so many use cases) I just have no idea "how good it can get", compared to what we have now. Is there an alternative world where CPUs vastly outperform ours in performance/power using the same materials? But more importantly how much can "vastly" be?

pjc50 7y ago
Single thread performance is still the limiting factor for things like perceived web browser performance. Raw MIPS is available in absurd amounts, but things like memory round trip delay become limiting. The lower energy limit is https://en.m.wikipedia.org/wiki/Landauer%27s_principle https://en.m.wikipedia.org/wiki/Landauer%27s_principle but we're a long way from that.
- K0SM0S 7y ago
  > memory round trip delay Is that where Zen's architecture, with memory controller central to the chip (close to memory IO up/down) and 'chiplets' containing cores left and right, makes so much sense? I'm partial to announcements of "3D" stacking chips; wherein memory cells, controller and CPU cores are arranged like cake layers, thus with extremely short memory round trips. A clever design could entirely remove the need for L3 cache I suppose, make RAM behave essentially as such. It's elegant I think, somewhat balanced in design, essential. And I find it crazy and awesome that cooling those is even possible.
mntmoss 7y ago
These kinds of questions have an essential unknowability to them, in that every phenomenon you try to model through computing is an inexact approximation - whether it's something like the precision of a mathematical computation or "what is this human being's real name". What we have done to date is the low-hanging fruit: take known categories of application and juice them up by applying CPU power. And for that, the amount of power you need is "enough to have an effect". A lion's share of the benefits of putting computers in the loop were realized in the 70's or 80's, even though the measured amount of power that could be applied then was relatively miniscule. There were plenty of alternatives at various times that were "better" or "worse" in some technical sense, but succeeded or failed based on other market factors. The real story going forward from then has been changes in I/O interfaces, connectivity and portability - computing has merely "kept up with" the demands imposed by having higher definition display, networking, etc. So then we have to ask, what are the remaining apps? If we can engineer a new piece of hardware that addresses those, it'll see some adoption. And that's the thrust of going parallel: It'll potentially hit more categories at once than trying to do custom fast silicon for single tasks. But the long-term trend is likely to be one of consolidating the bottom end of the market with better domain solutions. These solutions can be software-first, hardware-later, because the software now has the breathing room to define the solution space and work with the problem domain abstractly, instead of being totally beholden to "worse-is-better" market forces.
- K0SM0S 7y ago
  What an intelligent bird's-eye view of the problem. Thank you. I love the perspective, you kind of blend the evolution of simple bits at the hardware level (increasingly lots of them, but nonetheless "known category of applications") with complex high-level software space. The clarity, looking forward, is greatly improved through this lens. That last paragraph confirms my own vision for the next cycle, the next decade or so. About "remaining apps": the current cycle of ML, post-parallism (GPUs, DL, etc. since early 2010s) is imho one such candidate for transformative computing, where like vapor or hydrocarbons or electricity, computing lends itself to enabling a whole new category of 'machines', of tools. That's really interesting (just not the end-all be-all some seem to think, but a whole new solution space to build upon). I guess robotics is a fitting candidate as well (insofar as interacting with real physical objects changes everything) but we are many years away from commercially-viable solutions, afaik. I also like to think there are (potentially transformative) social or behavioral use of compute-enabled machines that we haven't scratched much yet. Areas of life/civilization generally too complex to be brute-forced or even fully modeled, like biology and health, or the more advanced social behaviors (topics best described by Shakespeare, Tocqueville, Stephen Covey, Robert Greene...); or things we 'just' need to brute-force e.g. life-like graphics/VR or seamless/ambient/'augmented' computing/reality. Some of these may be in for the taking during the next cycle or two.
cogman10 7y ago
Yes! And, by a lot. A huge portion of the power a CPU consumes is simply due to the clock running which is why modern CPUs go through tremendous efforts to disable circuits not in use and lower the clock speed when the CPU is idle. However, imagine if we didn't have a clock at all. If, instead, the only thing that caused CPU transistors to switch was new instructions being executed. In that world, the only time CPUs would consume any power is gate leaks and when the CPU is actually doing stuff. That would translate in extremely low power draw. Performance would also be way up. Data would mainly be constrained by switching speed, which can be super fast. Today, data speed is mostly constrained by how big the largest section of the pipeline is and how fast the clock moves. So why don't we do this today? Mostly because the entire industry is built around synchronous (with a clock) CPU design. Switching to an async design would be both super difficult (lack of tools to do so) and very different from the way things work now. Just like parallel programming is very hard, async circuit design requires a large amount of verification that we just lack. Further, HDLs are simply not well built.. but also not well built for async. Async circuitry usually requires more transistors and more lines. That, however, isn't really a problem anymore. Today, the vast majority of transistors in a modern CPU are spent not on logic, but on the cache. It'd be super expensive to adopt. It would be totally worth it. But I doubt we'll see it happen until AMD and Intel both completely stop at advancements.
- nerpderp82 7y ago
  https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchron...
- seangrogg 7y ago
  This actually seems like it would be somewhat ideal for many web servers, where in a large number of cases the only interesting things going on are in response to events.
- K0SM0S 7y ago
  This is a very interesting perspective. The evident benefit of async helps us see a world/civilization where indeed computing is pervasive to a much, much deeper/higher degree. Positive note: it could certainly help take silicon-based electronics further in a resource-starved world; it could/should also simply be part of the paradigm of the next thing if it comes soon enough — photo-hype, buzz-ristors, whatever tech wins. (Thanks for an uplifting glimpse at the "TO DO" list of humanity, and one more spark of interest as a programmer!)

by K0SM0S 7y ago

pjc50 7y ago

Single thread performance is still the limiting factor for things like perceived web browser performance. Raw MIPS is available in absurd amounts, but things like memory round trip delay become limiting. The lower energy limit is https://en.m.wikipedia.org/wiki/Landauer%27s_principle https://en.m.wikipedia.org/wiki/Landauer%27s_principle but we're a long way from that.

K0SM0S 7y ago
> memory round trip delay Is that where Zen's architecture, with memory controller central to the chip (close to memory IO up/down) and 'chiplets' containing cores left and right, makes so much sense? I'm partial to announcements of "3D" stacking chips; wherein memory cells, controller and CPU cores are arranged like cake layers, thus with extremely short memory round trips. A clever design could entirely remove the need for L3 cache I suppose, make RAM behave essentially as such. It's elegant I think, somewhat balanced in design, essential. And I find it crazy and awesome that cooling those is even possible.

mntmoss 7y ago

These kinds of questions have an essential unknowability to them, in that every phenomenon you try to model through computing is an inexact approximation - whether it's something like the precision of a mathematical computation or "what is this human being's real name". What we have done to date is the low-hanging fruit: take known categories of application and juice them up by applying CPU power. And for that, the amount of power you need is "enough to have an effect". A lion's share of the benefits of putting computers in the loop were realized in the 70's or 80's, even though the measured amount of power that could be applied then was relatively miniscule. There were plenty of alternatives at various times that were "better" or "worse" in some technical sense, but succeeded or failed based on other market factors. The real story going forward from then has been changes in I/O interfaces, connectivity and portability - computing has merely "kept up with" the demands imposed by having higher definition display, networking, etc. So then we have to ask, what are the remaining apps? If we can engineer a new piece of hardware that addresses those, it'll see some adoption. And that's the thrust of going parallel: It'll potentially hit more categories at once than trying to do custom fast silicon for single tasks. But the long-term trend is likely to be one of consolidating the bottom end of the market with better domain solutions. These solutions can be software-first, hardware-later, because the software now has the breathing room to define the solution space and work with the problem domain abstractly, instead of being totally beholden to "worse-is-better" market forces.

K0SM0S 7y ago
What an intelligent bird's-eye view of the problem. Thank you. I love the perspective, you kind of blend the evolution of simple bits at the hardware level (increasingly lots of them, but nonetheless "known category of applications") with complex high-level software space. The clarity, looking forward, is greatly improved through this lens. That last paragraph confirms my own vision for the next cycle, the next decade or so. About "remaining apps": the current cycle of ML, post-parallism (GPUs, DL, etc. since early 2010s) is imho one such candidate for transformative computing, where like vapor or hydrocarbons or electricity, computing lends itself to enabling a whole new category of 'machines', of tools. That's really interesting (just not the end-all be-all some seem to think, but a whole new solution space to build upon). I guess robotics is a fitting candidate as well (insofar as interacting with real physical objects changes everything) but we are many years away from commercially-viable solutions, afaik. I also like to think there are (potentially transformative) social or behavioral use of compute-enabled machines that we haven't scratched much yet. Areas of life/civilization generally too complex to be brute-forced or even fully modeled, like biology and health, or the more advanced social behaviors (topics best described by Shakespeare, Tocqueville, Stephen Covey, Robert Greene...); or things we 'just' need to brute-force e.g. life-like graphics/VR or seamless/ambient/'augmented' computing/reality. Some of these may be in for the taking during the next cycle or two.

cogman10 7y ago

Yes! And, by a lot. A huge portion of the power a CPU consumes is simply due to the clock running which is why modern CPUs go through tremendous efforts to disable circuits not in use and lower the clock speed when the CPU is idle. However, imagine if we didn't have a clock at all. If, instead, the only thing that caused CPU transistors to switch was new instructions being executed. In that world, the only time CPUs would consume any power is gate leaks and when the CPU is actually doing stuff. That would translate in extremely low power draw. Performance would also be way up. Data would mainly be constrained by switching speed, which can be super fast. Today, data speed is mostly constrained by how big the largest section of the pipeline is and how fast the clock moves. So why don't we do this today? Mostly because the entire industry is built around synchronous (with a clock) CPU design. Switching to an async design would be both super difficult (lack of tools to do so) and very different from the way things work now. Just like parallel programming is very hard, async circuit design requires a large amount of verification that we just lack. Further, HDLs are simply not well built.. but also not well built for async. Async circuitry usually requires more transistors and more lines. That, however, isn't really a problem anymore. Today, the vast majority of transistors in a modern CPU are spent not on logic, but on the cache. It'd be super expensive to adopt. It would be totally worth it. But I doubt we'll see it happen until AMD and Intel both completely stop at advancements.

nerpderp82 7y ago
https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchronous_CPU https://en.wikipedia.org/wiki/Asynchronous_circuit#Asynchron...
seangrogg 7y ago
This actually seems like it would be somewhat ideal for many web servers, where in a large number of cases the only interesting things going on are in response to events.
K0SM0S 7y ago
This is a very interesting perspective. The evident benefit of async helps us see a world/civilization where indeed computing is pervasive to a much, much deeper/higher degree. Positive note: it could certainly help take silicon-based electronics further in a resource-starved world; it could/should also simply be part of the paradigm of the next thing if it comes soon enough — photo-hype, buzz-ristors, whatever tech wins. (Thanks for an uplifting glimpse at the "TO DO" list of humanity, and one more spark of interest as a programmer!)