GN⁺: 코어당 스레드(Thread-per-core)

• 본 기사는 Rust 커뮤니티에서 멀티 스레드 실행자의 사용에 대한 논란을 논의하고 있으며, 이는 작업을 균형 있게 분배하기 위해 work-stealing을 수행하는 async 런타임입니다.
• 일부 Rust 사용자들은 "thread-per-core"라는 대안적인 아키텍처를 주장하며, 이는 성능이 더 우수하고 구현하기 쉽다고 약속하고 있습니다.
• "thread-per-core"라는 용어는 오해의 소지가 있습니다. 모든 멀티 스레드 실행자가 thread-per-core이며, OS 스레드를 코어 당 하나씩 생성하고 이러한 스레드 위에서 작업을 스케줄링합니다.
• Thread-per-core는 세 가지 아이디어를 결합합니다: 사용자 공간에서의 동시성 처리, I/O를 비동기화하여 스레드 차단을 피하고, CPU 코어 간의 데이터를 분할하여 동기화 비용과 CPU 캐시 간의 데이터 이동을 제거합니다.
• 이 논란은 주로 세 번째 포인트에 대한 것이며, async Rust를 사용하면 처음 두 요구사항을 충족시킬 수 있습니다.
• Thread-per-core 아키텍처에서는 두 가지 최적화를 수행할 수 있습니다: 스레드 간의 작업을 훔쳐가고, 가능한 한 적은 상태를 공유합니다.
• Work-stealing은 모든 스레드가 항상 작업을 할 수 있도록 하여 tail latency를 개선하지만, 구현하기 어렵고 동기화 비용과 캐시 누락을 초래할 수 있습니다.
• Share-nothing은 데이터를 단일 CPU 코어에 속한 더 빠른 캐시에 유지함으로써 tail latency를 개선하지만, 여러 파티션에서 상태를 변경해야 하는 복잡한 애플리케이션에 대해 구현하기 어려울 수 있습니다.
• 본 기사는 공유 상태를 사용하는 시스템에서 work-stealing이 부하하에서 CPU 사용률을 개선할 수 있을 것이라고 제안합니다.

[neo]

Hacker News 의견

• 논쟁의 핵심은 코어당 스레드 작업 훔치기(executors)가 아니라 Rust에서 async/await가 좋은 추상화인지 여부입니다.
• 코어당 스레드는 일반적인 많은 코어 서버에서의 계산의 확장성과 효율성을 해결하기 위해 발명되었으며, 이는 고처리량 I/O 바운드 작업에 탁월하다는 것이 밝혀졌습니다.
• 코어당 스레드 아키텍처는 그들의 확장성과 효율성 때문에 여기에 머무를 것이지만, 대부분의 소프트웨어 엔지니어들은 현대적이고 관용적인 코어당 스레드 디자인이 어떤 것인지에 대한 직관이 제한적입니다.
• 일부 애플리케이션은 단일 스레드 시스템에 더 적합하며, Rust는 이러한 유연성을 허용합니다.
• Rust의 async 프로그래밍에 대한 비판이 있으며, 이에는 'Send + Sync + 'static이 요구되는 것이 포함되어 있으며, 일부는 이를 부담스럽게 느낍니다.
• Send bound는 executor 스레드 간의 작업 이동을 허용하는 요구사항으로, Rust async 시스템의 결점으로 보입니다.
• 모든 프로그램에 대한 최상의 성능을 달성하는 일괄적인 접근법은 없으며, async 사용은 많은 Rust 프로그램에 대해 성급한 최적화로 간주됩니다.
• 커널 컨텍스트 스위치는 비용이 많이 들기 때문에 코어당 스레드 디자인을 선호하지만, 사용자 공간 컨텍스트 스위칭 스케줄링도 문제가 될 수 있습니다.
• 작업 훔치기는 꼬리 지연을 해결하는 방법이지만, 캐시 미스와 Send, Sync 및 ‘static과 같은 추가 개발자 제약 조건을 초래합니다.