<e​longated:matrix.org> Are we fighting risc-v miners ? Or bitmain can update code and still use it ?

sech1, wouldn't it be possible to take a look at the nounces and try and figure for how long these have been mining? x9 I mean

It looks like they use the same firmware, so nonce patterns didn't change

You can measure the increase of nonce patterns over time

irc.gammaspectra.live/00bff44cf801ed35/out.png

remade nonce pattern, from randomx fork or so to last block today

zoom into their patterns irc.gammaspectra.live/73e2bfbf1b91b112/out.png

nonce % 2^28, remove groups nonce / 2^28 that are 0 or > 10 (0 has a lot of contamination, and higher ones don't appear in nonces)

then their pattern is on the bottom 1/16th of this. That is the range of the plot

that has their sub-patterns

so they've improved effciency 1.6x. About what we expected.

still a shame that other commodity risc-v boards aren't very good

the best CPU rig that I'm aware of is 7945hx 19.2kh 85w @wall

225 h/J

X9 is 400 h/J

not even 2x better

Still, we need RandomX v2

yeah. 1.77x better

I wonder how many RAM sticks they put into X9

must be at least 60

with the price of RAM going thru the roof again, Bitmain would make more money cannibalizing the existing X9s for their RAM

it's silly...

although, that 7945HX can get 20 kh/s with more power, and it runs on a single stick of DDR5 (tuned timings)

DDR5 now is 4x its price in September...

btw I'm done with RISC-V code for XMRig, the next step is to bring to upstream repo and then finally implement the v2 part for RISC-V. Then only the small things will be left

I even added hardware AES support for RISC-V

Without actual hardware I can test on :D

yeah, RAM prices are insane

lol. maybe bitmain has already tested it :P

maybe :D

I think right now the RAM is worth more than it could ever make from mining

I think that RandomX program size must be bumped a lot for v2

like from 256 to 320 instructions (+25%)

because Zen4/Zen5 wait a lot for data from RAM

they became much faster than Zen2

ah, make more use of instruction cache?

more use of computing capacity

sounds good

they have better IPC and better clocks than 3700X which was the king when RandomX released

Instruction frequencies will need to be adjusted to avoid getting FP registers into +- infinity territory

because that will hurt entropy

but yeah, Zen5 can do 320 instructions instead of 256, almost at the same hashrate (and with CFROUND fix)

25% better ipc huh

I wonder how that affects arm64, Apple M2

L2 caches per thread have also grown quite a bit, while L3 have stayed ... the same

without X3D ofc

FSQRT instruction is the best to keep FP registers away from overflow/underflow. It basically halves the exponent

I'm sure bitmain bought RAM for these inb4 the crazyness

they usually "test" their HW for 1 year

this miner has probably been in the making for a few years now

It's probably been in the making ever since they started selling (=dumping) X5

Oh hi tevador

exactly :P

Which means they already have X11 or something in the works

hehehe

x5, x9 ... x13?

new "ASIC"?

tevador I plan to work on RandomX v2 in January and prepare the complete pull request when it's done

cool

btw I added RISC-V vector JIT + dataset init + vector AES + hardware AES code to XMRig

All that code will be added to upstream too

if they are mining with that it's not with the same nonce pattern afaik

And for v2, I want to increase program size, like a lot (+25%)

256 -> 320

and increase FSQRT frequency to keep FP registers in range

the density of the nonce pattern has decreased over time, though I now need to calculate the actual hashrate of the bands (weighted by difficulty)

btw at this point, they can just take stock XMRig (dev branch) and use it on X9 :D

so nonce pattern will be the regular one

now, yes. but not say couple of years ago since they released other one

yes

are there any existing risc-v chips with hardware AES?

my Orange Pi RV2 has vector extensions but not AES

When I asked, I got this answer: "Bunch of SiFive cores has crypto extensions. X280, X390, P470, P670, P870."

there are scalar and vector crypto extensions

QEMU supports everything so I was able to verify my code, but it can still break on the real hardware

I implemented scalar crypto extensions

zknd/zkne

I haven't heard about vector AES on RISC-V, and I read all the specs

That one I didn't read

It's not mentioned in github.com/riscvarchive/riscv-v-spec/releases/tag/v1.0

so it's a newer extension

oh well, another version to implement?

luckily RandomX AES is not a lot of code

According to the latest RVA profile, vector crypto should be preferred: github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified

"The scalar crypto extensions Zkn and Zks that were options in RVA22 are not options in RVA23. The goal is for both hardware and software vendors to move to use vector crypto, as vectors are now mandatory and vector crypto is substantially faster than scalar crypto."

oh, they even have vror instruction for vector registers

I guess I'll added detection of zvkb and zvkned extensions too, before bringing it upstream

*add

yeah, I'm not a fan of having two hardware AES implementations for RISC-V

I already have vectorized soft AES, so vectorized hard AES only makes more sense

"vectors are now mandatory" that's good

Btw, I'd also suggest to bump the CBRANCH jump frequency to at least 1/32 (currently 1/256).

HashX was broken by GPUs because of insufficient branching.

HashX is not RandomX, it doesn't do 2048 loop iterations

25/256*2048 = 200 taken branches per program on average

and it's just one program at a time which can be compiled for GPUs, if I read the description right

Then yes, only branching can save it from GPUs.

I forgot why we chose 1/256. Perhaps the misprediction overhead was measurable at 1/128, but it could be retested with current hardware.

because of misprediction stalls in the pipeline

these branches are essentially random and can't be predicted

I doesn't need to hurt with SMT because the other thread can run.

It*

> To take advantage of speculative designs, the random programs should contain branches. However, if branch prediction fails, the speculatively executed instructions are thrown away, which results in a certain amount of wasted energy with each misprediction. Therefore we should aim to minimize the number of mispredictions.

oh yes, and this too

> Unfortunately, we haven't found a way how to utilize branch prediction in RandomX. Because RandomX is a consensus protocol, all the rules must be set out in advance, which includes the rules for branches.

branch prediction - isn't that specific for the CPU? nowadays the predictors for speculation can remember values of registers at certain branches, and if they follow a pattern

so 200 taken branches per program = 200xN wasted instructions executed and rolled back

Still doesn't explain why 1/256 was selected rather than 1/128.

N = pipeline depth

the smallest possible value was chosen

because we already have a lot of CBRANCH instructions in the code

they needed to be frequent to limit instruction reordering optimizations for simple in-order CPUs

The question is, 200 taken branches per program is too little or enough?

btw increasing program size will also increase the number of branches

Yes, it might be enough just to increase the program size.

and frequent branches also limit VLIW CPUs

and number of CFROUND on avg :)

