Parsing CSV dengan SIMD pada AMD 9950X dengan kecepatan 21 GB/s

• Versi terbaru Sep 0.10.0 mencapai kecepatan parsing CSV yang luar biasa, 21 GB/s, di AMD 9950X
• Performa meningkat besar berkat dukungan AVX-512 dan keberhasilan mengatasi isu register mask
• Parser AVX-512-to-256 yang baru menunjukkan hasil melampaui AVX2 dan parser AVX-512 sebelumnya
• Dalam lingkungan multithread, 1 juta baris diproses dalam 72ms dengan bandwidth 8 GB/s
• Optimisasi perangkat lunak dan perangkat keras yang berkelanjutan menghasilkan peningkatan performa sekitar 3x dalam 2 tahun

---

Rilisan Sep 0.10.0 dan ringkasan peningkatan performa

• Pada rilisan 0.10.0 terbaru, Sep melakukan optimisasi untuk CPU dengan dukungan AVX-512 (misalnya AMD 9950X, Zen 5), dan hasil benchmark telah diperbarui
• Pada versi terbaru, Sep mencatat capaian luar biasa sebesar 21 GB/s pada parsing CSV tingkat rendah
• Dibandingkan versi sebelumnya, ini merupakan peningkatan performa yang signifikan dari 18 GB/s
• Rincian peningkatan dapat dilihat di rilisan GitHub dan README Sep
• Artikel ini menjelaskan proses peningkatan performa melalui kode C# berbasis SIMD dan assembly SIMD x64 yang mengatasi inefisiensi machine code AVX-512 di .NET 9.0

Proses perkembangan performa Sep

• Perkembangan Sep dari 0.1.0 awal hingga 0.10.0, dari .NET 7.0 ke 9.0, serta dari AMD 5950X (Zen 3) ke 9950X (Zen 5) ditampilkan secara visual
• Benchmark didasarkan pada single-thread, dan tiap rilisan dapat memiliki sedikit variasi
• Pesan utamanya adalah bahwa refaktorisasi besar (penulisan ulang struktur internal di 0.2.0) maupun optimisasi kecil yang terakumulasi sama-sama mendorong peningkatan performa secara konsisten
• Berkat perkembangan bersama perangkat keras dan perangkat lunak, kecepatan parsing 21 GB/s yang sekitar 3x lebih tinggi berhasil dicapai dalam rata-rata 2 tahun
• Perubahan antargenerasi perangkat keras saja (5950X→9950X, 4.9→5.7GHz) sudah menjadi dasar peningkatan lebih dari 1.2x

Pembuatan kode AVX-512 dan masalah register mask

• Sep telah mendukung AVX-512 sejak 0.2.3, tetapi ada keterbatasan dalam pemanfaatan register mask AVX-512 (k1-k8)
• Di .NET 8, belum ada dukungan langsung untuk register mask, sehingga penyalinan dan konversi berulang antar register normal menjadi faktor penurun performa
• Pada masa awal ketika belum ada CPU terpisah yang mendukung AVX-512, pengujian terbatas dilakukan di Xeon Silver 4316 dan memastikan bahwa itu yang paling cepat

Upgrade ke 9950X dan perbandingan AVX-512 vs AVX2

• Setelah baru-baru ini meng-upgrade CPU dari Zen 3 (5950X) ke Zen 5 (9950X), benchmark Sep menunjukkan hasil mencapai 18 GB/s
• Dalam eksperimen perbandingan langsung antara parser AVX-512 dan AVX2, agak mengejutkan, AVX2 menunjukkan performa sekitar 20 GB/s, kira-kira 10% lebih cepat daripada AVX-512
• Ini mengindikasikan bahwa inefisiensi penanganan register mask pada .NET JIT masih menjadi masalah

Kode parser, analisis assembly, dan parser AVX-512-to-256 baru

