7 ms·

Testing AMD's Bergamo: Zen 4c

158 points by latchkey 2y ago

tedunangst 2y ago
I remember as part of the TBB library release, Intel remarked that 100 pentium cores had the same transistor count of a core2. Took a while, but starting to turn the corner on slower and wider becoming more common.
- deleted 2y ago
  [deleted]
- imtringued 2y ago
  The problem with adding more cores is that SRAM is the real bottleneck. Adding more cores means more cache. Until someone figures out how to do 3D stackable SRAM similar to how SSDs work, SRAM will always consume most of the area on your chip.
  - wmf 2y ago
    It's called V-Cache.
    - Rohansi 2y ago
      V-cache is just L3 which is shared between cores. L1 and L2 are still within each core.
  - JonChesterfield 2y ago
    This isn't fill the reticle with CPU, it's make a dozen separate chips and package them on a network fabric. Amount of cache can increase linearly with number of cores without a problem. There is some outstanding uncertainty about cache coherency vs performance as N goes up which shows up in numa cliff fashion. My pet theory is that'll be what ultimately kills x64 - the concurrency semantics are skewed really hard towards convenience and thus away from scalability.
    - doctor_eval 2y ago
      I know next to nothing about CPU architecture so please forgive a stupid question. Are you saying that the x86 memory model means RAM latency is more impactful than on some other architectures? Is this (tangentially) related to the memory mode that Apple reportedly added to the M1 to emulate x86 memory model to make emulation faster? - presumably to account for assumptions that compilers make about the state of the CPU after certain operations?
      - CoastalCoder 2y ago
        I'm guessing GP's point is that x86 makes really strong memory consistency guarantees. It makes life easier for programmers of multithreaded software, but at the cost of high synchronization overhead. Contrast to e.g. Arm, where programmers can avoid a lot of that synchronization, but in exchange they have to be more careful. * IIRC from some recent reading.
      - inkyoto 2y ago
        The preceding comment was about the CPU cache coherency, which is the bane of the symmetric multiprocessor (SMP) system design. The problem arises due to the fact the main memory is shared across processors (or CPU cores). Consider this rough sketch: [memory (shared)] ⇕ [L3 cache (shared)] ⇕ [core 0] ⟺ [L1 cache (private)] ⟺ [L2 cache (shared)] ⟺ [L1 cache (private)] ⟺ [core N] ⇕ [core 1] ⟺ [L1 cache (private)] Each CPU (or CPU core) has its own private L1 cache that other CPU's/CPU cores do not have access to. Now, code running on the CPU 0 has modified 32 bytes at the address 0x1234 but the modification does not occur directly in the main memory, it takes places within a cache and changes to the data now have to be written back into the main memory. Depending on the complexity of the system design, the change has to be back propagates through a hierarchy of L2/L3/L4 (POWER CPU's have a L4 cache) caches until the main memory that is shared across all CPU's is updated. It is easy and simple if no other CPU is trying to access the address 0x1234 at the same time – the change is simply written back and the job is done. But when another CPU is trying to access the same 0x1234 address at the same time whilst the change has not made it back into the main memory, there is a problem as stale data reads are typically not allowed, and another CPU / CPU cores has to wait for the CPU 0 to complete the write back. Since multiple cache level are involved in modern system design, the problem is known as the cache coherency problem, and it is a very complex problem to solve in SMP designs. It is a grossly oversimplified description of the problem, but it should be able to illustrate what the parent was referring to.
  - fulafel 2y ago
    The real real problem is that we don't know how to effectively use growing transistor budgets to speed applications up compared to the single core era. Adding cache and more cores are both options that make for very sublinear improvements at the margin. (for 95% of usage - somen niche things can utilize resources better, those not coincidentally often being the focus of benchmarks)
  - sva_ 2y ago
    Isn't that what AMD 3D V-Cache does? https://www.amd.com/en/products/processors/technologies/3d-v-cache.html https://www.amd.com/en/products/processors/technologies/3d-v...
