Berapa Banyak Memori yang Dibutuhkan pada 2024 untuk Menjalankan 1 Juta Tugas Konkuren?

Kami menjalankan program yang memproses 1 juta tugas konkuren menggunakan versi terbaru Rust, C#, Python, Go, Java, dan NodeJS untuk membandingkan efisiensi memorinya.

C# (NativeAOT) dan Rust menunjukkan efisiensi memori terbaik, sementara Go mendapat penilaian rendah karena konsumsi memorinya lebih tinggi dari perkiraan. Secara keseluruhan, performa .NET dan Rust menonjol, dan Java (GraalVM) menunjukkan peningkatan yang mengejutkan.

Secara spesifik, Rust menggunakan memori paling sedikit, sekitar 29MB, disusul C# NativeAOT sekitar 71MB. NodeJS mencatat 232MB, Python 339MB. Go menunjukkan hasil yang kurang memuaskan dengan penggunaan memori yang relatif tinggi, yaitu 753MB. Java (GraalVM) menunjukkan peningkatan besar dengan 92MB.

[kroisse]

Melihat kode benchmark-nya, untuk Rust dan Python tampaknya yang sebenarnya dibuat bukanlah concurrent task, melainkan hanya objek future yang bersifat asinkron tetapi tidak dapat berjalan paralel dengan task lain. Mungkin C# juga kasusnya mirip. Sebaliknya, kode Go membuat goroutine, yaitu task yang memiliki call stack sendiri dan sebagainya, jadi kemungkinan penyebab penggunaan memori Go terlihat sangat menonjol pada kasus 1 juta adalah hal ini.

[bungker]

Sebagai pembelaan untuk Go, Go tetap berjalan meskipun ada library apa pun di dalam fungsi yang berjalan 1 juta buah. Tinggal tambahkan go saja. Di bahasa lain yang berbasis asinkron, kalau di tengah ada library yang sedikit saja memakan waktu dengan cara sinkron, keuntungannya sebagai sistem asinkron bisa habis semua dan situasinya jadi sangat kacau.
Untuk benar-benar menikmati 100% keuntungan asinkron, semua fungsi yang memakan waktu meski sedikit pun harus diubah menjadi asinkron.
Java VirtualThread, hmm... kali ini di perusahaan kami sempat mencoba mengandalkan Java VirtualThread, tetapi karena masalah kompatibilitas library, akhirnya kami kembali ke thread biasa dan berakhir dengan menyalakan puluhan instance.

[roxie]

Bisa dijelaskan sedikit lebih lanjut tentang bagian kompatibilitasnya? :eyes:

[secret3056]

Bisa dibilang, tidak lagi tepat ada anggapan yang sering terdengar di Spring bahwa "untuk benar-benar menggunakan WebFlux dengan semestinya, Anda harus memakainya bersama R2DBC alih-alih JPA agar keunggulannya benar-benar terlihat".

[bungker]

Saya mendengar bahwa pustaka msal milik MS tidak berjalan di virtual thread.

[vwjdalsgkv]

Menurut saya, untuk contoh library msal yang Anda berikan, kasusnya akan sama juga di Go jika library tersebut menggunakan tipe data atau struktur yang tidak thread-safe.

[riki3]

Apa kaitannya dengan thread safety? Sejak awal goroutine bukanlah sistem yang menjamin thread safety, bukan?

[hookim]

Terima kasih atas informasinya

Saya ada pertanyaan
Kalau begitu, apakah bahasa lain selain Go akan bermasalah semuanya seperti yang Anda jelaskan jika ada library dengan cara kerja sinkron?
Atau, saya juga penasaran apakah di antara bahasa-bahasa lain ada yang seperti Go, yaitu mendukung asynchronous yang benar-benar sempurna?

[riki3]

Ada istilah colorless. Go adalah satu-satunya bahasa yang tidak perlu membedakan antara asinkron dan sinkron. Dari sudut pandang pengguna, saat melakukan pemrograman yang membutuhkan konkurensi, Go memiliki keunggulan yang sangat besar dari sisi tingkat kesulitan dan kemudahan penggunaan.
Meski dari segi performa mungkin sedikit kalah dibanding pemrograman asinkron yang dioptimalkan.

[bungker]

Maaf mengoreksi, tapi saya hanya ingin menyampaikan bagian yang keliru dari ungkapan "rusak" dan "asinkron yang sempurna". Dalam asinkron pun tidak masalah memakai library bergaya sinkron, asalkan ada jaminan bahwa ia selesai dalam waktu singkat. Masalah muncul jika ada pemanggilan bergaya sinkron dengan waktu eksekusi panjang, karena itu akan menunda pemrosesan asinkron lainnya. Di Go, karena pekerjaan dalam jumlah ratusan juta pun bisa dialokasikan dengan goroutine, tidak ada konsep asinkron pada level bahasa itu sendiri. Dari sudut pandang pengguna, ini sangat nyaman karena fungsi apa pun bisa dijalankan paralel cukup dengan memanggilnya sambil menambahkan go. Secara pribadi saya merasa bahwa "asinkron yang sempurna" mungkin justru adalah JavaScript, karena fondasi bahasanya sendiri memang asinkron.