- Perbandingan penggunaan memori antara async dan multithread dalam Rust, Go, Java, C#, Python, Node.js, dan Elixir
- Menulis program di tiap bahasa (dengan bantuan ChatGPT) yang menjalankan N task yang menunggu selama 10 detik
- Perbandingan dilakukan di Xeon E3 + Ubuntu 22.04
Hasil
- Jejak memori minimum (eksperimen dengan hanya 1 task): Go dan Rust hanya membutuhkan kurang dari 3MB, Python 17MB, Java/Node.js sekitar 40MB, C# 131MB
- 10 ribu task: Rust Tokio 4.6MB, Rust async-std 8MB, Go 28.6MB, Python 40MB, Rust Threads 48MB, Node.js 48MB, Java Virtual Thread 78MB, Elixir 99MB, C# 131MB, Java Threads 244MB
- 100 ribu task (tanpa thread): Rust tokio 23MB, Rust Async-std 54MB, Node.js 112MB, C# 130MB, Java virtual threads 223 MB, Python 240MB, Go 269MB, Elixir 445MB
- 1 juta task: Rust Tokio 213MB, C# 461MB, Node.js 494MB, Rust async-std 527MB, Java virtual thread 1154MB, Python 2232MB, Go 2658MB, Elixir 4009MB
Kesimpulan
- Rust tokio benar-benar tidak tertandingi
- C# memiliki jejak memori besar, tetapi sangat kompetitif (bahkan kadang mengungguli Rust)
- Saat naik ke 1 juta, Go makin tertinggal dari Java virtual threads (membalik anggapan umum bahwa Go lebih ringan daripada JVM)
- Yang dilihat hanya penggunaan memori, faktor lain tidak dipertimbangkan
- Pada 1 juta task, overhead untuk memulai pekerjaan menjadi besar, dan sebagian besar kode butuh lebih dari 12 detik untuk selesai
- Benchmark lain juga direncanakan
9 komentar
Ini benchmark yang cukup bermakna kalau Anda memakai Go sambil terus melirik Rust, dan bertanya-tanya apakah benar perlu beradaptasi dengan sintaks yang serba ketat ini. Jika dalam situasi di mana Go mati karena OOM Rust justru masih mampu bertahan dengan baik.... rasanya cukup layak untuk diinvestasikan.
Tentu saja, masalah bahwa mencari developer Rust jauh lebih sulit masih tetap ada...
Memang benar bahwa Go memiliki struktur yang mengalokasikan satu stack (2KB) untuk setiap goroutine, sehingga penggunaan meningkat sebesar O(n) dan menjadi kurang menguntungkan seiring bertambahnya jumlah thread....
Hal yang agak membuat penasaran adalah, seberapa sering sebenarnya ada situasi yang melampaui 10 ribu thread? Rasanya context switching akan terjadi lebih sering daripada kode sebenarnya berjalan....
Saya penasaran bagaimana dengan coroutine Kotlin.
Hasil Elixir yang paling mengejutkan; saya tahu Erlang menghabiskan memori hanya pada tingkat beberapa ratus word yang bahkan lebih ringan daripada Go, tetapi...
Saya melihat dokumentasi resmi Erlang, dan tertulis bahwa untuk melakukan spawn satu proses Erlang dibutuhkan 338 word. Lalu, jika 1 word pada sistem 64-bit adalah 8 byte, berarti satu proses Erlang memakan memori sekitar 2,7KB (338 × 8 = 2.704). Di bahasa Go, ukuran satu stack goroutine sekitar 2,0KB, jadi tampaknya sisi Erlang memang menggunakan memori lebih banyak.
Kalau begitu, dengan perhitungan sederhana, 1 juta proses Erlang seharusnya memakai memori 2,7GB. Namun, pada benchmark Elixir yang diperkenalkan di atas, penggunaan memori maksimum yang teramati sekitar 4,0GB, jadi ada tambahan 1,3GB memori yang terpakai. Jika dihitung sederhana, ini berarti dalam skenario tersebut ada tambahan sekitar 1,3KB memori per proses Erlang. Saya tidak begitu yakin, tetapi mungkin ketika jumlah proses Erlang bertambah melewati batas tertentu, runtime memerlukan penggunaan ruang memori tambahan semacam itu.
Saya menduga mungkin karena memesan kapasitas untuk peta pohon supervision atau message queue.
Saya rasa Rust benar-benar bahasa yang luar biasa, dari paradigma hingga performa.
Perbandingan antara pendekatan asinkron dan thread, ditambah benchmark yang juga melibatkan runtime bahasa, bisa keliru tergantung sudut pandang, jadi lihatlah sebagai referensi saja.
Lihat juga komentar di HN. https://news.ycombinator.com/item?id=36024209