Asynchronous logic is significantly more power efficient, so it may be one approach to "save Moore's Law" (for one generation perhaps). But it would probably require some company that really cares about power efficiency, doesn't care about industry best practices, and is willing to risk hundreds of millions in R&D.
People have been poking at it for over 30 years now. I'm scratching it up to "it's the future, and always will be ..."
The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
11–20 of 31 posts
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#12Asynchronous logic is significantly more power efficient, so it may be one approach to "save Moore's Law" (for one generation perhaps). But it would probably require some company that really cares about power efficiency, doesn't care about industry best practices, and is willing to risk hundreds of millions in R&D.
People have been poking at it for over 30 years now. I'm scratching it up to "it's the future, and always will be ..."
The upsides are real but other avenues of development may still have higher payoff vs cost (effort).
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#13This reminded me of one of Gustafson's reasoning for change in how numerical computations are done - currently used principles of hw architecture result in hw wasting lots of energy and time, mostly in the process where numbers get from RAM to CPU and back. It seems more people already realize this, which is good. I hope to see some general purpose hw inspired by these ideas of efficient computation.
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#14Asynchronous logic is significantly more power efficient, so it may be one approach to "save Moore's Law" (for one generation perhaps). But it would probably require some company that really cares about power efficiency, doesn't care about industry best practices, and is willing to risk hundreds of millions in R&D.
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#15Asynchronous logic is significantly more power efficient, so it may be one approach to "save Moore's Law" (for one generation perhaps). But it would probably require some company that really cares about power efficiency, doesn't care about industry best practices, and is willing to risk hundreds of millions in R&D.
People have been poking at it for over 30 years now. I'm scratching it up to "it's the future, and always will be ..."
Now that Moore's Law is on its way out, people can actually try new things, and discover what pays off and what does not.
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#16Mine start at 50 microsecond intervals. I've worked on stuff with shorter and longer intervals. Sometimes we have lists of tasks that need to run at different rates, so scheduling becomes a real pain. Welcome to the world of real time embedded software in high performance systems. The same thing applies, we make sure the worst case execution time is within the allowed intervals and use a master clock to sync everything up.
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#17Earlier quoted context omitted.
People have been poking at it for over 30 years now. I'm scratching it up to "it's the future, and always will be ..."
People have been poking at every architecture improvement for 30 years. Moore's Law makes it clear that the only winning move is to go into the most popular path. Now that Moore's Law is on its way out, people can actually try new things, and discover what pays off and what does not.
What may have been hard to implement 30-40 years ago may be easier now with current technology. Some of these could definitely supplement existing binary/boolean silicon in certain domains if not replace it, like using actual brains in AI-as-a-Service, for image recognition and so on,
Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]
#18>> Imagine what software would be like if subroutines could start and end only at preset time intervals. “My subroutines all start at 3.68 millisecond intervals; how often do yours start?” Mine start at 50 microsecond intervals. I've worked on stuff with shorter and longer intervals. Sometimes we have lists of tasks that need to run at different rates, so scheduling becomes a real pain. Welcome to the world of real t…
This in contrast to non-real-time systems which tend to just freeze for random periods of time (sometimes seconds or even minutes) without any apparent cause. That's something that really puzzles me about todays software+hardware. In theory it should all be faster than ever but in practice I spend as much or even more time waiting for my computers than I ever did in the past.
Maybe I'm just more impatient but I don't believe that's the reason here.
Real time should be the norm, not the exception, just like encrypted communications should be the norm, not the exception.
Computers should respond without noticeable latency to user input at all times.