<p​olar9669:matrix.org> So only x5 would be affected ? Unless they have have a aes coprocessor

I have no idea how it will be affected. The possible range of outcomes are from nothing changed to fully bricked

What's more important is that consumer CPUs will be used more efficiently: 5-10% more RandomX instructions executed per second on each core, 2x more AES computations "for free"

Most likely result for X5 will be 30% slowdown, if they implemented AES as a separate chip to initialize the scratchpad, and they don't have AES in their RISC-V CPUs

<p​olar9669:matrix.org> Consumer? You mean available to retail?

yep. that you can buy at your local bestbuy / costco / walmart

<p​olar9669:matrix.org> So only when rsic-v is available at a US retail store it would be considered non-asic-cpu?

<p​olar9669:matrix.org> So only when rsic-v is available at a US retail store it would be considered as consumer cpu ?

<p​olar9669:matrix.org> Btw rpi4 is available at Walmart

You seem to be trying to twist things on purpose. This is called disingenuousness. It is regarded as a dishonest way to have a conversation. I suggest you try to avoid it.

(Not only here, but several times before. One or twice is fine, but a pattern emerges)

Being constructive is best, if you can.

RISC-V is not an asic, and it's not a cpu. It's an open source instruction set and architecture

When risc-v based cpus will be a noticeable part of Monero hashrate, then yes we'll be taking it into account in future tweaks (if any)

And tweaks will be based on an architecture of actual cpus mining at the time

Also, we still don't know X5 architecture. Maybe it has asic chips inside, and risc-v cpu is only used as controller/main cpu on the board

<p​olar9669:matrix.org> Anyway to know which cpus currently mine monero ?

<p​olar9669:matrix.org> Ok, will try avoid it

can still order SiFive SBCs if you want to test and feel like writing a JIT

we need some perf impact numbers on arm64 too for these new changes

I'll try on my M1 macbookpro when I get a chance. can also try on my rk3399 rockpro64 later

my intels seem to be taking a slight hit

and i can't get huge pages on this one machine. blargh

hrm, huge pages problem hitting me on my A6-5200 as well. I use "sudo sysctl -w vm.nr_hugepages=1250" but it still says cache allocation fails

your i7-6820HQ gets too low hashrates, you should double check it

7700k only got 0.2% slower, we can ignore it

It's expected, because they were already fast with CFROUND instruction, so they don't get this boost

ah yeah the 6820 boots with some stupid throttle. forgot about that

are we sure this isn't actually penalizing Intel further? they were already inferior to AMD here

0.2% is negligible, you have to consider that we're adding extra 262144 AES rounds and yet the hashrate barely changed

If one part of Monero network (Intel) stays with the same hashrate, and another part (AMD) gets 5-10% more hashrate, then I count it as a win.

For Monero network as a whole

The important part is Intel CPUs still keep their hashrate, even when doing extra AES rounds

btw latest Intel CPUs have faster AES than AMD (3 vs 4 clock cycles latency)

<c​harutocafe:matrix.org> does RandomX favor any specific ISAs?

no, RandomX instruction set is a common denominator and it translates almost directly both to x86 and ARM

<c​harutocafe:matrix.org> do you know if anyone has tested RISC-V, PPC, or other ISAs?

We don't have JIT compiler for these ISAs

so it's not comparable

btw, based on the 7700K benchmark, every hash needs 4584 extra cycles, so that's >57 AES rounds per cycle, not even an ASIC can do this

at this scale (0.2%) it's hard to tell the real impact of changes, and count extra cycles

it can swing the other way next time it's tested

also, Intel CPUs should be tested with single thread

because they all run 1 thread per core

gingeropolous can you test your Intel CPUs with 1 thread?

Use command line "--mine --jit --largePages --threads 1 --affinity 1 --init 16"

Added my numbers for single thread Ryzen 7 1700, because it also runs 1 thread per core when mining

It's even bigger speedup (more than 10%)

I wanted to test on macOS ARM but seems the PR is not ready for that yet

magerd revert doesn't work. rm- r it is

still seeing that drop on single thread sech1

Did you run each test several times? I found that it can jump +-5 h/s in both directions

I run each test 5 times and choose the highest reported hashrate

i did just get Performance: 746.367 hashes per second on v2

and v1 Performance: 747.852 hashes per second

noice

wish i had the newest intel chips

so -0.2%

I could test it on Hetzner auction servers, but the newest they have is Core i7-8700

and the first Intel CPUs with faster AES (3 cycle latency) are Ice Lake (only mobile) and Rocket Lake (11xxx desktop series)

so the 13700KF would do it?

<c​harutocafe:matrix.org> sech1: is a JIT compiler for other ISAs expected? especially RISC-V since its anticipated growth?

Eventually (c)

gingeropolous 13700KF would do it, yes