कोर-प्रति-थ्रेड (Thread-per-core)

• यह लेख Rust कम्युनिटी में मल्टी-थ्रेडेड executor के उपयोग पर चल रही बहस पर चर्चा करता है, जो एक async runtime है और काम को संतुलित ढंग से बाँटने के लिए work-stealing करता है.
• कुछ Rust उपयोगकर्ता "thread-per-core" नाम की एक वैकल्पिक आर्किटेक्चर की वकालत करते हैं, जिसका दावा है कि यह बेहतर performance देता है और implement करना आसान है.
• "thread-per-core" शब्द भ्रामक हो सकता है. सभी मल्टी-थ्रेडेड executor वास्तव में thread-per-core ही होते हैं: वे हर core के लिए एक OS thread बनाते हैं और उन्हीं threads पर काम schedule करते हैं.
• Thread-per-core तीन विचारों को जोड़ता है: user space में concurrency को संभालना, threads के block होने से बचने के लिए I/O को asynchronous बनाना, और synchronization cost तथा CPU cache के बीच data movement को हटाने के लिए CPU cores के बीच data को partition करना.
• यह बहस मुख्यतः तीसरे बिंदु को लेकर है, और async Rust का उपयोग करके पहली दो आवश्यकताओं को पूरा किया जा सकता है.
• Thread-per-core आर्किटेक्चर में दो optimization किए जा सकते हैं: threads के बीच काम चुराना, और जितना संभव हो उतना कम state साझा करना.
• Work-stealing यह सुनिश्चित करके tail latency को बेहतर बनाता है कि सभी threads के पास हमेशा काम रहे, लेकिन इसे implement करना कठिन है और इससे synchronization cost तथा cache miss बढ़ सकते हैं.
• Share-nothing data को एक ही CPU core से जुड़े तेज cache में बनाए रखकर tail latency को बेहतर बनाता है, लेकिन उन जटिल applications के लिए इसे implement करना कठिन हो सकता है जिन्हें कई partitions में state बदलनी पड़ती है.
• यह लेख सुझाव देता है कि shared state का उपयोग करने वाले systems में work-stealing, load के दौरान CPU utilization को बेहतर बना सकता है.

[GN⁺]

Hacker News राय

• बहस का मूल मुद्दा thread-per-core work-stealing executors नहीं, बल्कि यह है कि क्या Rust में async/await एक अच्छा abstraction है।
• thread-per-core को सामान्य multi-core servers पर computation की scalability और efficiency की समस्या हल करने के लिए विकसित किया गया था, और यह high-throughput I/O-bound workloads में भी बेहतरीन साबित हुआ है।
• thread-per-core architecture अपनी scalability और efficiency की वजह से बना रहेगा, लेकिन अधिकांश software engineers की यह सहज समझ सीमित है कि आधुनिक और idiomatic thread-per-core design वास्तव में कैसा दिखता है।
• कुछ applications single-threaded systems के लिए अधिक उपयुक्त हैं, और Rust ऐसी flexibility की अनुमति देता है।
• Rust की async programming को लेकर आलोचनाएँ हैं, जिनमें Send + Sync + 'static की आवश्यकता भी शामिल है, और कुछ लोगों को यह बोझिल लगती है।
• Send bound वह requirement है जो executor threads के बीच tasks को स्थानांतरित करने की अनुमति देती है, और यह Rust async system की एक कमी जैसा लगता है।
• सभी programs के लिए सर्वोत्तम performance पाने का कोई एक जैसा universal approach नहीं है, और async का उपयोग कई Rust programs के लिए premature optimization माना जाता है।
• kernel context switches महंगे होते हैं, इसलिए thread-per-core design को प्राथमिकता दी जाती है, लेकिन user-space context-switching scheduling भी समस्याएँ पैदा कर सकता है।
• work-stealing tail latency को हल करने का एक तरीका है, लेकिन इससे cache misses और Send, Sync, तथा 'static जैसी अतिरिक्त developer constraints भी पैदा होती हैं।