41–50 of 50 posts
Raspberry pi5 8Gb, with data volume set to 4Gb 1 12.9 2 12.4 3 12.1 4 11.6 E5-1620 v2 @ 3.70GHz, 32Gb 1 16.9 2 29.5 3 39.8 4 37.8 5 35.3 6 35.3 7 34.9 8 34.7
1 3.9
2 3.9
3 3.7
4 3.6
1 4.7
2 4.1
3 3.8
4 3.7>You can double this amount of bandwidth with NUMA-aware code, but it will require further engineering. So is this benchmark really useful? Seems like it's engineered enough that it probably isn't relevant for most use cases (like running java, go or python services), and not engineered enough so it's not relevant for performant systems like databases. (That said NUMA simply isn't that hard, even with Java which is a…
16-core ARM CAX41
root@ubuntu-32gb-fsn1-1:~# ./a.out
1 17.8
2 35.6
3 49.9
4 64.9
5 79.0
6 92.1
7 101.7
8 110.2
9 117.6
10 124.0
11 130.4
12 136.2
13 140.9
14 143.8
15 149.2
16 152.9
16 Core AMD shared CPX51
root@ubuntu-32gb-fsn1-1:~# ./a.out
1 18.9
2 37.5
3 54.3
4 65.4
5 77.2
6 92.8
7 100.8
8 92.1
9 95.1
10 105.7
11 93.4
12 100.9
13 89.9
14 97.0
15 99.1
16 107.8
16 core AMD dedicated CCX43
root@ubuntu-64gb-fsn1-1:~# ./a.out
1 36.3
2 71.6
3 56.8
4 50.8
5 63.4
6 57.2
7 53.4
8 50.9
9 55.2
10 61.3
11 64.4
12 65.3
13 66.5
14 68.8
15 69.2
16 64.4
Increasing the data volume for CCX43 to 48GB increases the bandwidth using 16 cores to 75.1. Memory bandwidth seems to scale pretty well with the number of cores on ARM. Interesting that the bandwidth for the shared AMD system is that much higher than the dedicated system
> You can double this amount of bandwidth with NUMA-aware code, but it will require further engineering. If you have non uniform memory, you may be shooting yourself in the foot. Author used a dual socket system. If you are not careful, and your code is not NUMA aware, you may end up with less memory bandwidth for your application, than a single-socket would have. Can be avoided by prefixing `numactl --cpubind=0` to…
Note that you can get a significant speedup by using "restrict" on the pointer in the "sum()" function to tell the compiler that there is no mutation or aliasing happening during the call's lifetime. On Godbolt, with a size of 100MB (due to limits), this improves the speed using LLVM 17 ( https://godbolt.org/z/6dW1h8aev ) from: 1 15.1 2 15.9 To ( https://godbolt.org/z/sh3489Mxv ) 1 12.8 2 13.7
I changed data_volume to 8GB and ran on my desktop (Amd Ryzen5 7600X + 2x8GB DDR5-4800 running @ 5000 Mhz)(Win11) I get around 55 GB/s PS E:\> .\bandwidth.exe 1 54.0 2 56.7 3 56.1 4 55.3 5 54.6 6 54.3 7 53.9 8 53.1 9 53.4 10 53.1 11 52.3 12 52.8 55 is kinda low for DDR5 I guess.. On S23 Ultra (Snapdragon 8 Gen 2+, 12GB LPDDR5X @4200MHz) u0_a339@localhost ~> ./bandwidth 1 34.4 GB/s 2 38.7 GB/s 3 42.0 GB/s 4 42.3 GB/s…
Earlier quoted context omitted.
So around 3x of what AWS has? I guess this is more about what motherboard they have, and not an on-prem vs cloud difference.
Number of DIMM is important, I know the standard BOM at my company has way more memory that we use just to have more bandwidth.
Earlier quoted context omitted.
This is why M series chips "feels" faster
No it's not.
Another factor is mac's have many more memory channels on the m1/2/3 pro and m1/2/3 max. So they can have many more memory transactions, where on most PCs and x86-64 laptops you get 2 cache misses per memory latency (on the order of 70ns), where macs will get many more. So under various workloads all the cores spend much less time waiting on memory latency.
7950x3d w/ 128GB at stock timings (~3200MT/s?). Showed a high base but no increase with threads, need to investigate what is happening. 1 54.7 2 50.6 3 49.6 4 48.2 5 47.9 6 47.4 7 47.1 8 46.6 9 46.5 10 46.2 11 46.1 12 45.9 13 45.8 14 45.7 15 45.7 16 45.7 17 45.7 18 45.8 19 45.9 20 45.8 21 45.8 22 45.6 23 45.6 24 45.5 25 45.5 26 45.5 27 45.5 28 45.4 29 45.4 30 45.4 31 45.4 32 45.4
$ ./a.out
1 59.2
2 76.9
3 66.8
4 68.7
5 64.0
6 67.1
7 63.9
8 66.0
9 64.0
10 65.6
11 64.0
12 65.5
13 65.6
14 66.0
15 66.0
16 65.8
17 65.1
18 65.2
19 65.1
20 65.4
21 64.6
22 65.2
23 65.5
24 65.2