256 GB main memory with 32 GB graphics card memory in a few years.
Why/User Benefit/User Problem
As Linux machine lovers we've realized how asynchronous network and file IO can enable powerful new userspace applications (io_uring).
The team probably knows how the Rust community has currently settled for threadpool-based executors with some threads dedicated to blocking IO syscalls. You're probably aware of the current state of the Async Foundations WG. We've got ringbahn but IMO ideally we'll get to a future with a better interface to io_uring in std as Niko pointed out.
Thinking about resiliency and "essential devices for society", I've started thinking about Android (soon Fuchsia) phones more as Chrome machines due to Project Fugu. Phones as "out in the field" devices; laptops as mobile workstations. Although Apple has decided to refuse several PWA features, with WebAssembly and WebGPU, I'm optimistic about Chromium as a client platform. This would leave space for high-performance client-server applications served from a System76 workstation, which Chrome clients across LAN or the larger internet could connect to.
In a far future of disruption and flexibility, where on-prem compute may need to be mobile, ideally we'd have >= 1024 GB RAM in a mobile workstation for memory-bound userspace software powered by asynchronous runtimes. All needs of both concurrency and parallelism could be unified into a programming model based on threadpool-based executors invoking asynchronous syscalls in the style of io_uring - the romantic notion of a single-node Rust monolithic backend. Then single workstations could be used in on-prem domains for open source software e.g. real-time medical tissue modeling / CAD / enormous voxel landscapes. (I appreciated your blog post on the Harvard lab, although they need to use a cluster of machines today.) If only on one machine, then it could enable all sorts of graphics- and memory-intensive applications over localhost, although I need to do more research on both localhost and HTTP3 throughput. A WebGPU app in a browser tab might be more limited by the graphics card's memory than by the system's main memory depending on the app.
This target market may be too small for "if you build it they will come" but it's unclear if Google or Apple intend to scale their custom ARM chips to workstation TDP, while System76 is unafraid of thicker designs if need be. Not sure how much new silicon scaling DRAM to >= 1024 GB of main memory in a single, mobile, workstation will require; we seem to be limited by AMD's pipeline for x86 given they have better Wayland drivers. Still researching these topics. Thank you for the work your team does offering Linux workstations to the community.
Description of the feature
256 GB main memory with 32 GB graphics card memory in a few years.
Why/User Benefit/User Problem
As Linux machine lovers we've realized how asynchronous network and file IO can enable powerful new userspace applications (io_uring).
The team probably knows how the Rust community has currently settled for threadpool-based executors with some threads dedicated to blocking IO syscalls. You're probably aware of the current state of the Async Foundations WG. We've got ringbahn but IMO ideally we'll get to a future with a better interface to io_uring in std as Niko pointed out.
Thinking about resiliency and "essential devices for society", I've started thinking about Android (soon Fuchsia) phones more as Chrome machines due to Project Fugu. Phones as "out in the field" devices; laptops as mobile workstations. Although Apple has decided to refuse several PWA features, with WebAssembly and WebGPU, I'm optimistic about Chromium as a client platform. This would leave space for high-performance client-server applications served from a System76 workstation, which Chrome clients across LAN or the larger internet could connect to.
In a far future of disruption and flexibility, where on-prem compute may need to be mobile, ideally we'd have >= 1024 GB RAM in a mobile workstation for memory-bound userspace software powered by asynchronous runtimes. All needs of both concurrency and parallelism could be unified into a programming model based on threadpool-based executors invoking asynchronous syscalls in the style of io_uring - the romantic notion of a single-node Rust monolithic backend. Then single workstations could be used in on-prem domains for open source software e.g. real-time medical tissue modeling / CAD / enormous voxel landscapes. (I appreciated your blog post on the Harvard lab, although they need to use a cluster of machines today.) If only on one machine, then it could enable all sorts of graphics- and memory-intensive applications over localhost, although I need to do more research on both localhost and HTTP3 throughput. A WebGPU app in a browser tab might be more limited by the graphics card's memory than by the system's main memory depending on the app.
This target market may be too small for "if you build it they will come" but it's unclear if Google or Apple intend to scale their custom ARM chips to workstation TDP, while System76 is unafraid of thicker designs if need be. Not sure how much new silicon scaling DRAM to >= 1024 GB of main memory in a single, mobile, workstation will require; we seem to be limited by AMD's pipeline for x86 given they have better Wayland drivers. Still researching these topics. Thank you for the work your team does offering Linux workstations to the community.