- dialup_sounds 2y ago
  Reminds me of the ill-fated Larabee, which was supposed to be something like 50 Pentium-like cores in a GPU-shaped trenchcoat.
  - hajile 2y ago
    Larabee was launched as the first generation Knight-series chip (it even had the GPU-specific stuff still in there disabled IIRC). I believe the Knight-series chips were killed because they ran into a bunch of issues and politics with Knight's Mill then killed it in favor of their upcoming GPU architecture only for that to have issues and be delayed too. I suspect that a RISC-V version of Larabee would work better as the ratio of SIMD to the rest of the core would be a lot better.
    - kijiki 2y ago
      A dual-issue in-order RISC-V isn't enough smaller than a P54c to make a significant difference. The overwhelming majority of Larabee's area went to SIMD units and caches.
      - hajile 2y ago
        Do you have any evidence for this statement? Their actual core wasn’t a Pentium. It added in most/all the x86 bloat from the last 3 decades too. Cutting all that stuff and saving power means you can squeeze in a couple more cores and improve performance that more. 32 registers a significant advantage too. RVV also allows wider vectors than AVX. Without reordering, you can get stronger performance guarantees from a single, wide SIMD than from two narrow SIMD (it’s also possible to look at the next couple instructions and switch between executing one at full width or two at half width each without massive investment). And we haven’t even reached peak advantage yet. RISCV has the option for 48/64 bit instructions with loads of room to add VLIW instructions. While most VLIW implementations require everything to be VLIW, this would be optional in RISCV. Your core could be dual issuing two wide VLIW allowing a single thread to theoretically use four vector units. If you add in 4-8 wide SMT, the result is something very GPU-like while still using standard RISCV. Maybe x86 can do this too, but I don’t think it would be anywhere near as efficient and it would certainly eat up a lot of the precious remaining opcode space.
nullc 2y ago
Is the 4c core slower in any other way than L3 cache reductions? Would be interesting to see a compute bound perfectly scaling workload and compare it in terms of absolute performance and performance per watt between Bergamo and Genoa.
- mlyle 2y ago
  Same performance per cycle; less L3 and lower maximum frequency. Zen4C is said to be a little better performance per watt than Zen4, but it's not clear how much.
- toast0 2y ago
  > Is the 4c core slower in any other way than L3 cache reductions? It's got a lower clock ceiling. Not much lower than acheivable clocks in really dense zen4 Epyc, but a lot less than an 8 core Ryzen.
- wmf 2y ago
  https://www.phoronix.com/review/amd-epyc-9754-bergamo/2 https://www.phoronix.com/review/amd-epyc-9754-bergamo/2
deleted 2y ago
[deleted]
Pet_Ant 2y ago
The actual title seems to be "Testing AMD’s Bergamo: Zen 4c Spam" which I really like because for the perspectives of 20 years ago this would feel a bit like "spam" or a CPU-core "Zergling rush". As I said before, I do believe that this is the future of CPUs core. [1] With RAM latency not really having kept pace with CPUs have more performant cores really seems like a waste. In a Cloud setting where you always have some work to do it seems like simpler cores but more of them is really the answer. It's in the environment that the weight of x86's legacy will catch up with us and we'll need to get rid of all the waste transistors decoding cruft. https://news.ycombinator.com/item?id=40535915 https://news.ycombinator.com/item?id=40535915
- ComputerGuru 2y ago
  I agreed with you up until the x86 comment. Legacy x86 support is largely a red herring. The constraints are architectural (as you noted, per-core memory bandwidth, plus other things) more than they are due to being tied down to legacy instruction sets.
  - mlyle 2y ago
    If the goal ends up being many-many-core, x86's complexity tax may start to matter. The cost of x86 compatibility relative to all the complexities required for performance has been small, but if we end up deciding that memory latency is going to kill us and we can't keep complex cores fed, then that is a vote for simpler architectures. I suspect the future will be something between these extremes (tons of dumb cores or ever-more-complicated cores to try and squeeze out IPC), though.
    - hajile 2y ago
      The x86 tax ALREADY matters. Intel was only able to increase the number of decoders by adding entirely independent decoder complexes while reducing the number of decoders per branch. In practice, this means that decode increases for branchy code, but non-branchy code will be limited to just 3 decoders. In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. This also play into ideas like Larabee/Knights processors where you basically want the tiniest core possible attached to a massive SIMD engine. x86 decode eats up a lot of real estate. Even worse, x86 decode adds a bunch of extra stages which in turn increase the size of the branch predictor. That's not the biggest issue though. Dealing with all of this and all the x86 footguns threaded throughout the pipeline slows down development. It takes more designers and more QAs more time to make and test everything. ARM can develop a similar CPU design for a fraction of the cost compared to AMD/Intel and in less time too because there's simply fewer edge cases they have to work with. This ultimately means the ARM chips can be sold for significantly less money or higher margins.
