15:13:44 <dukenukem> "The first professional #XMR  Miner, pioneering XMR Mining!" - https://nitter.net/BITMAINtech/status/1695783295806775605
16:08:24 <DataHoarder> > Support RISC-V, Available For Mining Multiple Cryptocurrencies
16:08:42 <DataHoarder> huh? cluster of RISC-V cores?
16:14:24 <hyc> <interesting, since we never wrote a RISC-V JIT ourselves.
16:15:20 <hyc> if it's real, it's yet another case of for-profit companies exploiting permissive licenses. free software deves should never use anything but GPL-family licenses
16:16:06 <DataHoarder> oddly the numbers look almost equal to https://github.com/tevador/RandomX/issues/31 doing the math
16:17:12 <DataHoarder> 212000 / 1350 ~= 157 vs 15000 / 95 ~= 157.9
16:18:41 <hyc> that was an upper bound in efficiency at the time. and yet ryzens are alrady at the 150H/J region
16:32:14 <sech1> 212 kh? So I was right, it's those units that were mining since December 2021
16:32:32 <hyc> which means this thing isn't any more efficient than current CPUs, so... 
16:32:37 <sech1> And power efficiency is not even impressive
16:32:53 <sech1> https://api.hashvault.pro/v3/monero/network/nonce/distribution/png?hashrate=true&nonceColor=%23ff6600
16:33:14 <sech1> those horizontal lines we've noticed after Christmas 2021 and in early 2022
16:33:21 <hyc> ah right
16:33:32 <sech1> so they're dumping 2 year old devices :D
16:33:37 <sech1> 2 years of "testing" :D
16:33:42 <hyc> so they've been at it for at least 2 years, and all they could come up with is barely at parity with AMD
16:33:58 <sech1> well, 2 years ago they were a bit ahead of best CPUs
16:34:06 <sech1> now it's on par with tuned Zen4 CPUs
16:34:15 <sech1> Zen4 EPYCs will be more efficient
16:34:39 <hyc> yes, but to make an impact they needed to be more than 2x better. that was the threshold for GPUs to still be competitive on ETH
16:34:47 <sech1> So nothing will change, they're already on the network
16:34:49 <sech1> and mining
16:34:58 <hyc> they're nowhere near that threshold
16:36:08 <sech1> the ad says "multiple cryptocurrencies", so it's not even specialized. It's probably some custom RISC-V chips, but they're just regular CPUs
16:36:23 <hyc> yep
16:36:41 <hyc> but that's actually impressive for RISC-V to match AMD efficiency
16:37:10 <sech1> they probably took some shortcuts
16:37:20 <sech1> like 2 MB cache per core, but it's not shared between cores
16:37:31 <sech1> which will save some energy and a ton of area
16:37:37 <hyc> good point
16:37:55 <hyc> yeah, plenty of easy optimizations if they don't need to run general workloads
16:38:05 <kico> I guess that "whoever designs a randomx chip will help in advancing cpus" is still true but I never expected for riscV :D
16:38:25 <hyc> lol it kinda makes sense, no licensing restrictions
16:38:26 <sech1> risc-v only because no need to pay fees
16:38:31 <hyc> and it was the new hotness already
16:38:37 <sech1> they didn't want to pay ARM fees :D
16:38:37 <kico> :)
16:39:10 <kico> all gud as long as they kinda contribute to riscV development iGuess
16:39:13 <hyc> might be time for me to order a risc-v box from aliexpress
16:39:31 <hyc> kico: wouldn't hold my breath on that
16:39:43 <kico> yeah sure
16:39:57 <kico> being optimistic here iGuess
16:40:00 <hyc> but would be funny to see any bitmaintech names in LLVM/clang/gcc contributions 
16:40:01 <sech1> btw, back in early 2022 those "ASIC" workers we saw, they all had 250-300 kh/s reported hashrate on nanopool
16:40:22 <sech1> I guess after 2 years of operation, they had to disable some of the units and reduce to 212 kh guarantee
16:40:58 <hyc> overclocked and died :P
16:42:17 <kico> does this mean that "pow fork" is delayed for the time being?
16:42:46 <hyc> this has no impact on pow decisions
16:42:50 <selsta> The partial verification changes are useful for other reasons.
16:43:19 <kico> sure I mean no need for a "urgent fork" ?
16:43:29 <hyc> yeah, the double hash to improve verification speed is worthwhile all on its own
16:43:42 <selsta> I don't think there were any plans for an emergency PoW change
16:44:13 <kico> ok cool I got the wrong impression my bad :)
16:45:40 <hyc> at this point tweaking the algo won't stop anyone, they're obviously using CPUs now so they can just update their firmware 
16:46:09 <sech1> I doubt tweaks will stop these devices, they're proper CPUs from the looks of things
16:46:09 <kico> yeah but we should not care about them anyway
16:46:27 <hyc> the only things we could change that would make a substantial difference would be the on-chip cache requirements, and that would hurt all CPUs as well
16:46:33 <DataHoarder> moar L3, time to force multi threaded communication and atomics!
16:46:34 <sech1> of course, we can target tweaks to kill these specific devices
16:46:43 <sech1> like increase L3 until it exceeds what they have
16:46:58 <kico> sure but do we want to ?
16:47:05 <sech1> No need
16:47:09 <kico> not like they're super efficient
16:47:13 <sech1> Like I said, they've been mining for almost 2 years now
16:47:18 <hyc> it would be fun to see their 2+ years of effort poof 
16:47:25 <sech1> and they don't have superior efficiency
16:47:36 <hyc> but anything we did like that would only have a temporary effect
16:47:38 <kico> hyc, they already did ROI by now
16:47:49 <sech1> it's better that we make tweaks that make regular CPUs more efficient
16:47:53 <sech1> like my CFROUND tweak
16:48:10 <sech1> it will make Zen4 more efficient than these ASICs
16:48:10 <kico> yeah I think we should care for regular users and not jihan
16:53:52 <sech1> So far, RandomX works as it's been designed. If we do tweaks, we should focus on current and next generation CPUs.
16:54:26 <hyc> agreed
16:54:45 <m-relay> <x​fedex:matrix.org> Ryzen 9 5950X (Zen 3, launch date 2020) is more power efficient than this ASIC.
16:55:44 <hyc> I doubt they spent any effort on tuning the chips, and all their effort was on cramming a bunch of cores into a single case.
16:55:48 <sech1> The only question now is the price
16:56:34 <m-relay> <x​fedex:matrix.org> I estimate that it would have to cost ~$3500 or less to be worth buying that ASIC over Ryzen CPUs
16:56:46 <hyc> probably the best contriution they'd make to the world is in their physical build and cooling layout
16:57:37 <sech1> They have ~2000 of those ASICs mining now
16:58:07 <m-relay> <k​4r4b3y:karapara.net> How did you get to that estimate?
16:58:32 <sech1> judging by the hashrate of that ASIC miner (we know now it was Bitmain)
16:58:47 <sech1> they have ~17% of the network
16:58:56 <sech1> so around 400-450 MH/s
16:59:08 <sech1> Not sure if they ever got their money back :D
16:59:39 <hyc> all the more reason for them to start selling :P
16:59:42 <m-relay> <x​fedex:matrix.org> sech1: sorry, what is your CFROUND tweak?
16:59:59 <sech1> it's a tweak that changes how often CFROUND instruction is triggered
17:00:18 <sech1> it can boost Ryzen hashrate by up to 10% without changing anything else in RandomX
17:00:41 <m-relay> <x​fedex:matrix.org> is there any link for it?
17:00:49 <sech1> so we had 10% "free" hashrate all this time
17:01:00 <sech1> No link, but it was discussed in this channel before
17:03:56 <m-relay> <x​fedex:matrix.org> Found it: https://libera.monerologs.net/monero-pow/20230817
17:23:15 <hyc> hmmm. I wonder - would it be more efficient to add pool support to monerod (so that its internal miner could work with p2pool) or
17:23:47 <hyc> add hasher rpc to xmrig - so that it could do verification for both monerod and p2pool
17:41:35 <gingeropolous> so even after all the fuss in the original monero asic war, an asic company *still* decided to build and mine in secret
17:42:52 <hyc> lol, of course.
17:43:02 <hyc> that's what they do, why would they change
17:43:34 <m-relay> <x​fedex:matrix.org> hyc: the simplest thing to do which does not require any code change is running monerod with MONERO_RANDOMX_FULL_MEM and running p2pool with --no-randomx
17:43:49 <gingeropolous> and i doubt they even made these things capable of running anode, even though is a damn CPU
17:44:04 <gingeropolous> true milkers, not adding anything to the ecosystem
17:44:09 <m-relay> <x​fedex:matrix.org> gingeropolous: they OBVIOUSLY didn't
17:44:11 <hyc> xfedex: yes of course. I wrote that code.
17:45:19 <gingeropolous> lulz, that nitter page; "guess the price". they are trying to find what the market will tolerate to buy their burnt out silicon
17:45:25 <hyc> I use it 24/7 on my rockpro64. but I currently am not running xmrig on it because there wouldn't be enough RAM.
17:46:23 <m-relay> <x​fedex:matrix.org> I think the miner integrated in p2pool has performance similar to xmrig
17:47:16 <m-relay> <x​fedex:matrix.org> Does your device have enough RAM to run monerod without full memory and p2pool with RandomX fast mode?
17:48:00 <hyc> probably. but that's still a couple hundred MB I'd prefer not to spend. anything that takes away from available FS cache hurts monerod perf
17:48:35 <sech1> and memory limited devices, it's best to have full dataset in monerod and make everything else use calc_pow RPC call
17:48:41 <sech1> *on memory
17:49:27 <sech1> p2pool integrated miner has 5-10% lower performance even if you help it with manual MSR mod
17:49:42 <sech1> because there are many code-level optimizations in xmrig
17:50:41 <hyc> so... it might be worthwhile to add calc_pow RPC to xmrig itself, and point both monerod and p2pool at it
18:00:57 <sech1> that's kind of backwards
18:01:26 <hyc> why? let the fastest code do all of the hash computations
18:01:35 <sech1> xmrig optimizations were always designed to make it faster, but never cared about being 100% correct all the time
18:01:42 <hyc> ah
18:01:58 <hyc> ok never mind
18:02:06 <sech1> granted, it's correct now but I'm not sure I can give a guarantee :D
18:02:39 <hyc> then back to the earlier idea, let monerod's miner work with p2pool
18:02:54 <sech1> because I don't remember exactly, but at some point I considered optimizations that would make it 1% faster at a cost of 0.1% invalid hashes, for example
18:13:05 <DataHoarder> -f-unsafe-randomx-optimizations
18:13:34 <sech1> well, just in case we want to brick this ASIC, I already found an instruction that's available on x86 and ARM (not all x86 and ARM, but many), but 100% is not there on that RISC-V chip.
18:15:15 <DataHoarder> on *that* risc-v chip?
18:15:34 <DataHoarder> do we know what they have, or custom design? given extensions are plenty
18:16:24 <sech1> If they have risc-v chip, I know what they *don't* have :P
18:16:34 <sech1> risc-v is an open standard, after all
18:17:09 <sech1> and an instruction I picked, it's not even a finalized draft in risc-v, lol
18:18:59 <sech1> *it's not ratified yet
18:19:20 <sech1> and considering that they physically created their ASICs in 2021... It's 10000% not there
18:20:45 <DataHoarder> yeah, just saying that the standard includes instructions but there are many custom extensions on these risc-v chips out there
18:20:52 <DataHoarder> they probably have none though :D
18:22:35 <sech1> They use RV64GC+Zk at best, which leaves a lot of unsupported instructions
18:23:22 <sech1> RV64GC is a "standard" 64-bit RISC instruction set, Zk is needed for AES (I think)
18:25:44 <DataHoarder> yeah, unless they placed it in the non-standard extension in the "Guaranteed Non-Standard Encoding Space"
18:26:28 <sech1> I bet they used as much standard stuff as possible to reduce costs
19:42:25 <Inge> 1350w? What is the claimed performance of the thing?
19:42:45 <sech1> 212 kh/s
19:42:58 <sech1> about the same efficiency as Ryzen 5950X/7950X
19:46:14 <Inge> I mean... I'm partial to RISC-V getting a leg up :D
19:48:32 <sech1> On the other hand, adding an instruction that's not ratified in risc-v yet, will make trouble for all risc-v systems for the foreseeable future, not just for this ASIC. It's not ideal.
19:49:10 <sech1> It will not make RandomX on RISC-V impossible, but it will make it noticeably slower
20:05:53 <m-relay> <p​olar9669:matrix.org> So are we now going to favour particular cpu architectures ? Because someone made cpus to mine monero
20:12:10 <DataHoarder> considering possibilities doesn't mean they will be pushed for at all
21:08:54 <gingeropolous> yeah, i mean, randomx is cpu-bound, and this RISC-V system is CPUs. I don't see the sense in modding the PoW to counter this development. I think time has already addressed the concern, and will continue to.