13:56:49 sech1: which CFROUND tweak? 13:57:12 calling it less frequently 13:57:22 because right now it's 10% of loop time 13:57:47 so if it's called 1/16th of a time (for example), it will boost hashrate by 10% 13:57:53 on AMD CPUs 13:58:54 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 we'd have to be careful with this not to underutilize the nonstandard rounding modes 14:07:03 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 2. should be possible to brick 14:51:26 I don't think it will be possible to brick 14:51:52 If they weren't stupid 14:52:08 If they were, simple program size increase can brick it (it will not fit into internal buffers) 14:52:38 Regarding CFROUND, it will still be executed 2048/16=128 times per program 14:54:55 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 There is a 1.4 GH/s miner on Hashvault now 17:40:00 pretty odd they are going after that 0.6 xmr block reward, but i guess ethereum mining is dead 17:40:14 https://miningpoolstats.stream/monero 18:06:09 i hope they actually sell this one. i wanna see what it is 18:12:11 this miner looks more like another cloud server hacker 18:45:44 why do we want to reduce CFROUND and "boost hashrate" just for the sake of boosting hashrate? 19:04:39 hmm. 2023-08-18 17:36:43.294 W There were 94 blocks in the last 90 minutes, 19:14:38 @hyc because it's 10% more RandomX IPC for all existing Ryzen and EPYC CPUs? 19:15:22 less impact on Intel, but it's the point of RandomX - to be as close to real CPUs as possible 19:16:02 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 that solo miner dropped from 1.4 GH/s to 950 MH/s 19:19:25 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 Has it been considered to have opcodes shuffled from one run to the other? Could that possibly affect a putative ASIC? 20:48:18 the CFROUND tweak makes sense to implement; I also have some ideas for new instructions that could be added