adrian_b 2y ago
The article says "AMD’s server platform also leaves potential for expansion. Top end Genoa SKUs use 12 compute chiplets while Bergamo is limited to just eight. 12 Zen 4c compute dies would let AMD fit 192 cores in a single socket". It should be noted that the successor of Bergamo, Turin dense, which is expected by the end of the year, will have 12 compute chiplets, for a total of 192 Zen 5c cores, bringing thus both more cores and faster cores.
- metadat 2y ago
  192 cores per socket? If so, that's pretty wild.
chena12 2y ago
[flagged]
- chena12 2y ago
  [flagged]
- RedShift1 2y ago
  test failed successfully
  - chena12 2y ago
    [dead]
saxonww 2y ago
My immediate thought is that Sun beat both of these guys to market with the T1 20 years ago. Not exactly the same thing, but I wonder how close to the same idea they are; the line seems to have stopped with the M8, which is a 32c/256t part from 2017.
- kllrnohj 2y ago
  > the line seems to have stopped with the M8, which is a 32c/256t part from 2017. Epyc Naples was also 32c and also 2017. 4- and 8-way SMT wasn't something AMD or Intel ever bothered with, no, but IBM also did with the POWER line. It seems to help in some workloads, but probably isn't generally useful enough for volume solutions.
- kijiki 2y ago
  There is an absolutely huge difference between a 32c/256t part and a 128c/256t part. And Tera's MTA predated the T1 by quite a bit with a similar (and evidently doomed) architecture...
Havoc 2y ago
Every time I hear about a 100+ core my mind jumps to python GIL
- EasyMark 2y ago
  Has been heavily worked on in python 3.12 and up, don’t count out python just yet :)
  - Sesse__ 2y ago
    Spoiler alert: Software doesn't jump from “uses one core” to “efficiently uses 192 cores” once you remove the first lock.
    - deleted 2y ago
      [deleted]
    - merb 2y ago
      well back in the days when somebody invented gunicorn it was basically running one worker per core, if the software allowed it. thus you at least could scale on the process level, which of course was super slow if you only had like 10 req/s on a 60 cores machine.
    - EasyMark 2y ago
      Never said it did. I assume you know that at least a few people on here have a basic grasp on multiprocessors, locks, threads, asynch, etc
  - Havoc 2y ago
    Yeah not actually an issue for me. I run into skill limitations with python long before 100 core issues.
crote 2y ago
I wonder if these large cache sizes make it possible to operate functionally RAM-less servers? When optimized for size, it'd probably be possible to fit some microservices in an MB of 8 of RAM. You can fit a decent bit of per-connection client state in a few KB, which can take up the rest of the cache. Throw in the X3D cache for 96MB per CCD and you can actually do some pretty serious stuff. With the right preprocessing, it should be possible to essentially stream from NIC straight to CPU, process some stuff, and output it straight to the NIC again without ever touching RAM - although I doubt current DMA hardware allows this. It'd require quite a bit of re-engineering of the on-wire protocol to remove the need for any nontrivially-sized buffers, but I reckon it isn't impossible.
- yusyusyus 2y ago
  > With the right preprocessing, it should be possible to essentially stream from NIC straight to CPU, process some stuff, and output it straight to the NIC again without ever touching RAM this already exists [0] [0] https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/data-direct-i-o-technology-brief.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
  - crote 2y ago
    I wasn't aware of that, thanks for sharing!
- timschmidt 2y ago
  Lots of older or low end wireless routers have only 16 or 32mb RAM. A full linux stack fits in that. I do a full HTTPS stack on ESP32-C3 in ~500k. Lots of limitations, of course. Probably the biggest difficulty is that most modern systems simply refuse to boot without RAM installed, so you can't choose any platform without BIOS / EFI modifications. Definitely a worthwhile idea though.
  - crote 2y ago
    The difference is that those low end routers offload most or even all of the packet processing to dedicated networking hardware: it never even touches the CPU. The whole Linux stack is only used to host the management interface, configure the switching hardware, and deal with high-level stuff like DNS and DHCP. That's also why VPN performance is so horribly bad: there's no hardware acceleration for encryption, so it needs to be done on the CPU, which is not sized to deal with that kinds of traffic.

