> I struggle to imagine a regular workload that benefits from 32gbps of bandwidth, much less a scenario where the average layman could saturate a 200gbps or 400gbps bus.
Since this is HN, many of us like… compiling, you know, stuff. It is a regular workload for many of us on here.
The main beneficiary of the M1 Max wide memory architecture appears to be the Haskell GHC compiler, which is very, very voracious when it comes to the memory consumption and the data bus width. Regular Haskell builds shift the data around at 35-40 Gbps on average, with the Haskell optimiser hovering around 50 Gpbs and easily peaking out at 65 Gbps on medium size projects. Since cabal (the Haskell build toolchain) for some reason can't fully utilise the «-j10» parameter, roughly a 1/2 of CPU cores are not utilised. Which means we can kick off another large Haskell build in parallel without affecting memory transfer speeds of the first build.
Rust release builds are a runner-up with 30-35 Gbps transfer speeds on average. Static type analysis and type inference in Haskell and Rust is hard, is complex and requires a lot of fast memory and benefits vastly from large CPU caches.
I have not attemped a Rust LTO build yet, but I would expect the LTO builds to like the wide memory bus, like, A LOT. In general, a LTO build (e.g. large C++ builds) is heavily memory bound and shifts data blocks, small and large, around extensively.
But an application is not very useful with a dataset, so many of us then like training our data models. Data model training can easily saturate 200 Gbps per a M1 Max CPU cluster.
Then the application needs to load the data in and usually do something with it. For example, issue complex queries to a graph database. Large CPU caches coupled with a wide data bus is a winner here.
All of the above are examples of real, practical and regular workloads.