13:56:49 <tevador> sech1: which CFROUND tweak?
13:57:12 <sech1> calling it less frequently
13:57:22 <sech1> because right now it's 10% of loop time
13:57:47 <sech1> so if it's called 1/16th of a time (for example), it will boost hashrate by 10%
13:57:53 <sech1> on AMD CPUs
13:58:54 <sech1> we can use something like "some 4 bits of src register == mod.cond" to make it run 1/16th of a time
14:03:49 <tevador> we'd have to be careful with this not to underutilize the nonstandard rounding modes
14:07:03 <tevador> there are basically 2 options for this "ASIC" if it turns out to be real: 1. custom board with a bunch of ARM/RISC-V cores 2. VLIW core that implements the RandomX ISA in silicon
14:07:23 <tevador> 2. should be possible to brick
14:51:26 <sech1> I don't think it will be possible to brick
14:51:52 <sech1> If they weren't stupid
14:52:08 <sech1> If they were, simple program size increase can brick it (it will not fit into internal buffers)
14:52:38 <sech1> Regarding CFROUND, it will still be executed 2048/16=128 times per program
14:54:55 <tevador> at best they could have implemented some kind of microcode to handle new instructions, which means we can't brick it, but we can make it slow
17:32:29 <sech1> There is a 1.4 GH/s miner on Hashvault now
17:40:00 <gingeropolous> pretty odd they are going after that 0.6 xmr block reward, but i guess ethereum mining is dead 
17:40:14 <nioc> https://miningpoolstats.stream/monero
18:06:09 <m-relay> <g​ingeropolous:monero.social> i hope they actually sell this one. i wanna see what it is
18:12:11 <sech1> this miner looks more like another cloud server hacker
18:45:44 <hyc> why do we want to reduce CFROUND and "boost hashrate" just for the sake of boosting hashrate?
19:04:39 <hyc> hmm. 2023-08-18 17:36:43.294 W There were 94 blocks in the last 90 minutes, 
19:14:38 <sech1> @hyc because it's 10% more RandomX IPC for all existing Ryzen and EPYC CPUs?
19:15:22 <sech1> less impact on Intel, but it's the point of RandomX - to be as close to real CPUs as possible
19:16:02 <sech1> so if some tweak gives better performance/watt on real CPUs and doesn't hurt ASIC resistance, it's a good tweak
19:16:39 <sech1> that solo miner dropped from 1.4 GH/s to 950 MH/s
19:19:25 <sech1> CFROUND tweak will make it 10% more efficient on Ryzens, 0-1% more efficient on Intel, and presumably will have the same ASIC resistance
19:41:06 <m-relay> <h​bs:matrix.org> Has it been considered to have opcodes shuffled from one run to the other? Could that possibly affect a putative ASIC?
20:48:18 <tevador> the CFROUND tweak makes sense to implement; I also have some ideas for new instructions that could be added