AMD 9950X पर SIMD का उपयोग कर 21 GB/s स्पीड से CSV parsing

• नवीनतम Sep 0.10.0 version ने AMD 9950X पर 21 GB/s की शानदार CSV parsing speed हासिल की
• AVX-512 support और mask register issues को पार करने से performance में बड़ा सुधार हुआ
• नया AVX-512-to-256 parser ने AVX2 और पुराने AVX-512 parser, दोनों को पीछे छोड़ दिया
• Multithreaded environment में 10 लाख rows को 72ms में process करते हुए 8 GB/s bandwidth दर्ज की गई
• लगातार software और hardware optimization से 2 साल में लगभग 3 गुना performance improvement हासिल हुआ

---

Sep 0.10.0 release और performance improvement का overview

• Sep ने हाल की 0.10.0 release में AVX-512 support वाले CPU (जैसे AMD 9950X, Zen 5) के लिए optimization किया, और benchmark results अपडेट किए गए
• नवीनतम version में low-level CSV parsing में 21 GB/s जैसा शानदार परिणाम दर्ज किया गया
• यह पिछले version के 18 GB/s की तुलना में बड़ा performance jump है
• सुधारों का विवरण Sep के GitHub release और README में देखा जा सकता है
• इस लेख में .NET 9.0 के AVX-512 machine code की inefficiency को पार करने वाले SIMD-आधारित C# code और x64 SIMD assembly के जरिए performance improvement की प्रक्रिया समझाई गई है

Sep की performance evolution

• Sep के शुरुआती 0.1.0 से 0.10.0 तक, .NET 7.0 से 9.0 तक, और AMD 5950X (Zen 3) से 9950X (Zen 5) तक की प्रगति को visual रूप में दिखाया गया है
• benchmark single-thread आधार पर हैं, और हर release में थोड़ा-बहुत उतार-चढ़ाव हो सकता है
• मुख्य संदेश यह है कि बड़े refactoring (0.2.0 में internal structure rewrite) और छोटे-छोटे changes से जमा हुई optimizations ने लगातार performance बढ़ाई
• Hardware और software की संयुक्त प्रगति से औसतन 2 साल में लगभग 3 गुना बेहतर 21 GB/s parsing speed हासिल हुई
• केवल hardware generation change (5950X→9950X, 4.9→5.7GHz) से भी 1.2x से अधिक improvement का आधार बनता है

AVX-512 code generation और mask register समस्या

• Sep, 0.2.3 से AVX-512 support देता रहा है, लेकिन AVX-512 के mask registers (k1-k8) के उपयोग में सीमाएँ थीं
• .NET 8 में mask registers के लिए direct support नहीं था, इसलिए सामान्य registers के बीच बार-बार copy और conversion performance drop का कारण बनते थे
• शुरुआती दौर में अलग AVX-512 support CPU नहीं होने के कारण Xeon Silver 4316 पर सीमित testing की गई थी, जहाँ इसे सबसे तेज़ पाया गया

9950X upgrade और AVX-512 vs AVX2 तुलना

• हाल में Zen 3 (5950X) से Zen 5 (9950X) पर CPU upgrade करने के बाद Sep के benchmark में 18 GB/s तक performance पहुँची
• AVX-512 और AVX2 parser की direct comparison testing में, थोड़ा अप्रत्याशित रूप से AVX2 ने लगभग 20 GB/s के साथ AVX-512 से लगभग 10% बेहतर प्रदर्शन किया
• यह दिखाता है कि .NET JIT की mask register handling inefficiency अभी भी समस्या बनी हुई है

parser code, assembly analysis और नया AVX-512-to-256 parser

• Sep के सभी parser 16K unit के char span को process करते हैं और SIMD registers (जैसे Vector256) पर आधारित compare operations का उपयोग करते हैं
• SIMD से special characters (newline, quote, delimiter आदि) को तेज़ी से पहचानकर bitmask में बदला जाता है, जिससे set operations optimization संभव होता है
• AVX-512 आधारित parser में mask registers (k1 आदि) और सामान्य registers (zmm आदि) के बीच repeated moves की वजह से बहुत से अतिरिक्त operations थे
• 0.10.0 में MoveMask call को पहले लाकर अनावश्यक mask conversion को कम किया गया, जिससे assembly instructions की संख्या घटी
• AVX2 parser में mask register नहीं होते, इसलिए इसकी structure कहीं ज़्यादा simple रही और यह व्यवहारिक रूप से AVX-512 से तेज़ निकला
• नया AVX-512-to-256 parser AVX-512 से data पढ़ता है और 256-bit conversion instructions से mask handling समस्या को ही bypass कर देता है; implementation सरल हो गई और performance 21 GB/s से ऊपर पहुँची