158 points by latchkey 2y ago

I remember as part of the TBB library release, Intel remarked that 100 pentium cores had the same transistor count of a core2. Took a while, but starting to turn the corner on slower and wider becoming more common.

deleted 2y ago
[deleted]
imtringued 2y ago
The problem with adding more cores is that SRAM is the real bottleneck. Adding more cores means more cache. Until someone figures out how to do 3D stackable SRAM similar to how SSDs work, SRAM will always consume most of the area on your chip.
- wmf 2y ago
  It's called V-Cache.
  - Rohansi 2y ago
    V-cache is just L3 which is shared between cores. L1 and L2 are still within each core.
- JonChesterfield 2y ago
  This isn't fill the reticle with CPU, it's make a dozen separate chips and package them on a network fabric. Amount of cache can increase linearly with number of cores without a problem. There is some outstanding uncertainty about cache coherency vs performance as N goes up which shows up in numa cliff fashion. My pet theory is that'll be what ultimately kills x64 - the concurrency semantics are skewed really hard towards convenience and thus away from scalability.
  - doctor_eval 2y ago
    I know next to nothing about CPU architecture so please forgive a stupid question. Are you saying that the x86 memory model means RAM latency is more impactful than on some other architectures? Is this (tangentially) related to the memory mode that Apple reportedly added to the M1 to emulate x86 memory model to make emulation faster? - presumably to account for assumptions that compilers make about the state of the CPU after certain operations?
    - CoastalCoder 2y ago
      I'm guessing GP's point is that x86 makes really strong memory consistency guarantees. It makes life easier for programmers of multithreaded software, but at the cost of high synchronization overhead. Contrast to e.g. Arm, where programmers can avoid a lot of that synchronization, but in exchange they have to be more careful. * IIRC from some recent reading.
    - inkyoto 2y ago
      The preceding comment was about the CPU cache coherency, which is the bane of the symmetric multiprocessor (SMP) system design. The problem arises due to the fact the main memory is shared across processors (or CPU cores). Consider this rough sketch: [memory (shared)] ⇕ [L3 cache (shared)] ⇕ [core 0] ⟺ [L1 cache (private)] ⟺ [L2 cache (shared)] ⟺ [L1 cache (private)] ⟺ [core N] ⇕ [core 1] ⟺ [L1 cache (private)] Each CPU (or CPU core) has its own private L1 cache that other CPU's/CPU cores do not have access to. Now, code running on the CPU 0 has modified 32 bytes at the address 0x1234 but the modification does not occur directly in the main memory, it takes places within a cache and changes to the data now have to be written back into the main memory. Depending on the complexity of the system design, the change has to be back propagates through a hierarchy of L2/L3/L4 (POWER CPU's have a L4 cache) caches until the main memory that is shared across all CPU's is updated. It is easy and simple if no other CPU is trying to access the address 0x1234 at the same time – the change is simply written back and the job is done. But when another CPU is trying to access the same 0x1234 address at the same time whilst the change has not made it back into the main memory, there is a problem as stale data reads are typically not allowed, and another CPU / CPU cores has to wait for the CPU 0 to complete the write back. Since multiple cache level are involved in modern system design, the problem is known as the cache coherency problem, and it is a very complex problem to solve in SMP designs. It is a grossly oversimplified description of the problem, but it should be able to illustrate what the parent was referring to.
- fulafel 2y ago
  The real real problem is that we don't know how to effectively use growing transistor budgets to speed applications up compared to the single core era. Adding cache and more cores are both options that make for very sublinear improvements at the margin. (for 95% of usage - somen niche things can utilize resources better, those not coincidentally often being the focus of benchmarks)
- sva_ 2y ago
  Isn't that what AMD 3D V-Cache does? https://www.amd.com/en/products/processors/technologies/3d-v-cache.html https://www.amd.com/en/products/processors/technologies/3d-v...