but also decrease frequency they switch

CFROUND was nerfed in another way in v2

indeed

CBRANCH 1/25 is the second most frequent op after FMUL_R 1/32

err, 25/256, 32/256

Increasing program size to 320 will require increasing FSQRT_R from 6/256 to 7 or even 8, to keep FP registers in range

so some other frequencies will need to be reduced

IXOR_R can probably be a donor.

15/256

it doesn't do much in terms of energy required

unlike FSQRT_R

XOR is just carryless ADD in GF(2) :)

making RandomX burn more energy and in places where AMD/Intel CPUs are best optimized (FPU) is the goal

sounds counter-intuitive :D

specifically float64

because in the end it will make AMD/Intel CPUs more efficient, relative to X9

where the ai/accelerator stuff is f32 or less :P

Internally in the CPU, sqrt is implemented as a table lookup + a few multiplications, so it burns more energy than even FMUL

*a few FMAs

Zen5 misprediction penalty is ~15 cycles, so ~24000 cycles per hash are wasted currently. It might be OK.

much more is wasted when it's waiting for dataset read

it's still keeping most of the CPU powered on in these moments

which is why 256 -> 320 increase is crucial

if it's powered on, it only makes sense to make it keep executing instructions until dataset read is guaranteed ready on most systems

Btw, reducing IXOR_R would have a side effect of reducing the mixing of integer registers.

yes, but letting FP registers almost always overflow/underflow will hurt entropy even more. Need to do real tests with v2 and 320 program size to make sure their exponents cover the full range, but rarely reach overflow/underflow

It might be better to transfer from FMUL_R, which is the main cause of needing a higher FSQRT_R frequency.

then it will be obviouse which sqrt frequency is the best

we don't need a lot of square roots, because they halve the exponent each time

so it's logarithmic dependency

FMUL_R can be a donor too

Probably RANDOMX_FREQ_FMUL_R 32 -> 30 and RANDOMX_FREQ_FSQRT_R 6 -> 8

too high frequency will reduce exponent range, so we will need tests

maybe 6 will still be enough, because the amount of square roots will also increase by 25%

You will need to rerun this: github.com/tevador/RandomX/blob/mas…#251-floating-point-register-groups

However, I can't find the source code for the test

not a problem, I will just modify the interpreter to collect the statistics

hyc MO discord has a sensible idea: if X9 has to pack this much RAM inside, maybe it's soldered RAM this time? It takes much less space, and they don't need to put a 16 GB memory stick per CPU. 2x2 GB memory chips will be enough

So double the dataset in v2? :D

^ I tried allocating the dataset via WASM on browser and it just worked btw

4 GB dataset / 512 MB light mode is okay now, it's not 2019 anymore

they lowered from 4 GiB to 2 GiB afaik

btw 4 GB dataset was considered for the original RandomX

yeah, I remember reading that up

or maybe they brought that back up again v8.dev/blog/4gb-wasm-memory

<s​yntheticbird:monero.social> sech1. Exactly we're in 2025. RAM is more expensive than ever

<s​yntheticbird:monero.social> WE NEED 10KB DATASET NOW

<s​yntheticbird:monero.social> I CANNOT SURVIVE WITHOUT IT

<s​yntheticbird:monero.social> HEEEEEELLLLLLLPPPPPPPPPP

Even single DDR4 stick is 8 GB, so it won't change anything in terms of what miners need to buy

Raspberry Pi's will lose, but using them for mining is a bad idea anyway. For anything else, they can use light mode

Remember that the current monerod code allocates two caches, so it already uses 512 MB with light mode.

Any increases in footprint will bump up hardware requirements

<e​longated:matrix.org> High time we increase hw requirements

it may make a lot of current nodes & miners nonviable

<e​longated:matrix.org> Nodes ? Yes, botnets will be affected

yes, nodes too. dataset ram will compete with blockchain cache

light mode will require 1 GB then, so 2 GB minimum for running monerod

<s​yntheticbird:monero.social> Are we sure we wanna piss off one of our significant portion of the hashrate while operations like qubit showcased the fragility of your current miner landscape

<s​yntheticbird:monero.social> our current*

<s​yntheticbird:monero.social> Yes, i believe botnets are a significant portion of the hashrate

<s​yntheticbird:monero.social> you may now proceed to shame me

I'm not sure about dataset increase just to brick the X9. Because it's not guaranteed - maybe they have 8 GB per CPU, so it won't stop them