अलग-अलग parser benchmark का सार

• environment variable के जरिए सभी parser types के benchmark की तुलना में AVX-512-to-256 parser 21.5 GB/s के साथ सबसे तेज़ निकला
• AVX2-आधारित और Vector256-आधारित parser भी केवल 5% के भीतर काफ़ी नज़दीकी performance दिखाते हैं
• Vector128 और Vector512-आधारित parser, AVX2 की तुलना में 5~10% धीमे रहे; खासकर Vector512 parser, Vector128 से भी धीमा था
• IndexOfAny parser दूसरे SIMD parser की तुलना में बहुत धीमा है। Vector64 को 9950X पर acceleration नहीं मिलता, इसलिए उसकी performance बहुत कम है
• AVX-512 और AVX2-आधारित SIMD parser ने समान श्रेणी के CSV parser की तुलना में दबदबे वाली performance साबित की

उच्च-स्तरीय benchmark: 5950X और 9950X तुलना

• 10 लाख package asset rows के आधार पर Sep_MT ने 9950X पर 72ms (8GB/s) और 5950X पर 119ms (4.9GB/s) दर्ज किए
• वास्तविक payload data (जैसे float आदि) में भी 9950X पर multithreaded mode में ~8GB/s bandwidth हासिल हुई
• generation change (5950X→9950X) से वास्तविक application parsing में लगभग 1.5~1.6x improvement देखा गया
• competing CSV libraries (Sylvan, ReadLine, CsvHelper आदि) की तुलना में कहीं अधिक throughput और न्यूनतम resource allocation साबित हुई

निष्कर्ष और सार

• Sep 0.10.0 ने software optimization और नवीन hardware features (AVX-512, उच्च clock) के मेल से CSV parsing performance की सीमाएँ आगे बढ़ाईं
• नवीनतम SIMD algorithm design, .NET JIT code, और assembly structure में सुधार इस innovation की कुंजी हैं
• कम समय में संचित performance improvement और architecture generation change का असर प्रभावशाली है
• Sep, CSV parsing क्षेत्र में वास्तविक रूप से industry-top स्तर की high performance, multiplatform support, और scalability पेश करता है

[GN⁺]

Hacker News राय

• यह बात बेहद हास्यास्पद है कि Intel ने कई साल तक consumer products में AVX-512 support के लिए chip area तक निवेश किया, लेकिन अब जब libraries धीरे-धीरे इसका उपयोग शुरू कर रही हैं, उसी समय उसने consumer SKU से AVX-512 हटा दिया। ऐसा भी नहीं कि AMD का AVX-512 support बहुत बेहतर है; विडंबना सिर्फ यह है कि Intel ने खुद अपनी निवेश की हुई चीज़ छोड़ दी, और नतीजतन AMD के consumer CPU में AVX-512 आ गया।
  • Intel हमेशा से tech market बनाता है (Optane), फिर अचानक पीछे हट जाता है (Depth Cameras), और इस पैटर्न से consumers को भ्रमित करता रहता है। वह नई technology पर एक साथ दांव लगाता है और uptake न मिले तो तुरंत छोड़ देता है। Linux kernel में Optane support अब जाकर mature होने वाला था, तभी उसे बंद कर दिया। अजीब cost-cutting strategies भी रही हैं। इतिहास में पीछे जाएँ तो Intel iAPX 432 के समय से वही गलतियाँ दोहराई जा रही हैं।
  • इस लेख में AMD CPU पर original: 18GB/s, AVX2: 20GB/s, AVX512: 21GB/s की speed दिखाई गई है। AVX-512 को AVX2 पर लगभग कोई खास बढ़त नहीं है। Intel consumer CPU में E-core पर भी AVX2 support है। Benchmark single-threaded है। Intel ने अधिक cores के लिए chip से AVX-512 हटाया, और उसका top-end 24-core है, जबकि AMD 16-core है। चूँकि AVX2→AVX512 का अंतर मामूली है, multi-threaded में ज़्यादा core वाला पक्ष जीत सकता है। अधिकांश real workloads में AVX-512 की बजाय core count बढ़ने का फायदा अधिक है। कुछ बहुत खास tasks को छोड़कर Intel का फैसला तर्कसंगत था।
  • जल्द ही AVX-10 आने वाला है, और इसमें AVX-512 जैसी लगभग वही functionality होने की उम्मीद है (फर्क क्या है, मुझे भी नहीं पता)।
  • इस लेख की सबसे दिलचस्प बात यह थी कि AMD 9950X पर AVX2 parser, AVX-512 आधारित parser से लगभग 10% तेज था (20GB/s बनाम 21GB/s)। अंततः AVX-512 आम consumer के लिए बहुत मददगार नहीं दिखता। CSV parsing अगर 20GB/s तक हो रही है तो मुझे शिकायत नहीं होगी। सिर्फ assembly enthusiasts ही support होने या न होने पर इतना ध्यान देते हैं।
  • Intel का इतना बेवकूफी भरा व्यवहार सच में चौंकाने वाला है।
  • तसल्ली की बात यह है कि Sep जहाँ संभव हो, बिना अलग configuration के भी AVX-512 का उपयोग करता है। यह JIT runtime में अच्छी तरह चलता है, इसलिए अनजाने में lowest-performance baseline को target करने पर भी खास नुकसान नहीं होता।
  • Intel का software support भी खास अच्छा नहीं है। मेरे laptop का iGPU भी काफी ठीक है, लेकिन PyTorch वगैरह में proper support नहीं मिलने से अफसोस होता है। llama.cpp और Vulkan inference अच्छे से चल जाते हैं, इसलिए उम्मीद है कि दूसरा software भी इसी तरह support दे।
