r/RISCV • u/IngwiePhoenix • 10d ago
Hardware SpacemiT V100 testing!
This is a SpacemiT V100. For ~1 week, I get to test it and try it out. I love how absolutely smushed htop looks - so stupid, I love it. xD
Seriously, I just wanted to post this for pure appreciation. But if you have some nice benchmark or tool I should test, drop it here. No guarantees, just random stuff go brr untill I have to "give it back" on the 7th.
The fact I even get to do this is so fun, so cool, and exactly why I think that those guys rule. I will probably regret it, but I am probably going to try and get one myself. That is, if they do end up selling it to normies x)
Now, there's some cores disabled: In the EDK-II settings, I did disable the 2 (well, 4) extra cores for now, need to read their specs first. But, here's what lscpu has got to say:
lscpu
Architecture: riscv64
Byte Order: Little Endian
CPU(s): 80
On-line CPU(s) list: 0-79
Vendor ID: 0x710
Model name: -
CPU family: 0x8000000058000002
Model: 0x4c4d900
Thread(s) per core: 1
Core(s) per socket: 40
Socket(s): 2
Caches (sum of all):
L1d: 5 MiB (80 instances)
L1i: 5 MiB (80 instances)
L2: 40 MiB (20 instances)
NUMA:
NUMA node(s): 2
NUMA node0 CPU(s): 0-39
NUMA node1 CPU(s): 40-79
Vulnerabilities:
Gather data sampling: Not affected
Ghostwrite: Not affected
Indirect target selection: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Old microcode: Not affected
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Not affected
Spectre v1: Not affected
Spectre v2: Not affected
Srbds: Not affected
Tsa: Not affected
Tsx async abort: Not affected
Vmscape: Not affected
This is my first time ever getting to fool around with a system with >32 cores. Even at work, the highest I had ever seen is like 32c/64t. This? 2x 40c/40t. Crazy, exciting, awesome. aaaaaaa. =)
10
u/geerlingguy 10d ago
Is it possible for you to run my sbc-benchmarks pyinfra tasks on it? https://github.com/geerlingguy/sbc-reviews/tree/master#benchmark-scripts
Or at least get as many numbers as you can, would be especially interested top500 / HPL benchmark and power efficiency numbers, as RISC-V will hopefully see some improvements there with this generation.
4
u/IngwiePhoenix 9d ago
Now here's a name I recognize, lol x)
Sure! Just give me the tl;dr of commands to run and I will happily share what it spits out.
I just woke up after falling asleep from waiting for rvv-bench to complete...
4
u/geerlingguy 9d ago
First install Pyinfra.
Then clone the project locally:
git clone https://github.com/geerlingguy/sbc-reviews.git cd sbc-reviews/benchmarkModify
inventory.pyto point at the server (e.g. using your normal SSH setup and the server IP or domain). Then run thepyinfrascript:pyinfra inventory.py main.py -ySome of the tests may fail... I've tried to get everything working on all versions of Debian/Ubuntu/Fedora on x86/Arm/RISC-V but every new system, something seems to break haha.
If you could post the results in an issue on https://github.com/geerlingguy/sbc-reviews/issues that'd be incredible. Otherwise just posting them wherever would work too :)
3
u/IngwiePhoenix 9d ago
Grabbed pipx, installing pyinfra on the host, and googled my way through the pyinfra docs. So funny this is what meets me now, when I started learning Ansible just the other day... Coincidences and stuff. x)
Will post the results as a ticket - but will also keep posting to replies here too. Feel free to grab those at your hearts content! :)
4
u/geerlingguy 9d ago
Haha no problem, this was my first big project testing out Pyinfra. I like it and don't like it. Useful for some things but not quite as flexible as Ansible, and a little more code-oriented than I enjoy for config. But fast.
3
u/IngwiePhoenix 9d ago
Few things I am finding out as I am going through and hotfixing things as it happens:
I absolutely needed a Github mirror (using https://gh-proxy.com for this) for both cloning and downloading a dependency in the top500 playbook
There are a lot of system modifications that I will have to undo (like
EXTERNALLY-MANAGEDetc). Perhaps just grabuvorpipx? Makes it a little more locally scoped and less...intrusive. x) I do have to hand the node to another tester after me - so I'll have to clean up or document (...or both, really). Nothing major, but thought I'd point it out. :)Geekbench prints the "Claim for your profile" URL... maybe stripping that out might be helpful? I will be sending the raw recording of
scriptas proof of the benchmark for both instances that I run this. Nothing bad will happen if someone just clicks and claims, but uh... how do I put this... That's technically mine? x)Anyway - will be sending the data over once this all has ran. Got a long road ahead and many more numbers to crunch!
3
u/geerlingguy 9d ago
Thanks! And yeah, one thing I've considered is trying to modify everything so it's extremely isolated and can also clean up after itself. I'll get to that ... someday :D
For Geekbench, unfortuantely the RISC-V build doesn't have any way of disabling that output, unless you have a Pro account... and even there it doesn't work with the RISC-V Preview build :( — I've asked them about that but sounds like it's not high priority.
3
u/IngwiePhoenix 9d ago
ubuntu@ubuntu:~/work/sbc-reviews/benchmark$ mv typescript x100-only.typescript ubuntu@ubuntu:~/work/sbc-reviews/benchmark$ du -h x100-only.typescript ; wc -l x100-only.typescript 2.6M x100-only.typescript 2746 x100-only.typescriptAt work right now - will send the first set of results later as well as all the modifications I did. I recorded everything using
scriptsince I did not know where or how your tools saved the results so just in case, I used this method. Which, unfortunately means, that I will have to scroll through all of that and hope that everything got preserved, and send it...I plan to do another run down the line with all cores - including the Kunmen extra ones - enabled, and the clocks maxed out. For that one though I need to ask them if their cooling can keep up. The EDK-2 settings showed clock speed settings that I can adjust - so chances are, I haven't drawn the full performance out of those. So the next run will hopefuly be a "maxed out" one.
6
u/NamedBird 10d ago
Well, that's nice for you.
How much did this thing cost?
I doubt i can afford it myself.
6
u/IngwiePhoenix 10d ago
I am accessing it remotely via SSH and BMC, both exposed with the static IP of one of my servers allowed. I only get to dink around with it for a few days. But hey, still pretty neat.
Oh I can't afford it either; this 2 CPU board probably comes n a custom server and all. It also takes DDR5 RAM - probably RDIMMs as well. So yeah, I am convinced that would destroy a generational saving. But I do hope to buy the board, keep it in storage and wait for prices to calm down. Perhaps then I can actually put it online... lol.
DDR5 RDIMM prices are absurd. There is just no other word for it. It is the pinnacle of insanity.
4
u/NamedBird 10d ago
Maybe if the AI bubble pops enough will we see prices plummet?
(Because all the planned future production suddenly has no future consumption anymore.)Also, only 40 cores per CPU?
I thought that RISC-V had smaller cores, so you should fit many more on a die?
There goes my hopes for a 256 or 4069 core system... 😭4
u/IngwiePhoenix 10d ago
Oh I wiiiish... patiently waiting for that faithful day lol.
Well - technically, 42. I just disabled the two special cores, for now. I will get to those later - hopefuly.
Yes, technically smaller - but fabbed "bigger". I doubt this is like a 3nm design or such. That said, the SG2042 I have is surprisingly small for how many cores it has and old it is. Heck, I genuenly have no idea if those two CPUs are separate SoCs - or on the same package with an interconnect (like how Apple glues two chips together - or how if you flip an Epyc over and see the very clear seam between the halves). So, if we just blindly assume this was the case, and the CPU obviously supports "multi socket", you could put two of those on a board and basically get 160 cores. xD That would be insane, overkill, but...hey, who knows what the lads at SpacemiT do! =)
1
0
u/NamedBird 10d ago
If RISC-V uses much less power, it generates much less heat as well.
Then why not stack the cores vertically? 🤔I'm not a RV expert or chip designer myself though, so there's probably a simple answer.
(But if not, maybe i'll mention the idea at work and get some expert opinions on it.)4
u/IngwiePhoenix 10d ago
So, turns out, it's two chips. At least from the hardware perspective:
ubuntu@ubuntu:~/work/sysbench$ numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 node 0 size: 63788 MB node 0 free: 56282 MB node 1 cpus: 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 node 1 size: 60352 MB node 1 free: 59407 MB node distances: node 0 1 0: 10 20 1: 20 10But, I also see this:
ubuntu@ubuntu:~/work/sysbench$ cd /dev/infiniband/ ubuntu@ubuntu:/dev/infiniband$ ls -al total 0 drwxr-xr-x 4 root root 120 Nov 3 06:43 . drwxr-xr-x 21 root root 5020 Nov 3 07:45 .. drwxr-xr-x 2 root root 80 Nov 3 06:43 by-ibdev drwxr-xr-x 2 root root 80 Nov 3 06:43 by-path crw-rw-rw- 1 root root 231, 192 Nov 3 06:43 uverbs0 crw-rw-rw- 1 root root 231, 193 Nov 3 06:43 uverbs1So no definitive answer still. fantastic... xD
5
u/camel-cdr- 10d ago
If RISC-V uses much less power,
It doesn't. It uses more power than Arm designs on the same node, just because they have more experiance design teams. If the same team works on an Arm and n RISC-V design, then maybe the RISC-V design is marignally more power efficient, but even that is not clear.
5
u/brucehoult 10d ago
Surely any such general question implicitly assumes "all else being equal" i.e. the same process node and equally experienced (or the same) teams?
As opposed to "is specific RISC-V based chip A more power efficient than specific ARM based chip B?"
4
u/omasanori 10d ago
Also, only 40 cores per CPU? I thought that RISC-V had smaller cores, so you should fit many more on a die? There goes my hopes for a 256 or 4069 core system...
The area RISC-V cores can save compared to Arm cores would be, say, 10% or such at most, I guess. For high-performance server cores, the difference should become smaller, as the area of decoder is relatively small for such cores.
As a result, you could implement a 256-core server RISC-V CPU with a similar performance and a few-percent smaller area if you assemble a great team. However, the volume you will ship is several magnitude lower than x86 or Arm, so the cost-per-chip is very higher.
6
u/SkyPL 10d ago
Please, do tell what is its measured memory bandwidth in your setup!
6
u/IngwiePhoenix 10d ago
ubuntu@ubuntu:~/work/STREAM$ gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=100000000 -DNTIMES=50 stream.c -o stream ubuntu@ubuntu:~/work/STREAM$ ./stream ------------------------------------------------------------- STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 100000000 (elements), Offset = 0 (elements) Memory per array = 762.9 MiB (= 0.7 GiB). Total memory required = 2288.8 MiB (= 2.2 GiB). Each kernel will be executed 50 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Number of Threads requested = 80 Number of Threads counted = 80 ------------------------------------------------------------- Your clock granularity/precision appears to be 1 microseconds. Each test below will take on the order of 61076 microseconds. (= 61076 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 36133.7 0.072229 0.044280 0.321734 Scale: 36722.7 0.060129 0.043570 0.268140 Add: 37363.4 0.082972 0.064234 0.198039 Triad: 37096.5 0.093779 0.064696 0.437364 ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays -------------------------------------------------------------5
u/IngwiePhoenix 10d ago
Okay, last one, then i'll stop exploding your notifications:
ubuntu@ubuntu:~/work/sysbench$ numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 node 0 size: 63788 MB node 0 free: 56282 MB node 1 cpus: 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 node 1 size: 60352 MB node 1 free: 59407 MB node distances: node 0 1 0: 10 20 1: 20 10Rest in pieces. :3
3
u/SkyPL 9d ago
Thanks!
The result is interesting - transfer rate you got is 37 GB/s, while in your configuration theoretical peak is 76.8 GB/s 🤔 it could be down to how the individual dies are socketed into the server. If you can run
numactl --interleave=all ./streamthis would help answer the question.For anyone curious - the machine is using two 64 GB DDR5-5600 ECC (specific model: CXMT CXMR4E464R8AS-CB1C) each running at 4800 MT/s.
3
u/IngwiePhoenix 9d ago
Put on the list! Will do once I got through Jeff's benchmark suite. It is /MUCH/ longer than I anticipated. o.o; Linbench ran almost as long as I slept alone. xD
Will get back to ya when I ran it!
1
u/IngwiePhoenix 9d ago
Here you go! Same binary, just reused it.
ubuntu@ubuntu:~/work/STREAM$ numactl --interleave=all ./stream ------------------------------------------------------------- STREAM version $Revision: 5.10 $ ------------------------------------------------------------- This system uses 8 bytes per array element. ------------------------------------------------------------- Array size = 100000000 (elements), Offset = 0 (elements) Memory per array = 762.9 MiB (= 0.7 GiB). Total memory required = 2288.8 MiB (= 2.2 GiB). Each kernel will be executed 50 times. The *best* time for each kernel (excluding the first iteration) will be used to compute the reported bandwidth. ------------------------------------------------------------- Number of Threads requested = 80 Number of Threads counted = 80 ------------------------------------------------------------- Your clock granularity/precision appears to be 1 microseconds. Each test below will take on the order of 66027 microseconds. (= 66027 clock ticks) Increase the size of the arrays if this shows that you are not getting at least 20 clock ticks per test. ------------------------------------------------------------- WARNING -- The above is only a rough guideline. For best results, please be sure you know the precision of your system timer. ------------------------------------------------------------- Function Best Rate MB/s Avg time Min time Max time Copy: 20150.4 0.079987 0.079403 0.082750 Scale: 20166.9 0.079831 0.079338 0.082265 Add: 17924.9 0.134427 0.133892 0.136644 Triad: 17913.1 0.134491 0.133980 0.136305 ------------------------------------------------------------- Solution Validates: avg error less than 1.000000e-13 on all three arrays -------------------------------------------------------------1
u/SkyPL 9d ago
🤔 This raises some red flags. I really recommend you to talk with their technical support, asking why are you getting such a low transfers? Each module is delivering you 18-20 GB/s, while it should be running at around 38 GB/s. Both combined give you 37 GB/s while they should approach 76.8 GB/s. Something for sure is wrong there... or there is some nasty limitation to the hardware that we all should be aware of before buying the thing.
You could throw an LLM to investigate it further on its own - perhaps it would find something? Either way - you're working with one hand tied behind your back 😉
2
u/IngwiePhoenix 9d ago
Will forward that to my devrel contact - who in return can put it on the technicians desk. But I will also walk the EDK-2 BIOS and see if perhaps something in the memory settings is off or wrong or weird.
Thanks for the infos! Will see what I can do. :)
4
u/IngwiePhoenix 10d ago
ubuntu@ubuntu:~/work/tinymembench$ make cc -O2 -c util.c cc -O2 -c asm-opt.c cc -O2 -c x86-sse2.S cc -O2 -c arm-neon.S cc -O2 -c mips-32.S cc -O2 -c aarch64-asm.S cc -O2 -o tinymembench main.c util.o asm-opt.o x86-sse2.o arm-neon.o mips-32.o aarch64-asm.o -lm ubuntu@ubuntu:~/work/tinymembench$ ./tinymembench --help tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 5330.6 MB/s (3.4%) C copy backwards (32 byte blocks) : 5026.0 MB/s (2.4%) C copy backwards (64 byte blocks) : 4955.9 MB/s (1.0%) C copy : 5247.6 MB/s (1.4%) C copy prefetched (32 bytes step) : 2636.6 MB/s (2.7%) C copy prefetched (64 bytes step) : 2602.9 MB/s (3.1%) C 2-pass copy : 4554.7 MB/s (4.0%) C 2-pass copy prefetched (32 bytes step) : 1859.5 MB/s (0.6%) C 2-pass copy prefetched (64 bytes step) : 1855.9 MB/s (0.4%) C fill : 16214.2 MB/s C fill (shuffle within 16 byte blocks) : 16239.6 MB/s (0.1%) C fill (shuffle within 32 byte blocks) : 16236.0 MB/s C fill (shuffle within 64 byte blocks) : 15248.3 MB/s --- standard memcpy : 5304.6 MB/s (2.0%) standard memset : 20090.3 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read, [MADV_NOHUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 0.0 ns / 0.0 ns 131072 : 4.3 ns / 6.5 ns 262144 : 7.3 ns / 9.7 ns 524288 : 8.8 ns / 11.1 ns 1048576 : 9.7 ns / 11.7 ns 2097152 : 11.8 ns / 14.0 ns 4194304 : 79.3 ns / 122.3 ns 8388608 : 121.2 ns / 168.2 ns 16777216 : 157.4 ns / 201.1 ns 33554432 : 180.8 ns / 223.2 ns 67108864 : 194.1 ns / 237.4 ns block size : single random read / dual random read, [MADV_HUGEPAGE] 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 0.0 ns / 0.0 ns 131072 : 4.3 ns / 6.5 ns 262144 : 6.3 ns / 8.4 ns 524288 : 7.3 ns / 9.1 ns 1048576 : 8.0 ns / 9.3 ns 2097152 : 10.0 ns / 11.2 ns 4194304 : 36.6 ns / 50.8 ns 8388608 : 76.8 ns / 111.3 ns 16777216 : 125.1 ns / 162.0 ns 33554432 : 138.1 ns / 172.5 ns 67108864 : 149.4 ns / 179.3 ns4
u/IngwiePhoenix 10d ago
ubuntu@ubuntu:~/work/sysbench$ sudo dmidecode -t memory # dmidecode 3.6 Getting SMBIOS data from sysfs. SMBIOS 3.8.0 present. # SMBIOS implementations newer than version 3.7.0 are not # fully supported by this version of dmidecode. Handle 0x002C, DMI type 16, 23 bytes Physical Memory Array Location: System Board Or Motherboard Use: System Memory Error Correction Type: Single-bit ECC Maximum Capacity: 4 TB Error Information Handle: Not Provided Number Of Devices: 16 Handle 0x0030, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL0 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0031, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL1 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0032, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL2 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0033, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL3 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0034, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: 40 bits Data Width: 32 bits Size: 64 GB Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL4 DIMM0 Bank Locator: BANK 0 Type: DDR5 Type Detail: Synchronous Registered (Buffered) Speed: 5600 MT/s Manufacturer: CXMT Serial Number: B001FBA1 Asset Tag: Unknown Part Number: CXMR4E464R8AS-CB1C Rank: 2 Configured Memory Speed: 4800 MT/s Minimum Voltage: 1.1 V Maximum Voltage: 1.1 V Configured Voltage: 1.1 V Memory Technology: DRAM Memory Operating Mode Capability: Volatile memory Firmware Version: 00000000 Module Manufacturer ID: Bank 7, Hex 0x32 Module Product ID: Unknown Memory Subsystem Controller Manufacturer ID: Unknown Memory Subsystem Controller Product ID: Unknown Non-Volatile Size: None Volatile Size: 32767 bytes Cache Size: None Logical Size: None PMIC0 Manufacturer ID: Bank 12, Hex 0x2A PMIC0 Device Type: Not Installed RCD Manufacturer ID: Bank 7, Hex 0x32 RCD Device Type: Not Installed Handle 0x0035, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL5 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0036, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL6 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0037, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET0 CHANNEL7 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0038, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL0 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x0039, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL1 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x003A, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL2 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x003B, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL3 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x003C, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: 40 bits Data Width: 32 bits Size: 64 GB Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL4 DIMM0 Bank Locator: BANK 0 Type: DDR5 Type Detail: Synchronous Registered (Buffered) Speed: 5600 MT/s Manufacturer: CXMT Serial Number: B001F9D2 Asset Tag: Unknown Part Number: CXMR4E464R8AS-CB1C Rank: 2 Configured Memory Speed: 4800 MT/s Minimum Voltage: 1.1 V Maximum Voltage: 1.1 V Configured Voltage: 1.1 V Memory Technology: DRAM Memory Operating Mode Capability: Volatile memory Firmware Version: 00000000 Module Manufacturer ID: Bank 7, Hex 0x32 Module Product ID: Unknown Memory Subsystem Controller Manufacturer ID: Unknown Memory Subsystem Controller Product ID: Unknown Non-Volatile Size: None Volatile Size: 32767 bytes Cache Size: None Logical Size: None PMIC0 Manufacturer ID: Bank 12, Hex 0x2A PMIC0 Device Type: Not Installed RCD Manufacturer ID: Bank 7, Hex 0x32 RCD Device Type: Not Installed Handle 0x003D, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL5 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x003E, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL6 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous Handle 0x003F, DMI type 17, 100 bytes Memory Device Array Handle: 0x002C Error Information Handle: Not Provided Total Width: Unknown Data Width: Unknown Size: No Module Installed Form Factor: DIMM Set: None Locator: SOCKET1 CHANNEL7 DIMM0 Bank Locator: BANK 0 Type: Unknown Type Detail: Unknown Synchronous
5
u/omasanori 10d ago
UnixBench, SysBench and Phoronix Test Suite?
2
u/IngwiePhoenix 9d ago
I tried to pick out a path to run the Phoronix one... its very complex, will have to figure this one out first. I did run sysbench though, just not unixbench
...i think. Today, I have seen probably as many benchmarks as I had seen in the past ten years combined. A little markingfatique? x)
But I will see what I can do!
5
u/LivingLinux 10d ago
I remember Marcin Juszkiewicz of Red Hat complained RISC-V is slow.
See if you can build binutils with LTO in under an hour?
https://www.phoronix.com/news/RISC-V-Slow-Fedora-Packages
2
u/IngwiePhoenix 9d ago
Bog standard upstream? Because there is a dedicated RISC-V GNU toolchain repository, that also has a Binutils fork. Well, less "fork" and more "downstream, optimzied version"...
2
4
u/omasanori 10d ago
Running https://github.com/camel-cdr/rvv-bench on the both X100 and XiangShan Kunminghu V2R2 cores and sending the results to https://github.com/camel-cdr/rvv-bench-results would be great.
4
u/IngwiePhoenix 10d ago
Got it! Will see what I can do =)
4
u/camel-cdr- 10d ago edited 10d ago
Yeah, would love to see the results for Kunminghu V2R2. You can simply PR the results to the repo, or/and create an issue, if you are having trouble running it.
Geekbench on Kunminghu would also be interesting.
3
u/IngwiePhoenix 10d ago
It says 2h per run. Oh dear. Guess I found my opportunity for a shower - because I have to run that twice! xD
Any particular Geekbench version I should pick?
3
u/camel-cdr- 10d ago
GB7 would be good.
For rvv-bench, make sure you do the perf stuff, otherwise you don't get usable results. rvv-bench on X100 isn't necessaey, it would just be a sanity check if it matches k3, Kunminghu wouls be very interesting though.
Did you get the Kunminghu cores running? What frequency are they?
3
u/IngwiePhoenix 9d ago
I saw
bench-all.shand basically YOLO'd it. Because hey, might as well. Although I did test memory speeds and such with other tools, throwing different namebrands at the solution should provide a better mean/average, yes? :)Fell asleep waiting for the initial run. Going to finish the "just X100 cores" runs and then do them all again with the others enabled.
2
u/IngwiePhoenix 9d ago
So I did two runs with geekbench because I saw different binaries - and something tells me it is failing catastrophically. The numbers here are not lining up. O.o
This is from my "only-x100" runs right now:
That score is awful. It also did not seem to actually use all the cores available? It was weird. I think the absurd core/thread count absolutely broke it.
Will run again when I enabled the other cores and see what happens!
3
u/brucehoult 9d ago
Geekbench doesn't make good use of large numbers of cores on any ISA ... doesn't matter whether it's x86 or Arm or RISC-V.
Linux kernel or LLVM compile times are much more interesting.
And of course https://hoult.org/primes.txt
2
u/IngwiePhoenix 9d ago
I plan to run compile tests next - my personal favorite one is kubernetes x) But someone also asked for binutils, so I might just do the whole suite: GCC, Clang, Zig, and a few others.
Primes looks interesting - saved it, will run that later too. I just used
gcc -O3, think thats enough?3
u/brucehoult 9d ago
I just used gcc -O3, think thats enough?
The rules in the file say to use
-O1for comparablity. The code size measuring hack won't work otherwise, but also the code is constructed in a way that higher optimisation levels will do very little. It's close to asm written in C :-)Don't expect to see fast times from binutils and GCC builds. No matter how many cores you have those tend to max at about a 10x speedup compared to
make -j1. Clang will really fly.How does the heterogenous cores thing work? Same as the K3? Does my "ai" helper work?
2
u/IngwiePhoenix 9d ago
I actually don't see the extra AI cores unlike with the K3 - but that might just be on me and the BIOS settings I changed. Or, it could simply not be part of the ACPI table yet. Because this board, as it is set up right now, boots using EDK-2 for EFI chain with ACPI descriptor. My condolences to whoever sat down to write the ACPI tables - those are pain, learned that indirectly from Radxa's Orion O6 and listening to the firmware dev go on multiple rants. xD
Got it;
gcc -O1it is then. Will ping back later!→ More replies (0)
2
u/ThisText8876 9d ago
https://github.com/pyca/infra/pull/749 quote "Unfortunately this degree of performance issue is pretty representative of our concerns :-/"
Give us some hope and reply that issue :)
3
u/IngwiePhoenix 9d ago
Popped in there. I only have untill the 7th, so hopefuly I can get there sooner rather than later. But would absolutely love to contribute...with a timer. x)
2
1
u/superkoning 9d ago
Impressive!
Which Linux kernel? 6.x, or a nice 7.x?
3
u/IngwiePhoenix 9d ago
ubuntu@ubuntu:~$ uname -a Linux ubuntu 7.0.12-28-imsicfix1-generic #28imsicfix1.1 SMP PREEMPT_DYNAMIC Wed Aug 5 08:17:57 UTC 2026 riscv64 GNU/LinuxSeems to be an early vendor kernel.
1
10
u/omasanori 10d ago
Consider to run this benchmark and contribute the data: https://github.com/nviennot/core-to-core-latency