dialup_sounds 2y ago
Reminds me of the ill-fated Larabee, which was supposed to be something like 50 Pentium-like cores in a GPU-shaped trenchcoat.
- hajile 2y ago
  Larabee was launched as the first generation Knight-series chip (it even had the GPU-specific stuff still in there disabled IIRC). I believe the Knight-series chips were killed because they ran into a bunch of issues and politics with Knight's Mill then killed it in favor of their upcoming GPU architecture only for that to have issues and be delayed too. I suspect that a RISC-V version of Larabee would work better as the ratio of SIMD to the rest of the core would be a lot better.
  - kijiki 2y ago
    A dual-issue in-order RISC-V isn't enough smaller than a P54c to make a significant difference. The overwhelming majority of Larabee's area went to SIMD units and caches.
    - hajile 2y ago
      Do you have any evidence for this statement? Their actual core wasn’t a Pentium. It added in most/all the x86 bloat from the last 3 decades too. Cutting all that stuff and saving power means you can squeeze in a couple more cores and improve performance that more. 32 registers a significant advantage too. RVV also allows wider vectors than AVX. Without reordering, you can get stronger performance guarantees from a single, wide SIMD than from two narrow SIMD (it’s also possible to look at the next couple instructions and switch between executing one at full width or two at half width each without massive investment). And we haven’t even reached peak advantage yet. RISCV has the option for 48/64 bit instructions with loads of room to add VLIW instructions. While most VLIW implementations require everything to be VLIW, this would be optional in RISCV. Your core could be dual issuing two wide VLIW allowing a single thread to theoretically use four vector units. If you add in 4-8 wide SMT, the result is something very GPU-like while still using standard RISCV. Maybe x86 can do this too, but I don’t think it would be anywhere near as efficient and it would certainly eat up a lot of the precious remaining opcode space.

nullc 2y ago

Is the 4c core slower in any other way than L3 cache reductions? Would be interesting to see a compute bound perfectly scaling workload and compare it in terms of absolute performance and performance per watt between Bergamo and Genoa.

mlyle 2y ago
Same performance per cycle; less L3 and lower maximum frequency. Zen4C is said to be a little better performance per watt than Zen4, but it's not clear how much.
toast0 2y ago
> Is the 4c core slower in any other way than L3 cache reductions? It's got a lower clock ceiling. Not much lower than acheivable clocks in really dense zen4 Epyc, but a lot less than an 8 core Ryzen.
wmf 2y ago
https://www.phoronix.com/review/amd-epyc-9754-bergamo/2 https://www.phoronix.com/review/amd-epyc-9754-bergamo/2

deleted 2y ago

[deleted]

Pet_Ant 2y ago

The actual title seems to be "Testing AMD’s Bergamo: Zen 4c Spam" which I really like because for the perspectives of 20 years ago this would feel a bit like "spam" or a CPU-core "Zergling rush". As I said before, I do believe that this is the future of CPUs core. [1] With RAM latency not really having kept pace with CPUs have more performant cores really seems like a waste. In a Cloud setting where you always have some work to do it seems like simpler cores but more of them is really the answer. It's in the environment that the weight of x86's legacy will catch up with us and we'll need to get rid of all the waste transistors decoding cruft. https://news.ycombinator.com/item?id=40535915 https://news.ycombinator.com/item?id=40535915

ComputerGuru 2y ago
I agreed with you up until the x86 comment. Legacy x86 support is largely a red herring. The constraints are architectural (as you noted, per-core memory bandwidth, plus other things) more than they are due to being tied down to legacy instruction sets.
- mlyle 2y ago
  If the goal ends up being many-many-core, x86's complexity tax may start to matter. The cost of x86 compatibility relative to all the complexities required for performance has been small, but if we end up deciding that memory latency is going to kill us and we can't keep complex cores fed, then that is a vote for simpler architectures. I suspect the future will be something between these extremes (tons of dumb cores or ever-more-complicated cores to try and squeeze out IPC), though.
  - hajile 2y ago
    The x86 tax ALREADY matters. Intel was only able to increase the number of decoders by adding entirely independent decoder complexes while reducing the number of decoders per branch. In practice, this means that decode increases for branchy code, but non-branchy code will be limited to just 3 decoders. In contrast, an ARM X4 or Apple M4 can decode 10 instructions under all conditions. This also play into ideas like Larabee/Knights processors where you basically want the tiniest core possible attached to a massive SIMD engine. x86 decode eats up a lot of real estate. Even worse, x86 decode adds a bunch of extra stages which in turn increase the size of the branch predictor. That's not the biggest issue though. Dealing with all of this and all the x86 footguns threaded throughout the pipeline slows down development. It takes more designers and more QAs more time to make and test everything. ARM can develop a similar CPU design for a fraction of the cost compared to AMD/Intel and in less time too because there's simply fewer edge cases they have to work with. This ultimately means the ARM chips can be sold for significantly less money or higher margins.