• हर character के लिए चार comparisons ('\n', '\r', ';', '“') और फिर तीन or operations करने के बजाय, एक आम trick से 1 shuffle, 1 comparison, और 0 or operations में काम हो सकता है। मैंने इस trick पर एक blog post भी लिखा है, देख सकते हैं। वैसे इस लेख में भी vpternlogd और vpor operations से or operations कम किए गए हैं।
• Intel का consumer CPU में slow cores डालना, या 'multi-pumping' पर विचार किए बिना AVX-512 पूरी तरह हटा देना, बहुत बुरा लगता है।
  • इस चुनाव का मुख्य कारण 10nm process की समस्या थी। Yield खराब थी और लागत बहुत ज्यादा थी, इसलिए chip को जितना हो सके काटकर Atom-family cores/low-power marketing से revenue निकालने की कोशिश की गई। महंगे products में die size बढ़ाकर margin घटाते हुए server/cloud market बचाने की कोशिश हुई। मुनाफ़ा आखिरकार घटा और market share भी गया, लेकिन कम से कम उन्होंने कोशिश तो की।
• Sep के लॉन्च (जून 2023) के बाद 2 साल में लगभग 3x speedup का दावा, hardware jump को ध्यान में रखें तो विवादास्पद है।
  • एक ही hardware पर software (0.9.0 और 0.10.0) का improvement 17% है, और 0.9.0 के 13088 पर 17% जोड़ें तो 15375 होता है। इसे 0.1.0 के 7335 से तुलना करें तो लगभग 2.1x improvement बनता है।
  • एक ही hardware पर sep के पिछले version की तुलना में 3GB/s improvement का दावा किया गया है, और actual speed तथा hardware information भी पारदर्शी रूप से दी गई है।
  • आजकल Moore's Law जैसा दौर भी नहीं रहा, इसलिए सिर्फ hardware से 3x speedup की उम्मीद करना कठिन है। इस हिसाब से यह उपलब्धि आज के समय में भी काफी प्रभावशाली लगती है।
  • यह स्पष्ट है कि hardware jump को गिने बिना 3x improvement कहना बहस का विषय हो सकता है, लेकिन फिर भी साल-दर-साल software की वास्तविक performance देखने का यह एक दिलचस्प नज़रिया है।
  • Benchmark chart चार CPU generations छोड़कर अचानक 'बड़ा performance improvement' जैसा दिखाता है, इसलिए उस पर भरोसा नहीं होता।
