There is still sense to tweak RandomX to make it align better with modern and future CPUs

irrespective of the current development

I think that this "ASIC" by Bitmain proves that RandomX has achieved its goal.

<k​4r4b3y:karapara.net> Can you expand on that?

Antminer X3 (Cryptonight): 220 kh/s, 465W

Antminer X5 (RandomX): 212 kh/s, 1350W

Are they going backwards?

And you can get ~150 H/J with an ordinary CPU.

Yes, well tuned 7950X can get 150 H/J

they use weird "J/K"

which is joules per 1000 hashes?

150 h/J = 6.67 "J/K"

Server CPUs (64 core EPYCs) can achieve even higher efficiency

This ASIC only has a better space density. It also depends on how much they will charge for it.

My bet is they haven't decided on the price yet

They're making twitter poll now to see what people expect and how much they can milk out of it

they've been mining with these devices since December 2021, so they for sure returned at least part of their investment

Coincidentally, I was going to propose 2 new instructions that use the carry and overflow flag, which RISC-V does not have.

<k​4r4b3y:karapara.net> +1

I was thinking about another instruction which makes very good sense to be added in the next RandomX version

<x​fedex:matrix.org> Fun fact: In December 2021 there already were x86 CPUs more energy efficient than that ASIC

<k​4r4b3y:karapara.net> Should we favor against risc-v though? Some other anon had posed the same question here before.

I don't think we need to react to this ASIC at all. We can just implement the CFROUND optimization and the double hashing.

<k​4r4b3y:karapara.net> +1 on "no need to react yet" .

Since it's not actually an ASIC, it's a general pupose compute platform with custom firmware.

They have ~500 RISC-V cores there by my calculations

split into 10 boards

good density

yes, CFROUND has bugged me almost since the beginning when I started optimizing for real CPUs

no real programs use it that often

so it makes sense that this instruction is slow

jst as long as it's never possible for it to randomly get zero uses

otherwise we have to rethink whether the easy/hard program problem is an issue again

BTW, if anyone is wondering how x86 can still compete in efficiency against RISC designs, the answer is here in the third bullet point: github.com/tevador/RandomX/blob/master/doc/design.md#22-program

hyc: 1/16 frequency for CFROUND should still be safe because 2048/16 = 128, i.e. rounding mode would change on average 96x per program (32x it would stay the same)

ISTR thre are other RISC families that don't have carry or overflow flags, but can't recall specifics right now

MIPS

ah yes

The carry/overflow instruction would be an option in case this ASIC was an actual ASIC implementing the RandomX ISA in silicon. In that case, it would be bricked as carry/overflow can't be emulated using the remaining instructions.

I just did a quick test on Ryzen 5 3600: 6498 h/s stock, 6979 h/s just by setting CFROUND frequency to 0 and increasing ISTORE frequency to 17 (from 16).

so 7.4% speedup just from not running CFROUND

<\x> ah yeah, just an update on iot though

<\x> new router/AP platforms now are 64 bit ARM mostly cortex A53 + aes with up to 2GB of RAM

<\x> thats the wifi 6/6e stuff

<\x> next gen will be like cortex a73 with up to 4GB ram

<\x> wifi 7 stuff

<\x> its like this for next gen

<\x> wiki.banana-pi.org/Banana_Pi_BPI-R4

2 GB of RAM is not enough to mine RandomX efficiently

<\x> yup

<\x> but on next gen it likely will be

<\x> pretty common to see aarch64 everywhere on iot hits nowadays, yes people still leave their passwords default on ssh

I don't see a problem if IoT botnets start helping to secure the network, unless they can reach 50%, which seems unlikely

<\x> for those its just a ram tweak yeah

<\x> just ask for more ram

<\x> and youll lose most iot

Adding more RAM is not an easy tweak, see the design docs.

<\x> mainstream computers are also heading towards having more ram

<\x> its like the norm for ddr5 is uhh 2x 16G setups

yeah but we still want to be able to verify hashes on a Raspberry PI with 512 MB

I was thinking of writing another VM for mining in 2GB of RAM

just keep the expanded dataset for 1GB, and use the cache for the other half

I remember that the slowdown from the other half is still too bad

I guess it would be. but still an improvement over lightmode