adrian_b 2y ago

The article says "AMD’s server platform also leaves potential for expansion. Top end Genoa SKUs use 12 compute chiplets while Bergamo is limited to just eight. 12 Zen 4c compute dies would let AMD fit 192 cores in a single socket". It should be noted that the successor of Bergamo, Turin dense, which is expected by the end of the year, will have 12 compute chiplets, for a total of 192 Zen 5c cores, bringing thus both more cores and faster cores.

metadat 2y ago
192 cores per socket? If so, that's pretty wild.

chena12 2y ago

[flagged]

chena12 2y ago
[flagged]
RedShift1 2y ago
test failed successfully
- chena12 2y ago
  [dead]

saxonww 2y ago

My immediate thought is that Sun beat both of these guys to market with the T1 20 years ago. Not exactly the same thing, but I wonder how close to the same idea they are; the line seems to have stopped with the M8, which is a 32c/256t part from 2017.

kllrnohj 2y ago
> the line seems to have stopped with the M8, which is a 32c/256t part from 2017. Epyc Naples was also 32c and also 2017. 4- and 8-way SMT wasn't something AMD or Intel ever bothered with, no, but IBM also did with the POWER line. It seems to help in some workloads, but probably isn't generally useful enough for volume solutions.
kijiki 2y ago
There is an absolutely huge difference between a 32c/256t part and a 128c/256t part. And Tera's MTA predated the T1 by quite a bit with a similar (and evidently doomed) architecture...

Havoc 2y ago

Every time I hear about a 100+ core my mind jumps to python GIL

EasyMark 2y ago
Has been heavily worked on in python 3.12 and up, don’t count out python just yet :)
- Sesse__ 2y ago
  Spoiler alert: Software doesn't jump from “uses one core” to “efficiently uses 192 cores” once you remove the first lock.
  - deleted 2y ago
    [deleted]
  - merb 2y ago
    well back in the days when somebody invented gunicorn it was basically running one worker per core, if the software allowed it. thus you at least could scale on the process level, which of course was super slow if you only had like 10 req/s on a 60 cores machine.
  - EasyMark 2y ago
    Never said it did. I assume you know that at least a few people on here have a basic grasp on multiprocessors, locks, threads, asynch, etc
- Havoc 2y ago
  Yeah not actually an issue for me. I run into skill limitations with python long before 100 core issues.

crote 2y ago

I wonder if these large cache sizes make it possible to operate functionally RAM-less servers? When optimized for size, it'd probably be possible to fit some microservices in an MB of 8 of RAM. You can fit a decent bit of per-connection client state in a few KB, which can take up the rest of the cache. Throw in the X3D cache for 96MB per CCD and you can actually do some pretty serious stuff. With the right preprocessing, it should be possible to essentially stream from NIC straight to CPU, process some stuff, and output it straight to the NIC again without ever touching RAM - although I doubt current DMA hardware allows this. It'd require quite a bit of re-engineering of the on-wire protocol to remove the need for any nontrivially-sized buffers, but I reckon it isn't impossible.

yusyusyus 2y ago
> With the right preprocessing, it should be possible to essentially stream from NIC straight to CPU, process some stuff, and output it straight to the NIC again without ever touching RAM this already exists [0] [0] https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/data-direct-i-o-technology-brief.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
- crote 2y ago
  I wasn't aware of that, thanks for sharing!
timschmidt 2y ago
Lots of older or low end wireless routers have only 16 or 32mb RAM. A full linux stack fits in that. I do a full HTTPS stack on ESP32-C3 in ~500k. Lots of limitations, of course. Probably the biggest difficulty is that most modern systems simply refuse to boot without RAM installed, so you can't choose any platform without BIOS / EFI modifications. Definitely a worthwhile idea though.
- crote 2y ago
  The difference is that those low end routers offload most or even all of the packet processing to dedicated networking hardware: it never even touches the CPU. The whole Linux stack is only used to host the management interface, configure the switching hardware, and deal with high-level stuff like DNS and DHCP. That's also why VPN performance is so horribly bad: there's no hardware acceleration for encryption, so it needs to be done on the CPU, which is not sized to deal with that kinds of traffic.