VRoom A high end RISC-V implementation • Hacker News Board

Re: VRoom A high end RISC-V implementation

#131

Post by Taniwha » Wed, Mar 23, 2022, 9:50 PM UTC

kragen wrote: post #130

Taniwha wrote: post #129

Earlier quoted context omitted.

oh totally, but then you aren't "making a procedure call" you're doing something different. In this case your data is likely traversing the memory hierarchy far enough so that the message data gets shared (more likely the sending data goes into the sending CPU's data cache and the receiving one will use the cache coherency protocol to pull it from there) - that's likely to take of the order of a pipe flush to happen.…

Agreed, but even in the cache-line-stealing case, those are latency costs, while a pipeline flush is also a throughput cost, no? Unless one of the CPUs has to wait for the cache line ownership to be transferred.

well if you're making a synchronous call you have to wait for the response which is likely as bad as a pipe flush (or worse, because you likely flood the pipe with a tight loop waiting for the response, or a context switch to do something else while you wait)

Also note that stealing a cache line can be very expensive, if the CPUs are both SMT with each other it's in the same L1, almost 0 cost, if they are on the same die it will be a few (4-5?) clocks across the L2/cache coherency fabric but if they are on separate chiplets connected via a memory controller with L3/L4 in it then it's 4 chip boundary crossings - an order or 2 in magnitude in cost

Re: VRoom A high end RISC-V implementation

#132

Post by skavi » Wed, Mar 23, 2022, 10:53 PM UTC

Taniwha wrote: post #62

titzer wrote: post #49

Earlier quoted context omitted.

As a language VM implementor, I would really love to have a conditional call instruction, like arm32. AFAICT this would be a relatively simple instruction to implement in the CPU. Is that accurate?

yes and no - there's a few issues here: 1 - architectural - RISCV has a nice clean ISA, it's adding instructions quickly, CMOV is contentious issue there - I'm not an expert on the history so I'll let others relitigate it - it's easy to add new instructions to a RISCV machine, unlike Intel/ARM it's even encouraged - however adding a new instruction to ALL machines is more difficult and may take many years. But unlike…

How do you feel about short forward optimizations? If I understand it correctly, BOOMv3 can convert instructions under a short forward branch shadow to be predicated.

Re: VRoom A high end RISC-V implementation

#133

Post by kragen » Wed, Mar 23, 2022, 11:30 PM UTC

Taniwha wrote: post #131

kragen wrote: post #130

Earlier quoted context omitted.

Agreed, but even in the cache-line-stealing case, those are latency costs, while a pipeline flush is also a throughput cost, no? Unless one of the CPUs has to wait for the cache line ownership to be transferred.

well if you're making a synchronous call you have to wait for the response which is likely as bad as a pipe flush (or worse, because you likely flood the pipe with a tight loop waiting for the response, or a context switch to do something else while you wait) Also note that stealing a cache line can be very expensive, if the CPUs are both SMT with each other it's in the same L1, almost 0 cost, if they are on the same…

All that makes sense to me. So for high performance collaboration across security boundaries needs to be either very rare or nonblocking?

Multithreading within a security boundary is one way to "synchronously wait" without incurring a giant context-switch cost (SMT or Tera-style or Padauk FPPA-style; do GPUs do this too, at larger-than-warp granularity?). Event loops are a variant on this, and io_uring seems to think that's the future. But the GreenArrays approach is to decide that the limiting resource is nanojoules dissipated, not transistors, so just idle some transistors in a synchronous wait. Not sure if that'll ever go mainstream, but it'd fit well with the trend to greater heterogeneity.

Re: VRoom A high end RISC-V implementation

#134

Post by timschmidt » Thu, Mar 24, 2022, 8:50 AM UTC

imtringued wrote: post #127

timschmidt wrote: post #109

Earlier quoted context omitted.

Fundamental rethinks take time. The ideas expressed by the mill folks have value independent of any specific implementation or absence thereof. Yosys is incredible and the dropping cost and increasing availability of capable FPGA dev boards equally so. I wouldn't put it past a sharp CS major to whip up a toy mill cpu in FPGA these days just based on what's been shared publicly. It's a bit strange to me that I can sti…

They won't commercialize their design. Your best bet would be to reverse engineer their designs and build your own.

I went looking and it seems that they're making some progress. I wasn't previously aware of their wiki, which contains ISA documentation and more: http://millcomputing.com/wiki/Main_Page

Re: VRoom A high end RISC-V implementation

#135

Post by brucehoult » Fri, Mar 25, 2022, 12:06 AM UTC

Taniwha wrote: post #86

Taniwha wrote: post #21

Earlier quoted context omitted.

Dhystone's just a place to start, it helps me make quick tweaks, and I'm at that stage of the process - it's particularly good because it's somewhat at odds with my big wide decoders - VRoom! can decode bundles of up to 8 instructions per clock, while Dhrystone has lots of twisty branches, only decodes ~3.7 instructions per bundle - it's a great test for the architecture by pushing at the things it might not be as go…

I'll add that freq scaled Dhrystone (DMIPS/MHz) is a particularly useful number because it helps you compare architectures rather than just clocks - you can figure out questions like "If I can make this run at 5GHz how will it compare with X?"

You could use verilator simulating VRoom! as a benchmark.

I haven't actually looked at the generated code, but I imagine it's thousands upon thousands of instructions in a row with no conditional branching at all. CHOMP.