07:39:07 <sech1> There is still sense to tweak RandomX to make it align better with modern and future CPUs
07:39:18 <sech1> irrespective of the current development
09:14:17 <tevador> I think that this "ASIC" by Bitmain proves that RandomX has achieved its goal.
09:15:40 <m-relay> <k​4r4b3y:karapara.net> Can you expand on that?
09:17:02 <sech1> Antminer X3 (Cryptonight): 220 kh/s, 465W
09:17:02 <sech1> Antminer X5 (RandomX): 212 kh/s, 1350W
09:17:07 <sech1> Are they going backwards?
09:17:34 <tevador> And you can get ~150 H/J with an ordinary CPU.
09:17:50 <sech1> Yes, well tuned 7950X can get 150 H/J
09:17:59 <sech1> they use weird "J/K"
09:18:07 <sech1> which is joules per 1000 hashes?
09:18:25 <sech1> 150 h/J = 6.67 "J/K"
09:18:55 <sech1> Server CPUs (64 core EPYCs) can achieve even higher efficiency
09:18:59 <tevador> This ASIC only has a better space density. It also depends on how much they will charge for it.
09:19:18 <sech1> My bet is they haven't decided on the price yet
09:19:37 <sech1> They're making twitter poll now to see what people expect and how much they can milk out of it
09:20:03 <sech1> they've been mining with these devices since December 2021, so they for sure returned at least part of their investment
09:20:55 <tevador> Coincidentally, I was going to propose 2 new instructions that use the carry and overflow flag, which RISC-V does not have.
09:20:56 <m-relay> <k​4r4b3y:karapara.net> +1
09:21:36 <sech1> I was thinking about another instruction which makes very good sense to be added in the next RandomX version
09:21:40 <m-relay> <x​fedex:matrix.org> Fun fact: In December 2021 there already were x86 CPUs more energy efficient than that ASIC
09:22:32 <m-relay> <k​4r4b3y:karapara.net> Should we favor against risc-v though? Some other anon had posed the same question here before.
09:22:34 <tevador> I don't think we need to react to this ASIC at all. We can just implement the CFROUND optimization and the double hashing.
09:23:00 <m-relay> <k​4r4b3y:karapara.net> +1 on "no need to react yet" .
09:23:32 <tevador> Since it's not actually an ASIC, it's a general pupose compute platform with custom firmware.
09:25:32 <sech1> They have ~500 RISC-V cores there by my calculations
09:25:38 <sech1> split into 10 boards
09:25:47 <sech1> good density
09:26:29 <sech1> yes, CFROUND has bugged me almost since the beginning when I started optimizing for real CPUs
09:26:37 <sech1> no real programs use it that often
09:26:46 <sech1> so it makes sense that this instruction is slow
10:31:34 <hyc> jst as long as it's never possible for it to randomly get zero uses
10:32:04 <hyc> otherwise we have to rethink whether the easy/hard program problem is an issue again
10:32:57 <tevador> BTW, if anyone is wondering how x86 can still compete in efficiency against RISC designs, the answer is here in the third bullet point: https://github.com/tevador/RandomX/blob/master/doc/design.md#22-program
10:36:08 <tevador> 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)
10:40:53 <hyc> ISTR thre are other RISC families that don't have carry or overflow flags, but can't recall specifics right now
10:42:08 <tevador> MIPS
10:43:06 <hyc> ah yes
10:46:54 <tevador> 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.
10:53:47 <sech1> 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).
10:54:09 <sech1> so 7.4% speedup just from not running CFROUND
10:56:37 <hv-bridge> <\x> ah yeah, just an update on iot though
10:57:03 <hv-bridge> <\x> new router/AP platforms now are 64 bit ARM mostly cortex A53 + aes with up to 2GB of RAM
10:57:34 <hv-bridge> <\x> thats the wifi 6/6e stuff
10:57:49 <hv-bridge> <\x> next gen will be like cortex a73 with up to 4GB ram
10:57:54 <hv-bridge> <\x> wifi 7 stuff
10:58:24 <hv-bridge> <\x> its like this for next gen
10:58:25 <hv-bridge> <\x> https://wiki.banana-pi.org/Banana_Pi_BPI-R4
10:59:04 <tevador> 2 GB of RAM is not enough to mine RandomX efficiently
10:59:08 <hv-bridge> <\x> yup
10:59:16 <hv-bridge> <\x> but on next gen it likely will be
10:59:55 <hv-bridge> <\x> pretty common to see aarch64 everywhere on iot hits nowadays, yes people still leave their passwords default on ssh
11:00:20 <tevador> I don't see a problem if IoT botnets start helping to secure the network, unless they can reach 50%, which seems unlikely
11:01:36 <hv-bridge> <\x> for those its just a ram tweak yeah
11:01:43 <hv-bridge> <\x> just ask for more ram
11:01:50 <hv-bridge> <\x> and youll lose most iot
11:03:08 <tevador> Adding more RAM is not an easy tweak, see the design docs.
11:03:44 <hv-bridge> <\x> mainstream computers are also heading towards having more ram
11:03:55 <hv-bridge> <\x> its like the norm for ddr5 is uhh 2x 16G setups
11:05:10 <tevador> yeah but we still want to be able to verify hashes on a Raspberry PI with 512 MB
11:07:47 <hyc> I was thinking of writing another VM for mining in 2GB of RAM
11:08:06 <hyc> just keep the expanded dataset for 1GB, and use the cache for the other half
11:12:24 <sech1> I remember that the slowdown from the other half is still too bad
12:27:40 <hyc> I guess it would be. but still an improvement over lightmode