Penanda aras terkini telah mendedahkan jurang prestasi yang mengejutkan antara OpenBSD dan Linux semasa mencipta socket rangkaian dalam aplikasi berbilang benang. Ujian ini, yang melibatkan dua benang yang masing-masing mencipta 256 socket TCP, menunjukkan OpenBSD menyelesaikan tugas dalam kira-kira 2-6 milisaat manakala Linux mengambil masa 17-26 milisaat - perbezaan prestasi sehingga 10 kali lebih pantas.
Keputusan Perbandingan Prestasi:
- Prestasi Linux : 17-26 milisaat (0.017770s - 0.026309s)
- Prestasi OpenBSD : 2-6 milisaat (0.002326s - 0.006096s)
- Perbezaan Kelajuan: Sehingga 10 kali ganda lebih pantas pada OpenBSD
- Senario Ujian: 2 thread masing-masing mencipta 256 soket TCP (512 jumlah file descriptor)
Punca Utama: Pengembangan Jadual Deskriptor Fail
Perbezaan prestasi ini berpunca daripada cara setiap sistem pengendalian mengendalikan pengembangan jadual deskriptor fail apabila berbilang benang terlibat. Dalam Linux, jadual deskriptor fail bermula dengan 256 slot secara lalai. Apabila dua benang mencipta 256 socket setiap satu (berjumlah 512 deskriptor fail), sistem mesti mengembangkan jadual ini pada pertengahan proses.
Semasa pengembangan ini, kernel Linux memeriksa sama ada berbilang benang berkongsi jadual deskriptor fail yang sama. Apabila ia mengesan akses berkongsi (seperti yang ditunjukkan oleh kiraan rujukan yang lebih besar daripada 1), ia memanggil fungsi yang dipanggil synchronize_rcu() untuk memastikan keselamatan benang. Fungsi ini menunggu tempoh rahmat RCU penuh untuk selesai, yang boleh mengambil masa beberapa milisaat dan mewujudkan kesesakan prestasi yang diperhatikan.
RCU (Read-Copy-Update) adalah kaedah sinkronisasi yang membolehkan berbilang benang membaca data dengan selamat manakala satu benang mengemas kininya, tetapi memerlukan tempoh menunggu untuk memastikan semua pembaca telah selesai.
Butiran Teknikal:
- Saiz Jadual FD Lalai Linux : 256 slot
- Pencetus Kesesakan: Pengembangan jadual deskriptor fail apabila kiraan rujukan > 1
- Kaedah Penyegerakan Linux : RCU (Read-Copy-Update) dengan panggilan
synchronize_rcu() - Kaedah Penyegerakan OpenBSD : Kunci baca-tulis tradisional
- Penyelesaian Sementara: Pra-kembangkan jadual FD menggunakan
dup2(0, 666)sebelum penciptaan thread
Pendekatan Yang Lebih Mudah Oleh OpenBSD
OpenBSD mengambil pendekatan yang berbeza sama sekali. Daripada menggunakan sinkronisasi RCU, ia bergantung pada kunci baca-tulis tradisional semasa mengubah suai jadual deskriptor fail. Kaedah ini mengelakkan kelewatan sinkronisasi yang panjang yang melanda Linux dalam senario khusus ini, menghasilkan masa penciptaan socket yang lebih pantas.
Penanda aras juga menunjukkan penyelesaian untuk isu Linux. Dengan pra-mengembangkan jadual deskriptor fail menggunakan dup2(0, 666) sebelum mencipta benang tambahan, penalti prestasi hilang kerana jadual tidak lagi memerlukan pengembangan semasa penciptaan socket.
Pandangan Komuniti dan Implikasi Yang Lebih Luas
Penemuan ini telah mencetuskan perbincangan menarik tentang pertukaran reka bentuk sistem pengendalian. Walaupun penanda aras ini menunjukkan kelebihan OpenBSD dalam senario khusus, ahli komuniti menyatakan bahawa Linux secara amnya mengatasi OpenBSD dalam kebanyakan beban kerja lain dengan margin yang ketara. Sistem RCU yang menyebabkan kelembapan khusus ini sebenarnya memberikan faedah dalam banyak situasi lain.
Tajuk yang lebih baik: program ujian patologi yang dimaksudkan untuk Linux tidak mencetuskan tingkah laku patologi pada OpenBSD
Penanda aras ini menyerlahkan bagaimana keputusan reka bentuk kernel yang berbeza boleh mewujudkan ciri prestasi yang tidak dijangka. Walaupun pendekatan RCU Linux menawarkan kelebihan dalam banyak senario, ia boleh mewujudkan kesesakan dalam kes tepi khusus seperti peruntukan deskriptor fail pantas dalam program berbilang benang.
Penemuan ini berfungsi sebagai peringatan bahawa prestasi sistem pengendalian sangat bergantung kepada beban kerja, dan penanda aras mudah boleh mendedahkan perbezaan seni bina yang menarik antara sistem yang mungkin tidak disedari sebaliknya.
Rujukan: Is OpenBSD 10x faster than Linux?