RISC-V Evolving to Address Supercomputers and AI | Hacker News Reader

RISC-V Evolving to Address Supercomputers and AI

tomshardware.com

41 pointsrbanffy8 comments

If it could be evolved to have POPCOUNT in (at least) the base 64-bit instruction set, that would be helpful. Every other mainstream ISA either has had it from the outset, or got it added later at substantial expense. For reasons.

It is hard to understand how it could have been omitted.

That' s funny, you are posting this exact same message in every RISC-V news I read.

> It is hard to understand how it could have been omitted.

This has not been omitted at all. The spec of the bitmanip extension, which contains the popcount instruction among others, has been around for a long time.

> If it could be evolved to have POPCOUNT

The goal of the HPC group is clearly not to add this type of extension. It focuses on the software and hardware requirements to enable the use of RISC-V for HPC. So it will focus on compilers and libraries used for high performance and possibly some ISA extension like the SIMD one or the crypto acceleration one.

But you'll probably be happy to know that there's actually some movement around the bitmanip extension right now. The spec 1.0 is under review and we can expect a freeze of this extension soon. And this extension is split into 4 sub-extensions that can be taken individually.

BitManip consists of more than four ISA extensions, but only the first four are being ratified at the moment. Those four extensions (including Zbc which contains popcount) are frozen in terms of the Task Group, and are in a 45 day public review period. In theory public review could cause some change, but really it's highly unlikely as the instructions in these four extensions are uncontroversial and conventional with a lot of existing experience from other ISAs. Also it's very easy for anyone with interest and expertise to have joined RISC-V International as a no-fee individual member and joined the Task Group during the last couple of years to put their point of view. But really BitManip has far less room for disagreement than the Vector extension, which should enter public review in a few weeks. Ratification should take place very soon after the end of the public review period.

Thank you for your notes ! I saw a few months ago that there were more than 4 extensions in BitManip, but when I recently checked the github page only 4 were left.

Is there a better source of information than the github page to know the development status of an extension?

> But really BitManip has far less room for disagreement than the Vector extension

Yes I've heard lots of criticism about the V extension.

As a counterexample to your claim about "every other ISA", ARM64 doesn't have an x86-style popcount instruction. Its CNT instruction operates on vectors, not words, and gives you the popcount within each byte. You need to perform a bytewise horizontal sum if you want to combine the counts across lanes.

If you start with a word in a GPR and want to compute its popcount into another GPR, you need to move the GPR into a vector register, do the CNT, do the horizontal sum, and move the result back into a GPR.

It's been a while since I did the test, but I think the latency I measured on the Apple M1 perf cores (Firestorm) for that instruction sequence was around 15 cycles. [1] Compare that to POPCNT being 3 cycles on Intel and it really hurts for latency-sensitive uses of word popcount. However, CNT is great for doing large reductions since you can do 32 rounds of CNT + vector add before the bytewise counters can overflow, so you can amortize away the cost of the horizontal reduction. (People end up doing similar things on x86 for large streaming popcount calculations.)

A lot of my micro-optimized code relies on low-latency word popcount, so I selfishly want every processor to have an Intel-style popcount. :)

[1] You can actually beat the latency of that very easily with an L1-resident byte popcount lookup table + sum reduction. This table is only 256B, so it's very practical. You can shave off 1-2 cycles of latency by going to a halfword popcount lookup table, which is 64KB. That kind of cache hogging will perform better in microbenchmarks than in real applications but with the M1's large L1 cache of 128KB per core it might be a net win if you have a tight loop that's heavily affected by popcount latency.

It's very easy to understand. It's a specialised and expensive instruction in gates and gate delays (quite possibly being the limiting factor on clock speed if you try to do it in one cycle), there is very little software that would benefit meaningfully from it, and RISC-V was not design to sell computers to the NSA.

The Zbc BitManip extension contains popcount (and also count leading and trailing zeros) and will be ratified before the end of summer.

What you mean to say is that you do not personally understand the myriad uses where it makes an order of magnitude difference in performance. The "NSA" myth is long past its sell-by date.

It is rare for popcount to complete in one cycle on other systems, and so it is mystifying that you would even bring it up. Other core operations take more than one cycle.

> What you mean to say is that you do not personally understand the myriad uses where it makes an order of magnitude difference in performance

You clearly misunderstand the concept of a modular ISA. RISC-V does not only target high performance. It targets simple scalar microcontrollers, general purpose superscalar machines, and specialized acceleration (Except specific encoding like VLIW for now).

Each of these domains needs a slightly different ISA, and a modular ISA like RISC-V can aggregate all this by providing several ISA extensions. Then, for each domain, we must select an appropriate set of extensions.

And bitmanip is not necessary for all domains.

Reply on news.ycombinator.com