hmm sech1, but each one currently does get different initialization entropy

and each slot does get xor'd along the way with register data, which means you still have to store 3 values total across iterations

speaking of zen-c, is there any major performance difference w/ RX on zen-c cores? after accounting for clock speed differences, that is

clocks are lower and caches are smaller, but possibly cache latency?

on 4/4c I see it's ~5ghz/3.7ghz so definitely some raw hashrate difference, but IPC is similar no?

afaik they left the other stuff equal in zen5c besides lowering l3

it's not similar to intel efficiency cores that change implementation

chipsandcheese.com/p/testing-amds-bergamo-zen-4c-spam < this says that L3 gets also a hit to latency on zen4c

just finished building gcc/g++ 14.3.0, still failed to build. Maybe gas is also out of date

debian paste refused the output: Could not add your entry to the paste database:

Spam detected: Content is primarily a list of links or hashes.

Yes, risc-v vector aes instructions are very new, so gas must be new too

I'll try to get that built...

Orange Pi RV2 has gcc 15 out of the box (in the distro from their official site), so it's not that bad for risc-v boards

Licheepi appears to be abandoned, they haven't updated their OS image in 2 years

a shame, since I got 16GB of RAM in mine

ok. latest gas built, got past there

all tests passed, SSSE/AVX skipped

and fast reciprocal skipped

mining with 1 thread paste.debian.net/hidden/6c5e26ee

Nice

I see you're testing the final v2 code, not just that RV64 vector PR?

No large pages? You have 16 GB RAM, you can enable them

ah yes, I thought this branch was just the PR merged on

do I still need to check just the PR itself?

4 threads mining paste.debian.net/hidden/fc6d9c0d

The PR itself is included in v2 branch, so if it works, it works

ok then I'm going to approve the PR

And large pages?

checking that now

That's a more powerful board than RV2

better hashrate

lemme see, how many hugepages do I need here

I always set it to 1280

1200 should be enough too, but 1280 is a more round number :)

ok

I set 1200

largepages paste.debian.net/hidden/84f42e24

Definitely faster than RV2

Nice to see it working

too bad no vector AES but all good

RV2 could do 110.7 h/s max on v1 (with XMRig)

And I think 99 h/s on v1 with randomx-benchmark

and 67 h/s or so on v2

RV2 doesn't have AES too

I don't know of any boards that have it now

yes, found in the chat log: "Orange Pi RV2 (Ky X1 CPU, software AES): v1 99.3 h/s, v2 67.1 h/s"

have you tried PR#174, monsterpages?

seems decent enough

No, I haven't tried it yet. But I can try it when I get back home, in a week or so

cool

"Memory initialized in 29.9764 s"

RV2 initializes dataset in 15 seconds

Thanks to vector code

nice

And maybe also because it's 8-core

did you look at all at the v0.7 vector instructions? I wonder if the stuff you used is all present in there

granted, only THead's patched gas supports it

No, I downloaded v1.0 vector specs and only looked at that documentation

v0.7 was an intermediary standard, all new boards will have v1.0

ok. I have both v0.7 and v1.0 docs around here but haven't looked at any of it in a while

bitmain also trying to contact me on reddit paste.debian.net/hidden/014a2749

> We want to discuss/clarify on the new updates on Monero.

personally I don't see why anything needs to be discussed, everything is there in the github repos

and the irc channels and matrix rooms are public

PR merged, github.com/SChernykh/RandomX/tree/v2 rebased

Bitmain can't IRC, apparently

Is it blocked in China?

matrix :)

They can make a Github issue, ffs :)

Damn, that FreeBSD packaging bug is still not fixed... github.com/SChernykh/RandomX/actions/runs/21253931716/job/61162948713

What does Bitmain tech team want to discuss anyway, we even have RISC-V code for them to use now :)

yeah they don't even have to lift a finger

just send them the irc logs

btw, SG2044 is most likely what they're using now browser.geekbench.com/v6/cpu/8661173

Does SG2044 have hardware AES, or do they use some kind of SoC with AES accelerator on it - that is the question...

SG2044 is a powerful beast, especially in the memory department

> 1 Processor, 1 Core, 64 Threads

SG2042 4 memory controllers, 4 channels. SG2044 32 memory controllers, 32 channels. What a beast.

dataset for the core is afaik xrvm.com/product/xuantie/C920 xrvm.com/community/download?id=4240183866976964608

cannot find AES mention there (?)

C920v2

if it implements 1.0 it should have the vector crypto no?

ask them for details via the provided email :D

interesting, gcc 14 adopted support for THeadVector, so basically vector0.7

damn arxiv.org/html/2508.13840v1/graphs/streams.png

interesting comparisons against Zen2

yeahI get the feeling it'd be a great database machine too

if it has aes, the x9 would still be a pretty nice platform if they don't become DoA like previous

apparently the vector unit can access any memory, independent of MMU permissions

that is afaik about the C920v1(?)

ahahahah

spectre is inevitable, just offer instructions to do this directly

lol

email-to-irc service when :)

I don't see any Zkr / Zkt references here gcc.gnu.org/pipermail/gcc-patches/2025-March/677772.html

so probably no crypto extensions

Zk are scalar crypto extensions

Zvk* are vector crypto extensions

They are different

either way, not referenced here

In addition to the standard RV64GCB[V] ISA, C907 has also implemented the XIE (XuanTie Instruction Extension). The XIE consists of extended instructions optimized for load/store, arithmetic, bitwise and cache/TLB operations. When enabled, these instructions improve the performance significantly.

Interesting

SG2044 has XIE too

Looking for the list of instructions now

I think current gcc with -march=native should already turn those on

though perhaps some of these only make sense in asm

crypto specs github.com/riscv/riscv-crypto/releases

So yeah, Zvk doesn't get mentioned anywhere. and I guess it's separate from RVV1.0?

Probably this: github.com/XUANTIE-RV/thead-extension-spec/releases/tag/2.3.0

I don't see any crypto instructions mentioned

Those extensions add instructions similar to the regular RISC-V zba/zbb/zbc instructions, we already have support for those

Zvk is still pretty new dl.acm.org/doi/abs/10.1145/3658644.3691394

without AES in-line, that'd be pretty devastating

I wonder if they have an accelerator for scratchpad AES

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

what the hell are folks running on. Linux kernel already supports it all. lwn.net/Articles/952854

I don't know what they're running on, but I debugged my vector aes code in qemu

They did the same, probably, since it was in 2023

I guess

zvkt here rt-rk.com/gcc-tuning-for-spacemit-x…r-dual-issue-scheduler-model-part-i

zvkt = make certain instructions constant time

it's not a specific instruction set

ok. so spacemit x60 claims RVA22 support and RVV1.0 but crypto is still optional in RVA22 and it sounds like they don't support it

X5 used SG2042R which must be a custom chip, so maybe X9 uses a custom SG2044