• Semua parser Sep memproses char span dalam unit 16K dan memanfaatkan operasi perbandingan berbasis register SIMD (Vector256 dan lainnya)
• SIMD digunakan untuk mendeteksi karakter khusus (baris baru, tanda kutip, delimiter, dll.) dengan cepat lalu mengubahnya menjadi bitmask demi optimisasi operasi himpunan
• Parser berbasis AVX-512 memiliki banyak operasi berlebih akibat perpindahan berulang antara register mask (k1 dan sejenisnya) dan register umum (zmm dan sejenisnya)
• Di 0.10.0, pemanggilan MoveMask dimajukan untuk meminimalkan konversi mask yang tidak perlu, sehingga jumlah instruksi assembly berkurang
• Parser AVX2 tidak memiliki register mask sehingga strukturnya jauh lebih sederhana dan dalam praktiknya lebih cepat daripada AVX-512
• Parser AVX-512-to-256 yang baru membaca data dengan AVX-512 lalu memakai instruksi konversi 256-bit untuk melewati masalah pemrosesan mask itu sendiri; implementasinya menjadi lebih ringkas dan mencapai performa lebih dari 21 GB/s

Ringkasan berbagai benchmark parser

• Hasil perbandingan benchmark semua tipe parser melalui environment variable menunjukkan bahwa parser AVX-512-to-256 adalah yang tercepat dengan 21.5 GB/s
• Parser berbasis AVX2 dan Vector256 juga menunjukkan performa yang sangat dekat, dengan selisih hanya dalam 5%
• Parser berbasis Vector128 dan Vector512 5~10% lebih lambat dibanding AVX2, dan khususnya parser Vector512 bahkan lebih lambat daripada Vector128
• Parser IndexOfAny jauh lebih lambat dibanding parser SIMD lain. Vector64 tidak diakselerasi pada 9950X sehingga performanya sangat rendah
• Parser SIMD berbasis AVX-512 dan AVX2 membuktikan performa yang sangat unggul dibanding parser CSV sejenis

Benchmark tingkat atas: perbandingan 5950X dan 9950X

• Berdasarkan 1 juta baris aset paket, Sep_MT mencatat 72ms (8GB/s) di 9950X dan 119ms (4.9GB/s) di 5950X
• Pada data beban nyata (seperti float), bandwidth ~8GB/s juga dicapai secara multithread di 9950X
• Perubahan generasi (5950X→9950X) menghasilkan peningkatan sekitar 1.5~1.6x pada parsing aplikasi nyata
• Dibanding pustaka CSV pesaing (Sylvan, ReadLine, CsvHelper, dll.), Sep membuktikan throughput yang jauh lebih tinggi dan alokasi sumber daya minimal

Kesimpulan dan ringkasan

• Sep 0.10.0 menembus batas performa parsing CSV melalui kombinasi optimisasi perangkat lunak dan fitur perangkat keras terbaru (AVX-512, clock tinggi)
• Perancangan algoritme SIMD terbaru, perbaikan kode JIT .NET, dan struktur assembly adalah inti inovasinya
• Efek dari peningkatan performa kumulatif dan perubahan generasi arsitektur dalam waktu singkat sangat mengesankan
• Sep secara efektif menghadirkan performa tinggi, multiplatform, dan skalabilitas kelas atas di ranah parsing CSV

[GN⁺]

Komentar Hacker News