• उम्मीद है कि Arthur Whitney इस नतीजे से प्रेरित होकर 1-line code से इसे पार कर जाएँगे, या shakti engine update के साथ 1 line में record तोड़ देंगे, या फिर news update आएगी। प्रगति देखने की उम्मीद है।
• यह सोचकर ही घबराहट होती है कि किसे दसियों लाख lines वाली CSV को इस speed से process करना पड़ता होगा।
  • मेरा भी ऐसा अनुभव रहा है। शुरुआत में छोटे data volume के हिसाब से CSV चुना जाता है, क्योंकि non-developers—खासकर Excel अच्छी तरह इस्तेमाल करने वाले लोग—इसे आसानी से पढ़ लेते हैं, और logs/processes भी CSV में साफ-सुथरे ढंग से संभाले जाते हैं। लेकिन जब data 10x, 100x बढ़ जाता है, तब अरबों lines वाली CSV को optimize करके जल्दी ingest करना वास्तविक ज़रूरत बन जाता है। इस तरह की optimization से internal processes को धीरे-धीरे अधिक उपयुक्त format में migrate करने के लिए समय मिल जाता है।
  • CSV अंदरूनी इस्तेमाल में भी सोच से अधिक common format है, और इसका एक फायदा यह है कि compression (deflate) आसान है। मैंने पहले ऐसा code संभाला है जो NIC card की speed पर Netflow data को CSV में उगलता था। निजी तौर पर मुझे लगता है कि अगर इतनी जटिल processing करनी ही है तो protocol buffers का उपयोग करना बेहतर होगा। protobuf कोई इतना कठिन format भी नहीं है, फिर भी उसका adoption ठीक से नहीं होता।
  • 21GB/s स्तर की CSV process करने के बाद उसके output को store करने का विचार और भी डरावना लगता है। चाहे aggregation कितनी भी उपयोगी हो, इतनी speed पर अंततः वह data कहीं न कहीं जमा तो होगा ही, और यही बात जिज्ञासा पैदा करती है।
  • कई कमियों के बावजूद, मुझे अब भी लगता है कि CSV सबसे common data interchange format है।
  • finance sector में CSV इसलिए चलता है क्योंकि इसे हर कोई share कर सकता है, और text-based होने से इसे कहीं भी डालकर process किया जा सकता है।
  • उदाहरण के तौर पर accounting department साल के अंत में जो cartesian product files भेजता है, उन्हें लिया जा सकता है।
  • सच में, मुझे ऐसी पुरानी शैली की CSV files से जूझना पड़ता है।
  • लगभग हर मामले में HDF5, CSV से बेहतर है। फिर भी इसे न अपनाने की वजह शायद सिर्फ अज्ञान, आलस्य, या 'काम तो चल रहा है' जैसी सोच ही हो सकती है।
• मैं assembly code की उम्मीद से आया था, लेकिन यह C# निकला; यह चौंकाने वाला भी था और प्रभावशाली भी। शानदार परिणाम है।
  • आधुनिक .NET वह 'high-level language' है जिसमें SIMD और vector intrinsics का सबसे गहरा integration है। Microsoft के Tanner Gooding ने इसमें काफी प्रगति कराई है, और इस विषय पर उनके blog posts भी बेहतरीन हैं।
• लेख में यह स्पष्ट रूप से परिभाषित नहीं है कि 21GB/s वाला code आखिर ठीक-ठीक क्या कर रहा है, और यही बात भ्रम पैदा करती है। उदाहरण के लिए parsing format क्या है (जैसे CSV में quotes handling आदि), और parsing के बाद परिणाम का उपयोग कैसे हो रहा है (क्या उसे किसी data structure में डाला जा रहा है), यह स्पष्ट नहीं है।
  • लेख में गणना किया गया ns/row लगभग 27ns/row है (प्रति सेकंड 37,000 row के आसपास), लेकिन अगर speed 21GB/s है तो प्रति row लगभग 570KB बैठता है, इसलिए यह benchmark बहुत असामान्य लगता है।
• मेरे अनुभव में custom SIMD code से modern compiler की auto-vectorization की तुलना में बड़ा फायदा पाना मुश्किल रहा है, खासकर vector-friendly code में। हालाँकि JSON parsing जैसे कुछ विशेष मामलों में बात अलग हो सकती है।
• हाल ही में मैंने 300GB CSV extract पर काम किया, और manipulation व integrity verification में इतना समय लगा कि ऐसे तेज CSV parser की सख्त ज़रूरत महसूस हुई।
  • यह समझ से बाहर है कि floating-point data को store करने के लिए विशेष रूप से बने format का उपयोग क्यों नहीं किया जाता। HDF5 कहीं बेहतर विकल्प है।