Secara teknis, mengapa proses di Erlang lebih efisien daripada thread OS?

Karakteristik Erlang

Dari Erlang Programming (2009):

Konkurensi erlang cepat dan terukur. Prosesnya ringan karena mesin virtual Erlang tidak membuat utas OS untuk setiap proses yang dibuat. Mereka dibuat, dijadwalkan, dan ditangani dalam VM, independen dari sistem operasi yang mendasarinya. Akibatnya, waktu pembuatan proses adalah urutan mikrodetik dan independen dari jumlah proses yang ada secara bersamaan. Bandingkan ini dengan Java dan C #, di mana untuk setiap proses thread OS yang mendasarinya dibuat: Anda akan mendapatkan beberapa perbandingan yang sangat kompetitif, dengan Erlang mengungguli kedua bahasa.

Dari pemrograman berorientasi Concurrency di Erlang (pdf) (slide) (2003):

Kami mengamati bahwa waktu yang diperlukan untuk membuat proses Erlang adalah konstan 1μs hingga 2.500 proses; setelah itu meningkat menjadi sekitar 3μs hingga 30.000 proses. Kinerja Java dan C # ditampilkan di bagian atas gambar. Untuk sejumlah kecil proses, dibutuhkan sekitar 300 μs untuk membuat proses. Membuat lebih dari dua ribu proses adalah hal yang mustahil.

Kami melihat bahwa hingga 30.000 proses waktu untuk mengirim pesan antara dua proses Erlang adalah sekitar 0,8 μs. Untuk C # dibutuhkan sekitar 50μs per pesan, hingga jumlah maksimum proses (yaitu sekitar 1800 proses). Java bahkan lebih buruk, untuk hingga 100 proses dibutuhkan sekitar 50 μs per pesan setelah itu meningkat pesat menjadi 10 ms per pesan ketika ada sekitar 1000 proses Java.

Pikiran saya

Saya tidak sepenuhnya mengerti secara teknis mengapa proses Erlang jauh lebih efisien dalam memunculkan proses baru dan memiliki jejak memori yang jauh lebih kecil per proses. Baik OS dan Erlang VM harus melakukan penjadwalan, konteks switch, dan melacak nilai-nilai dalam register dan seterusnya ...

Hanya mengapa thread OS tidak diimplementasikan dengan cara yang sama dengan proses di Erlang? Apakah mereka harus mendukung sesuatu yang lebih? Dan mengapa mereka membutuhkan jejak memori yang lebih besar? Dan mengapa mereka memiliki pemijahan dan komunikasi yang lebih lambat?

Secara teknis, mengapa proses di Erlang lebih efisien daripada utas OS ketika menyangkut pemijahan dan komunikasi? Dan mengapa thread di OS tidak dapat diimplementasikan dan dikelola dengan cara yang efisien? Dan mengapa utas OS memiliki jejak memori yang lebih besar, ditambah pemijahan dan komunikasi yang lebih lambat?

Lebih banyak membaca

• Di dalam Erlang VM dengan fokus pada SMP (2008)
• Concurrency di Jawa dan di Erlang (pdf) (2004)
• Pengukuran Kinerja Thread di Jawa dan Proses di Erlang (1998)

Ada beberapa faktor yang berkontribusi:

1. Proses Erlang bukan proses OS. Mereka diimplementasikan oleh Erlang VM menggunakan model threading kooperatif ringan (preemptive di tingkat Erlang, tetapi di bawah kendali runtime terjadwal kooperatif). Ini berarti bahwa jauh lebih murah untuk beralih konteks, karena mereka hanya beralih pada titik-titik yang diketahui dan dikendalikan dan karenanya tidak perlu menyimpan seluruh keadaan CPU (normal, register SSE dan FPU, pemetaan ruang alamat, dll.).
2. Proses Erlang menggunakan tumpukan yang dialokasikan secara dinamis, yang mulai sangat kecil dan tumbuh seperlunya. Hal ini memungkinkan pemunculan ribuan - bahkan jutaan - proses Erlang tanpa menyedot semua RAM yang tersedia.
3. Erlang digunakan untuk single-threaded, artinya tidak ada persyaratan untuk memastikan keamanan benang di antara proses. Sekarang mendukung SMP, tetapi interaksi antara proses Erlang pada penjadwal / inti yang sama masih sangat ringan (ada antrian run terpisah per core).

Setelah beberapa penelitian lebih lanjut saya menemukan presentasi oleh Joe Armstrong.

Dari Erlang - perangkat lunak untuk dunia bersamaan (presentasi) (pada 13 menit):

[Erlang] adalah bahasa konkuren - maksud saya bahwa utas merupakan bagian dari bahasa pemrograman, mereka bukan milik sistem operasi. Itu benar-benar apa yang salah dengan bahasa pemrograman seperti Java dan C ++. Utasnya tidak ada dalam bahasa pemrograman, utas adalah sesuatu dalam sistem operasi - dan mereka mewarisi semua masalah yang mereka miliki dalam sistem operasi. Salah satu masalah adalah rincian sistem manajemen memori. Manajemen memori dalam sistem operasi melindungi seluruh halaman memori, sehingga ukuran terkecil yang dapat dituju adalah ukuran terkecil dari sebuah halaman. Itu sebenarnya terlalu besar.