• Sangat absurd bahwa Intel menginvestasikan area chip selama bertahun-tahun untuk mendukung AVX-512 pada produk konsumen, tetapi justru ketika library mulai semakin banyak memakainya, mereka malah menghapus AVX-512 dari SKU konsumen; bukan berarti dukungan AVX-512 AMD lebih baik, hanya saja ironisnya CPU konsumen AMD jadi memiliki AVX-512 karena Intel sendiri melepaskan investasi yang dulu mereka tanam
  • Intel selalu mengulang pola membangun pasar teknologi (Optane), lalu mundur mendadak (Depth Cameras) dan membuat konsumen bingung; mereka all-in pada teknologi baru lalu langsung berhenti kalau adopsinya tidak muncul, dukungan Optane dihentikan tepat ketika dukungannya di kernel Linux mulai matang, mereka juga punya strategi penghematan biaya yang aneh; kalau ditarik lebih jauh ke belakang, mereka mengulang kesalahan yang sama sejak era Intel iAPX 432
  • Artikel ini menunjukkan kecepatan CPU AMD sebagai berikut: orisinal 18GB/s, AVX2 20GB/s, AVX512 21GB/s; AVX-512 hampir tidak punya keunggulan dibanding AVX2, CPU konsumen Intel mendukung AVX2 bahkan di E-core, benchmark ini single-threaded, Intel membuang AVX-512 dari chip demi lebih banyak core dan hasilnya model teratas punya 24 core, sementara AMD 16 core; karena perbedaan AVX2→AVX512 sangat kecil, pada beban multi-thread pihak dengan core lebih banyak bisa menang, dan pada sebagian besar workload nyata penambahan jumlah core lebih menguntungkan daripada AVX-512; kecuali beberapa tugas yang sangat spesifik, menurut saya keputusan Intel cukup masuk akal
  • AVX-10 akan segera hadir, dan tampaknya akan memiliki fitur yang hampir sama dengan AVX-512 (saya juga tidak tahu tepatnya apa bedanya)
  • Bagian paling menarik dari artikel ini adalah bahwa pada AMD 9950X, parser AVX2 hanya sekitar 10% lebih lambat daripada parser berbasis AVX-512 (20GB/s vs 21GB/s); pada akhirnya AVX-512 tampaknya tidak terlalu membantu konsumen nyata, saya juga tidak akan mengeluh kalau parsing CSV sudah mencapai 20GB/s, hanya penggemar assembly yang benar-benar sensitif soal dukungan ini
  • Benar-benar konyol melihat Intel bertindak sebodoh ini
  • Kalau itu bisa menghibur, Sep memakai AVX-512 kapan pun memungkinkan tanpa perlu pengaturan terpisah; ini berjalan baik di runtime JIT, jadi tanpa sengaja pun tidak ada kerugian berarti saat menargetkan baseline performa terendah
  • Dukungan perangkat lunak Intel juga kurang bagus; iGPU di laptop saya juga cukup layak, tetapi sayang tidak didukung dengan baik di PyTorch dan sejenisnya; llama.cpp dan inferensi Vulkan berjalan baik, jadi saya berharap perangkat lunak lain juga memberi dukungan seperti itu
• Daripada melakukan empat perbandingan per karakter ('\n', '\r', ';', '“') lalu tiga operasi or, ada trik umum untuk melakukannya dengan satu shuffle, satu compare, dan nol operasi or; saya pernah menulis posting blog tentang trik ini, silakan lihat; omong-omong, bahkan di artikel ini operasi or juga dikurangi dengan vpternlogd dan vpor
• Sangat tidak enak dipandang melihat Intel memutuskan bahwa CPU konsumen harus berisi core lambat, lalu membuang seluruh AVX-512 tanpa memikirkan 'multi-pumping'
  • Penyebab utama pilihan ini adalah masalah proses 10nm; yield-nya buruk dan biayanya terlalu mahal, jadi mereka berusaha menghasilkan uang dengan memotong chip sebanyak mungkin dan memasarkan core keluarga Atom/daya rendah; untuk produk mahal mereka memperbesar ukuran dan memangkas margin demi mempertahankan pasar server/cloud; profitabilitas akhirnya tetap turun dan pangsa pasar juga hilang, tetapi setidaknya mereka memang mencoba
• Klaim bahwa sejak rilis Sep (Juni 2023) performanya meningkat sekitar 3x dalam dua tahun cukup bisa diperdebatkan jika lompatan hardware ikut diperhitungkan
  • Pada hardware yang sama, peningkatan perangkat lunak (0.9.0 ke 0.10.0) adalah 17%, dan jika 17% ditambahkan ke 13088 dari 0.9.0 hasilnya 15375; dibandingkan dengan 7335 dari 0.1.0, itu peningkatan sekitar 2,1x
  • Mereka memang mengklaim peningkatan 3GB/s dibanding versi sep sebelumnya pada hardware yang sama, dan kecepatan aktual beserta informasi hardwarenya ditulis dengan transparan
  • Sekarang kita juga sudah melewati era seperti hukum Moore, jadi sulit berharap peningkatan 3x hanya dari hardware; menurut saya capaian sebesar ini pun sudah cukup mengesankan di zaman sekarang
  • Jelas masih bisa diperdebatkan jika mereka mengklaim peningkatan 3x tanpa memperhitungkan lompatan hardware, tetapi tetap menarik sebagai salah satu cara melihat performa nyata perangkat lunak dari tahun ke tahun
  • Grafik benchmark-nya melompati sampai empat generasi CPU lalu mendadak terlihat seperti 'peningkatan performa besar', jadi tidak terlalu meyakinkan
