Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

worrydream.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#21

Post by daveloyall »

Hm, I came up with this idea independently, 5 Code: The Hidden Language of Computer Hardware and Software.

Neat!

I just figured that you could redesign common ICs so that they had a new wire akin to the "carry" bit. I called it the 'done' wire, and I figured you could just tie it to the CLK of the next IC. Ya know? So 'doneness' would propagate across the surface of the motherboard (or SoC) in different ways depending on the operation it was performing. Rather than the CLK signal, which is broadcast to all points...

(I know that my idea is half baked and my description is worse. I'm glad I found this PDF!)

I knew the big advantage would be power savings. I called the idea 'slow computing', and I envisioned an 8-bit style machine that would run on solar or a hand crank and be able to pause mid calculation until enough power was available... Just like a old capacitor-based flash camera will be able to flash more frequently when you have fresh batteries in it.

You'd just wire the power system up with the logic. Suppose an adder fires a "done" at some other IC. Now, put your power system inline, like MiTM... When it gets the "done", it charges that capacitor (a very small one? :) ) and only when enough power is available does it propagate the "done". ...Maybe the "done" powers the next IC. I dunno.

As I said, half baked. Glad to find out that I'm not the only one that dreamed of 'clockless', though!

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#22

Post by daveloyall »

jacquesm wrote: post #18
phkahler wrote: post #16

>> 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…

I've done quite a few of these embedded systems with real time constraints and your summary is quite accurate. The good part for me is that once you have things nailed down they (usually, and if not then you're really in for a long night) don't shift and what works will continue to work reliably. This in contrast to non-real-time systems which tend to just freeze for random periods of time (sometimes seconds or even…

Remember moving your cursor through menu options in an NES game? (or using a 8-bit word processor?) Computers should be like that. Consumers shouldn't accept anything else.

Responsive interfaces allow users to develop muscle memory.

I used to type in complicated sequences of commands into my commodore 64 to perform common actions. (wow, I didn't know I wanted a $HOME with some scripts in it. Now I know!)

When I'd make a typo in one of those sequences, it would commonly be quicker for me to reset the machine and start from the top.

If I performed the same action twice (with a reset inbetween) and got a different result, I could logically conclude that I had a hardware problem. (Not every HW problem is permanent. Heat and grounding problems can both be fixed, unless some threshold is crossed...)

Anyway, I figure that Wintel denied grandma that kind of computer because they learned from the hobbyists that neophyte users with quality hardware+software will exceed the creators in skill in less time than it takes to design the next gen rig--and a couple genius users will start building their own out of impatience!

There's no profit in quality hardware+software combinations.

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#23

Post by sliverstorm »

trsohmers wrote: post #13
effie wrote: post #5

This 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.

The inefficiency you are talking about is not due to the fact that there is a synchronous clock (within each individual "block", since there needs to be some async logic going between the different clock domains of DRAM and the processor). The waste in getting numbers from RAM to the register file is primarily due to the hardware managed cache hierarchy, which we are addressing at REX Computing, along with John Gusta…

Waste? Or overhead in exchange for having a cache?

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#25

Post by Cyph0n »

daveloyall wrote: post #21

Hm, I came up with this idea independently, 5 Code: The Hidden Language of Computer Hardware and Software . Neat! I just figured that you could redesign common ICs so that they had a new wire akin to the "carry" bit. I called it the 'done' wire, and I figured you could just tie it to the CLK of the next IC. Ya know? So 'doneness' would propagate across the surface of the motherboard (or SoC) in different ways dependi…

The big issue with the done signal you're referring to is how do you generate it? In other words, how does the circuit "know" that it's finished execution?

There are several options. One is to simply add a delay element to each circuit that is matched to the circuit's delay. Another is to use a circuit-level handshaking protocol, similar to that used in TCP.

It's not an easy thing to tackle and leads to performance loss in the long run relative to a synchronous design.

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#27

Post by [deleted] »

jacquesm wrote: post #18
phkahler wrote: post #16

>> 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…

I've done quite a few of these embedded systems with real time constraints and your summary is quite accurate. The good part for me is that once you have things nailed down they (usually, and if not then you're really in for a long night) don't shift and what works will continue to work reliably. This in contrast to non-real-time systems which tend to just freeze for random periods of time (sometimes seconds or even…

[deleted]

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#29

Post by trsohmers »

sliverstorm wrote: post #23
trsohmers wrote: post #13

Earlier quoted context omitted.

The inefficiency you are talking about is not due to the fact that there is a synchronous clock (within each individual "block", since there needs to be some async logic going between the different clock domains of DRAM and the processor). The waste in getting numbers from RAM to the register file is primarily due to the hardware managed cache hierarchy, which we are addressing at REX Computing, along with John Gusta…

Waste? Or overhead in exchange for having a cache?

Obviously tooting my own horn here, but our solution is replacing hardware managed caches with software managed caches... You get to have larger, lower latency "caches" of SRAM in our solution, that also use less power in moving data from RAM to the register file through them since we very granularly control the hierarchy.

Re: The Tyranny of the Clock – Ivan Sutherland (2012) [pdf]

#30

Post by daveloyall »

Cyph0n wrote: post #25
daveloyall wrote: post #21

Hm, I came up with this idea independently, 5 Code: The Hidden Language of Computer Hardware and Software . Neat! I just figured that you could redesign common ICs so that they had a new wire akin to the "carry" bit. I called it the 'done' wire, and I figured you could just tie it to the CLK of the next IC. Ya know? So 'doneness' would propagate across the surface of the motherboard (or SoC) in different ways dependi…

The big issue with the done signal you're referring to is how do you generate it? In other words, how does the circuit "know" that it's finished execution? There are several options. One is to simply add a delay element to each circuit that is matched to the circuit's delay. Another is to use a circuit-level handshaking protocol, similar to that used in TCP. It's not an easy thing to tackle and leads to performance l…

I don't understand. It's clear to me when an adder is 'done'. Hm, so I'm guessing it does get more complicated than that. :)
Post reply on HN