yeah that's their typical procedure. they just have to be more careful with timelines since we can change RandomX out from under them

<e​longated:matrix.org> ‘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

"I" sounds centralized, not "we"

<e​longated:matrix.org> They I we same gang changing algo to suit their botnets

You're welcome to push "New pull request" button then github.com/tevador/RandomX/pulls

The consensus in Monero community is to keep mining viable on general purpose CPUs. This is what we do, no more, no less

1 CPU = 1 vote, remember that?

<e​longated:matrix.org> risc-v is a cpu

RISC-V JIT is available in the reference repository, it's supported

Moreover, I've been working on adding support for RISC-V vector extensions and hardware AES (it's in XMRig dev branch now)

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

<e​longated:matrix.org> I appreciate you not killing support for a non-proprietary processor.

<e​longated:matrix.org> 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.

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

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)

Now repeat for other parts :)

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

Hashrate will not stay the same, because v2 hash will be heavier on compute. But final parameters are not decided yet.

yeah, I mean, equivalent ratio

for example - lengthening the program didn't have that much impact on modern CPUs

do we have a listing of the efficiency of randomx with modern apple chips?

<s​yntheticbird:monero.social> i don't need proof apple chips are the most efficient

<s​yntheticbird:monero.social> because apple is perfect

<s​yntheticbird:monero.social> the apple will destroy monero

<s​yntheticbird:monero.social> stay tunes in my podcast for more incredible revelations

<e​longated:matrix.org> 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 ?

afaik the current CFROUND impacts all Zen-class cpus

EPYC is Zen, Ryzen is Zen

<e​longated:matrix.org> 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

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.

<e​longated:matrix.org> Changes done are to improve efficiency only ? or changes are also done to reduce efficiency of x9 and kind

Re-read my message above

<e​longated:matrix.org> I read that you are making changes to hurt the other bird, is the specific change to hurt or increase efficiency of other bird ?

yes

I already said everything many times in many place

Don't want to feed trolls anymore

<e​longated:matrix.org> Okay, keep rolling