• Saya berharap Arthur Whitney terpacu oleh hasil ini lalu melampauinya dengan kode satu baris, atau memecahkan rekor lagi dengan pembaruan mesin shakti dan satu baris kode, atau setidaknya ada pembaruan berita; saya menantikan perkembangan lebih lanjut
• Membayangkan siapa yang harus memproses CSV puluhan juta baris dengan kecepatan seperti ini saja sudah bikin ngeri
  • Saya juga pernah mengalaminya; awalnya CSV dipilih karena cocok untuk volume data kecil dan mudah dibaca oleh non-developer—terutama orang yang mahir Excel—jadi log/proses juga ditangani rapi dengan CSV; tetapi ketika datanya membengkak 10x atau 100x, mengoptimalkan ingest CSV bernilai miliaran baris dengan cepat menjadi kebutuhan nyata; optimasi seperti ini pada dasarnya membeli waktu untuk memindahkan proses internal sedikit demi sedikit ke format yang lebih sesuai
  • CSV ternyata cukup sering dipakai bahkan secara internal, dan punya kelebihan mudah dikompresi (deflate); dulu saya pernah menangani kode yang memuntahkan data Netflow sebagai CSV pada kecepatan kartu NIC; secara pribadi, kalau pemrosesannya sudah serumit itu, lebih baik pakai protocol buffers saja; protobuf bukan format yang sulit, tetapi entah kenapa adopsinya tidak terlalu jalan
  • Yang terasa lebih menakutkan adalah menyimpan hasil dari pemrosesan CSV di kisaran 21GB/s; seberguna apa pun agregasinya, pada kecepatan seperti itu pada akhirnya data itu pasti menumpuk di suatu tempat, dan itu memunculkan pertanyaan tersendiri
  • Terlepas dari banyak kekurangannya, saya rasa CSV masih merupakan format pertukaran data yang paling umum
  • Di sektor keuangan, CSV bisa dibagikan ke semua orang, berbasis teks, dan bisa dimasukkan serta diproses di mana saja
  • Contohnya file cartesian product yang dikirim departemen akuntansi saat akhir tahun
  • Saya benar-benar sedang berada di posisi harus bersusah payah menangani CSV model lama seperti ini
  • Hampir di semua kasus HDF5 lebih baik daripada CSV, tetapi selain karena ketidaktahuan, kemalasan, atau alasan 'karena sudah jalan', sulit mencari penjelasan lain
• Saya masuk dengan harapan melihat kode assembly, tetapi ternyata C#, dan itu mengejutkan sekaligus mengesankan; hasil yang keren
  • .NET modern adalah 'bahasa tingkat tinggi' yang paling dalam mengintegrasikan SIMD dan vector intrinsics; Tanner Gooding dari Microsoft mendorong banyak kemajuan di sini, dan tulisan blog terkait juga sangat bagus
• Agak membingungkan bahwa di teks utama tidak didefinisikan dengan jelas apa tepatnya yang dilakukan kode 21GB/s itu; misalnya, format parsingnya secara spesifik seperti apa (misalnya penanganan quote pada CSV), dan setelah parsing hasilnya dipakai bagaimana (apakah dimasukkan ke struktur data, dll.) juga tidak jelas
  • Perhitungan ns/row di artikel itu sekitar 27ns/row (sekitar 37.000 row per detik), jadi kalau memang 21GB/s berarti ukurannya sekitar 570KB per row, dan itu terasa seperti benchmark yang sangat tidak wajar
• Dalam pengalaman saya, sulit mendapatkan keuntungan besar dari kode SIMD kustom dibanding auto-vectorization compiler modern (terutama pada kode yang ramah vektor), walau untuk kasus khusus seperti parsing JSON memang agak berbeda
• Baru-baru ini saya mengerjakan ekstrak CSV 300GB, dan terlalu banyak waktu terbuang untuk manipulasi dan verifikasi integritas, jadi parser CSV cepat seperti ini benar-benar sangat dibutuhkan
  • Saya tidak mengerti kenapa tidak memakai format yang dikhususkan untuk menyimpan data floating-point; HDF5 adalah alternatif yang jauh lebih baik