03:00:30 yeah that's their typical procedure. they just have to be more careful with timelines since we can change RandomX out from under them 08:32:47 ‘We’ sounds so centralised, wants to be a rug CPU miner 😂; feels like this is a botnet operator pushing to change the algo if a CPU was made which is better optimised 08:38:32 "I" sounds centralized, not "we" 09:34:12 They I we same gang changing algo to suit their botnets 10:16:13 You're welcome to push "New pull request" button then https://github.com/tevador/RandomX/pulls 10:17:31 The consensus in Monero community is to keep mining viable on general purpose CPUs. This is what we do, no more, no less 10:17:50 1 CPU = 1 vote, remember that? 10:19:20 risc-v is a cpu 10:27:30 RISC-V JIT is available in the reference repository, it's supported 10:28:50 Moreover, I've been working on adding support for RISC-V vector extensions and hardware AES (it's in XMRig dev branch now) 10:40:27 There are a few ways to completely kill any RISC-V CPU performance, we know about them, but they're not a part of RandomX v2 changes 11:41:47 I appreciate you not killing support for a non-proprietary processor. 11:41:48 But having the view that they don’t want Bitmain to work on building miners for mining Monero even if they are using CPU is a wrong approach. Any legitimate mining hashrate we can get to fight Qubic-type attacks should be appreciated; people buying hardware to mine XMR shouldn’t be shunned away. 13:15:08 The view is that RandomX should be the most efficient when run under general purpose CPUs and what they are best optimized to. In this case, there's a difference between efficiencies and changes can bring it to par 13:17:10 V2 existing changes already did changes before this, for example, the slow round mode changes on AMD was affecting these comparatively to Intel ones without any plus. So, change to frequency on these switches made them equal (and reduced ways a custom cpu could win over them) 13:17:28 Now repeat for other parts :) 13:19:58 It's quite likely the hashrate of existing CPUs stays the same or improves, as they have become better (but we aren't letting them run at their best ability due to parameters picked in original RandomX). Also likely that these riscv miners would be still vastly performant, just reducing the gap. If they upgrade them ofc at all 15:08:55 Hashrate will not stay the same, because v2 hash will be heavier on compute. But final parameters are not decided yet. 15:13:23 yeah, I mean, equivalent ratio 15:13:53 for example - lengthening the program didn't have that much impact on modern CPUs 15:15:01 do we have a listing of the efficiency of randomx with modern apple chips? 16:05:30 i don't need proof apple chips are the most efficient 16:05:31 because apple is perfect 16:05:34 the apple will destroy monero 16:05:45 stay tunes in my podcast for more incredible revelations 16:19:17 Does the proposed randomxv2 changes make non consumer/general cpus like epyc more efficient and also reduces efficiency of non-proprietary cpus that are used by bitmain ? 16:39:37 afaik the current CFROUND impacts all Zen-class cpus 16:39:48 EPYC is Zen, Ryzen is Zen 18:37:54 CFROUND is the only change that will make bitmain miners less efficient? Or some other change is made on purpose unrelated to “consumer” grade hw 18:41:47 Changes are made to improve CPUs efficiency. X9 was designed/balanced specifically for RandomX, so any changes will make it less efficient - no matter what we change. So we change things that will improve things for commodity CPUs. Two birds with one stone. 18:44:07 Changes done are to improve efficiency only ? or changes are also done to reduce efficiency of x9 and kind 18:58:07 Re-read my message above 18:59:54 I read that you are making changes to hurt the other bird, is the specific change to hurt or increase efficiency of other bird ? 19:02:37 yes 19:02:58 I already said everything many times in many place 19:03:17 Don't want to feed trolls anymore 19:16:38 Okay, keep rolling