Jika Anda menambahkan lebih banyak memori ke mesin Anda - Anda memiliki jumlah bit yang sama yang melindungi memori sehingga granularity dari tabel halaman naik - Anda akhirnya menggunakan mengatakan 64kB untuk proses yang Anda tahu berjalan dalam beberapa ratus byte.

Saya pikir itu menjawab jika tidak semua, setidaknya beberapa pertanyaan saya

Saya telah mengimplementasikan coroutine dalam assembler, dan mengukur kinerja.

Beralih di antara coroutine, alias proses Erlang, membutuhkan sekitar 16 instruksi dan 20 nanodetik pada prosesor modern. Selain itu, Anda sering mengetahui proses yang Anda gunakan (contoh: proses menerima pesan dalam antriannya dapat diimplementasikan sebagai proses langsung dari proses panggilan ke proses penerimaan) sehingga penjadwal tidak ikut berperan, membuat ini merupakan operasi O (1).

Untuk mengganti utas OS, dibutuhkan sekitar 500-1000 nanodetik, karena Anda memanggil kernel. Penjadwal thread OS mungkin berjalan dalam waktu O (log (n)) atau O (log (log))), yang akan mulai terlihat jika Anda memiliki puluhan ribu, atau bahkan jutaan utas.

Oleh karena itu, proses Erlang lebih cepat dan skala lebih baik karena kedua operasi dasar switching lebih cepat, dan penjadwal berjalan lebih jarang.

Proses Erlang berhubungan (kurang-lebih) dengan utas hijau dalam bahasa lain; tidak ada pemisahan yang diberlakukan OS antara proses. (Mungkin ada pemisahan yang ditegakkan oleh bahasa, tapi itu perlindungan yang lebih rendah meskipun Erlang melakukan pekerjaan yang lebih baik daripada kebanyakan.) Karena mereka jauh lebih ringan, mereka dapat digunakan jauh lebih luas.

Utas OS di sisi lain hanya dapat dijadwalkan pada inti CPU yang berbeda, dan (sebagian besar) dapat mendukung pemrosesan terikat CPU yang independen. Proses OS seperti benang OS, tetapi dengan pemisahan yang ditegakkan dengan OS yang jauh lebih kuat. Harga kemampuan ini adalah bahwa utas OS dan (bahkan lebih lagi) proses lebih mahal.

Cara lain untuk memahami perbedaannya adalah ini. Misalkan Anda akan menulis implementasi Erlang di atas JVM (bukan saran yang sangat gila) maka Anda akan membuat setiap proses Erlang menjadi objek dengan beberapa negara. Anda kemudian akan memiliki kumpulan instance Thread (biasanya berukuran sesuai dengan jumlah core dalam sistem host Anda; itu adalah parameter yang dapat ditala dalam runtime Erlang nyata BTW) yang menjalankan proses Erlang. Pada gilirannya, itu akan mendistribusikan pekerjaan yang harus dilakukan di seluruh sumber daya sistem nyata yang tersedia. Ini cara yang cukup rapi dalam melakukan sesuatu, tetapi sangat bergantungpada kenyataan bahwa setiap proses Erlang individu tidak melakukan banyak hal. Tidak apa-apa tentu saja; Erlang disusun untuk tidak mengharuskan proses individu menjadi kelas berat karena merupakan keseluruhan dari mereka yang menjalankan program.

Dalam banyak hal, masalah sebenarnya adalah salah satu terminologi. Hal-hal yang disebut Erlang proses (dan yang sangat sesuai dengan konsep yang sama dalam CSP, CCS, dan khususnya π-kalkulus) sama sekali tidak sama dengan hal-hal yang bahasa-bahasa dengan warisan C (termasuk C ++, Java, C #, dan banyak lainnya) memanggil suatu proses atau utas. Ada beberapa kesamaan (semua melibatkan beberapa gagasan tentang eksekusi bersamaan) tetapi jelas tidak ada kesetaraan. Jadi berhati-hatilah ketika seseorang mengatakan "proses" kepada Anda; mereka mungkin mengerti itu berarti sesuatu yang sangat berbeda ...

Saya pikir Jonas menginginkan beberapa angka untuk membandingkan thread OS dengan proses Erlang. Penulis Pemrograman Erlang, Joe Armstrong, beberapa waktu lalu menguji skalabilitas pemijahan proses Erlang ke thread OS. Dia menulis server web sederhana di Erlang dan mengujinya terhadap multi-threaded Apache (karena Apache menggunakan thread OS). Ada situs web lama dengan data yang berasal dari tahun 1998. Saya hanya berhasil menemukan situs itu sekali saja. Jadi saya tidak bisa menyediakan tautan. Tetapi informasinya ada di luar sana. Poin utama dari penelitian ini menunjukkan bahwa Apache maksimal hanya di bawah proses 8K, sementara server Erlang yang ditulis tangannya menangani proses 10K +.

Karena juru bahasa Erlang hanya perlu khawatir tentang dirinya sendiri, OS memiliki banyak hal lain yang perlu dikhawatirkan.

salah satu alasannya adalah proses erlang dibuat bukan di OS, tetapi di evm (mesin virtual erlang), sehingga biayanya lebih kecil.