Rust runtime optimized for Apple Silicon
- Rust developers are reviving interest in thread-per-core async runtimes for Mac hardware, pointing to existing projects like Compio and Monoio that already pair Rust tasks with OS-native I/O engines. - Compio says it uses IOCP on Windows, io_uring on Linux and polling elsewhere, while Monoio advertises a thread-per-core design with io_uring, epoll and kqueue across supported platforms. - The push reflects a wider split in async Rust: general-purpose Tokio dominates, while lower-level runtimes chase lower latency and less cross-thread contention for servers and local inference workloads. (github.com 1) (github.com 2)
An async runtime is the traffic cop for Rust programs that juggle thousands of network or file operations at once. Projects like Compio and Monoio are built around a different rulebook from Tokio: keep work on one core, and use each operating system’s native I/O path. (doc.rust-lang.org) (github.com 1) (github.com 2) The model is called thread-per-core. Instead of moving tasks around a shared pool, the runtime pins work to a specific thread, which cuts down on locks, cache misses and the need for Rust’s cross-thread `Send` and `Sync` guarantees. (github.com 1) (github.com 2) That design is not a new proposal so much as a growing branch of async Rust. ByteDance’s Monoio describes itself as a “thread-per-core Rust runtime with io_uring/epoll/kqueue,” and Compio calls itself “a thread-per-core async Rust runtime with IOCP/io_uring/polling,” inspired by Monoio. (github.com 1) (github.com 2) The operating-system part matters because Linux, Windows and macOS do not expose the same plumbing. Linux has io_uring, Windows has Input/Output Completion Ports, and macOS commonly relies on kqueue or polling-based fallbacks. (github.com) (github.com) (github.com) For Apple Silicon, the appeal is less about a single Mac-only syscall than about avoiding unnecessary thread hops on fast local hardware. On an M-series machine, a runtime that keeps socket or file work local to one core can trade scheduler flexibility for tighter latency and lower overhead. (github.com) (include.gr) That tradeoff comes with limits. Thread-per-core runtimes can stumble when load is uneven, because tasks do not move freely between workers the way they do in Tokio’s work-stealing model. (rust-lang.github.io) (chesedo.me) Tokio still dominates the Rust ecosystem because most libraries, examples and production deployments assume it. Even Tokio’s own io_uring design notes say a Linux-first runtime would likely use an isolated thread-per-core model and many non-`Send` types to expose lower-level performance gains. (corrode.dev) (github.com) Mac support in these newer runtimes is also more uneven than the hype suggests. Monoio documents a legacy driver for macOS based on kqueue, and Compio’s issue tracker includes a 2025 macOS-on-arm64 bug report involving filesystem APIs and thread-pool settings. (github.com) (github.com) So the story on Apple Silicon is not that Rust suddenly got a brand-new Mac runtime this week. It is that developers are paying fresh attention to a class of runtimes that already exists, and asking whether OS-native, thread-per-core designs fit the next wave of high-throughput servers and local inference backends. (github.com) (github.com)
