4 ms·

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 al

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.

twoodfin 5y ago
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.
- Const-me 5y ago
  A good source of that info is https://www.uops.info/ 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 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.
- Taniwha 5y ago
  Well for example imagine you have a 64-bit adder - and you add two numbers together - let's assume that on e of the in puts is '1' - how long does it take until the output is stable? it depends on the second value an d more importantly how long it takes for all the carries to propagate to the MSB - for a naive circuit and input of 0 the output will stabilise very quickly, for an input of 0xffff_ffff_ffff_ffff it will take 64 adder delays - an async circuit can have simple additions run faster than the worst case ones (which will still work). While a synchronous circuit would have a clock that could only go as fast as the slowest case (or pipeline things so that the output appears multiple clocks later)
  - jacquesm 5y ago
    That's a pretty naive adder implementation. A more efficient version would stabilize after two ticks.
    - Taniwha 5y ago
      yup, but I'm using it as an example to make a point here (hence my use of the word 'naive') - also the whole point of doing async stuff is that you don't have to worry about 'ticks'
      - jacquesm 5y ago
        Even in async you have to worry about ticks, it's just that the ticks aren't global. Think of the extent to which a clock can propagate as a lightcone, within that domain everything is synchronized, but it need not be synchronized with things on the outside. The smaller the domains the more asynchronous a design gets. But you'll never be async all the way down, at some point you will have to worry about stabilizing your outputs and passing them on to the next stage in that stable situation. Compare synchronous serial lines with an asynchronous interface such as a centronics printer interface. The former will happily send zeros + clocks all day long absent a signal, the latter will strobe it's 'ready' output only when there actually is data, but it will still have to output that pulse, which serves as a very local clock.
  - Const-me 5y ago
    > imagine you have a 64-bit adder Integer addition is too easy. On all modern computers, add instructions take at most 1 cycle. Even vector ones like vpaddq AVX2 which adds four 64-bit numbers to another four numbers.
nynx 5y ago
Certainly, modern CPUs are pipelined, but each clock cycle is still the worse-case time for all steps in the pipeline.
- Const-me 5y ago
  > 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.
  - nynx 5y ago
    That's exactly what I mean.

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.

twoodfin 5y ago

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.

Const-me 5y ago
A good source of that info is https://www.uops.info/ 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 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.
Taniwha 5y ago
Well for example imagine you have a 64-bit adder - and you add two numbers together - let's assume that on e of the in puts is '1' - how long does it take until the output is stable? it depends on the second value an d more importantly how long it takes for all the carries to propagate to the MSB - for a naive circuit and input of 0 the output will stabilise very quickly, for an input of 0xffff_ffff_ffff_ffff it will take 64 adder delays - an async circuit can have simple additions run faster than the worst case ones (which will still work). While a synchronous circuit would have a clock that could only go as fast as the slowest case (or pipeline things so that the output appears multiple clocks later)
- jacquesm 5y ago
  That's a pretty naive adder implementation. A more efficient version would stabilize after two ticks.
  - Taniwha 5y ago
    yup, but I'm using it as an example to make a point here (hence my use of the word 'naive') - also the whole point of doing async stuff is that you don't have to worry about 'ticks'
    - jacquesm 5y ago
      Even in async you have to worry about ticks, it's just that the ticks aren't global. Think of the extent to which a clock can propagate as a lightcone, within that domain everything is synchronized, but it need not be synchronized with things on the outside. The smaller the domains the more asynchronous a design gets. But you'll never be async all the way down, at some point you will have to worry about stabilizing your outputs and passing them on to the next stage in that stable situation. Compare synchronous serial lines with an asynchronous interface such as a centronics printer interface. The former will happily send zeros + clocks all day long absent a signal, the latter will strobe it's 'ready' output only when there actually is data, but it will still have to output that pulse, which serves as a very local clock.
- Const-me 5y ago
  > imagine you have a 64-bit adder Integer addition is too easy. On all modern computers, add instructions take at most 1 cycle. Even vector ones like vpaddq AVX2 which adds four 64-bit numbers to another four numbers.

nynx 5y ago

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

Const-me 5y ago
> 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.
- nynx 5y ago
  That's exactly what I mean.