A Case for Asynchronous Computer Architecture (2000) [pdf] • Hacker News Board

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#11

Post by baybal2 » Sun, Nov 28, 2021, 12:17 PM UTC

bob1029 wrote: post #9

Having a common clock reference (per core) is essential for reducing latency between components. If you have to poll or await some other component arbitrarily, there will necessarily be extra overhead and delays in these areas. There will also need to be extra logic area dedicated to these activities. Make no mistake, just because there's no central clock, doesnt mean you are magically off the hook. You still need to…

Clock distribution eats a lot of power at gigahertz frequencies, and a lot of gates.

> If you have to poll or await some other component arbitrarily, there will necessarily be extra overhead and delays in these areas.

You don't poll. You have a lot of small input-clocked domains which work at a speed with which data comes.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#12

Post by twoodfin » Sun, Nov 28, 2021, 1:01 PM UTC

Const-me wrote: post #6

Modern clocked processors don't account for worst-case timings. Instead, instructions take variable count of clock cycles to complete. In some sense they're already asynchronous, despite clocked.

Can you write more about this or provide some examples? Of course, memory access has had variable timing “forever”, but the idea that other functional units can vary their timings for instructions is new to me.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#13

Post by nynx » Sun, Nov 28, 2021, 1:20 PM UTC

Const-me wrote: post #6

Modern clocked processors don't account for worst-case timings. Instead, instructions take variable count of clock cycles to complete. In some sense they're already asynchronous, despite clocked.

Certainly, modern CPUs are pipelined, but each clock cycle is still the worse-case time for all steps in the pipeline.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#14

Post by boibombeiro » Sun, Nov 28, 2021, 1:56 PM UTC

Memory cells are the thing that uses the vast majority of power in a CPU. And they are used everywhere, cache, uOP cache, BTB, etc.

Async CPU solved a problem that would have marginal benefit in a metric we care about

Also, I imagine, they would need to be implemented assuming the worst timing delay from the processes. They can't be binned like modern CPUs.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#15

Post by Const-me » Sun, Nov 28, 2021, 2:04 PM UTC

twoodfin wrote: post #12

Const-me wrote: post #6

Modern clocked processors don't account for worst-case timings. Instead, instructions take variable count of clock cycles to complete. In some sense they're already asynchronous, despite clocked.

Can you write more about this or provide some examples? Of course, memory access has had variable timing “forever”, but the idea that other functional units can vary their timings for instructions is new to me.

A good source of that info is https://www.uops.info/

For instance, on my CPU which is AMD Zen 3, the idiv instruction (it computes integer division and modulo) takes between 9 and 19 cycles for 64-bit version: https://www.uops.info/html-instr/IDIV_R64.html#ZEN3 That’s for the operand already in a register i.e. no RAM access involved.

Whether it takes 9 cycles, 19 cycles, or something in between, depends on the arguments of the instruction, i.e. on the numbers being divided.

Same applies to quite a few other instructions: floating point divisions (divps, divpd), floating point square root (sqrtps, sqrtpd), even 64-bit integer multiplication (imul).

It’s not just the math. Jumps, branches and function calls take very different count of cycles depending mostly on two things: predicted or not, and the state of micro-ops cache at the target address. Albeit these effects are very hard to measure reliably, depends on the code too much, probably for this reason uops.info doesn’t have latency figures for jmp/call/etc.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#16

Post by Const-me » Sun, Nov 28, 2021, 2:27 PM UTC

nynx wrote: post #13

Const-me wrote: post #6

Modern clocked processors don't account for worst-case timings. Instead, instructions take variable count of clock cycles to complete. In some sense they're already asynchronous, despite clocked.

Certainly, modern CPUs are pipelined, but each clock cycle is still the worse-case time for all steps in the pipeline.

> each clock cycle is still the worse-case time for all steps in the pipeline

The pipeline takes variable count of clocks to complete an instruction. The number depends on the instruction, input data of the instruction, and quite a few other things. In some exotic cases it even depends on power state, e.g. some Intel CPUs took ~20k cycles to power on their AVX pieces, during that window AVX instructions are much slower.

If for any reason the pipeline is unable to deliver the result by the end of the clock, CPUs don’t delay the clock, they continue running the clock. You simply gonna get the result on some later clock cycle.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#17

Post by nynx » Sun, Nov 28, 2021, 3:14 PM UTC

Const-me wrote: post #16

nynx wrote: post #13

Earlier quoted context omitted.

Certainly, modern CPUs are pipelined, but each clock cycle is still the worse-case time for all steps in the pipeline.

> each clock cycle is still the worse-case time for all steps in the pipeline The pipeline takes variable count of clocks to complete an instruction. The number depends on the instruction, input data of the instruction, and quite a few other things. In some exotic cases it even depends on power state, e.g. some Intel CPUs took ~20k cycles to power on their AVX pieces, during that window AVX instructions are much slow…

That's exactly what I mean.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#18

Post by mikeurbach » Sun, Nov 28, 2021, 7:45 PM UTC

fivelessminutes wrote: post #2

This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.

We had the pleasure of hosting Dr. Manohar at a CIRCT weekly discussion session earlier this year. He presented much more recent work if anyone is interested. The talk and discussion was recorded here: https://sifive.zoom.us/rec/play/Bg99_niHh9OG_8uE_nhaz6otxvA0...

EDIT: talk begins around 7 minutes.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#19

Post by nickdothutton » Sun, Nov 28, 2021, 8:48 PM UTC

matja wrote: post #3

fivelessminutes wrote: post #2

This seems to be from 20 years ago, the most recent citation was from 2000 and it describes a MIPS chip built on a 1998 process.

And not even a mention of AMULET ( https://en.wikipedia.org/wiki/AMULET_microprocessor )

Came here to say this.

Re: A Case for Asynchronous Computer Architecture (2000) [pdf]

#20

Post by IshKebab » Sun, Nov 28, 2021, 10:04 PM UTC

boibombeiro wrote: post #14

Memory cells are the thing that uses the vast majority of power in a CPU. And they are used everywhere, cache, uOP cache, BTB, etc. Async CPU solved a problem that would have marginal benefit in a metric we care about Also, I imagine, they would need to be implemented assuming the worst timing delay from the processes. They can't be binned like modern CPUs.

That doesn't sound right? Dynamic power is consumed by toggling wires, and memory cells are going to be one of the places where toggling is rare because you can't access all memory all the time.

Am I missing something?