Apakah arsitektur CPU bias terhadap runtime prosedural?

Apakah ada perubahan yang dapat dilakukan pada CPU untuk membuatnya berkinerja lebih baik untuk runtime bersamaan seperti Rust? Misalnya, apakah ada perubahan pada implementasi prediksi cabang atau ukuran cache yang akan membantu runtime bersamaan?

Saya memiliki kesan bahwa desain CPU saat ini mungkin lebih dioptimalkan untuk runtime prosedural seperti C. Jika kita malah akan mengoptimalkan untuk runtimes bersamaan, bagaimana CPU terlihat berbeda?

Untuk isntance, prediksi cabang diimplementasikan berdasarkan generalisasi yang diambil dalam makalah penelitian menganalisis kode prosedural. Saya bertanya-tanya apakah abstraksi konkurensi akan menambah set-kerja yang signifikan ke runtime yang berdampak buruk pada algoritma prediksi cabang yang ada. Sebagai contoh, memprediksi dalam loop for adalah satu hal, tetapi ketika target cabang selalu beberapa bagian baru dari memori (grafik, teks, dll), itu akan selalu menjadi cache miss, dan tidak akan pernah ada cabang sejarah untuk itu - karena belum menyentuhnya.

Ini mungkin pertanyaan konyol karena isinya, meskipun mungkin selalu dalam RAM, akan bercabang ke urutan lebih kecil dari yang akan digunakan (setelah itu dimuat ke cache) ... tapi tetap saja, ada harus menjadi batas temporal yang dapat diamati pada konteks yang disimpan dalam cache dan prediktor cabang dalam runtime prosedural, yang akan dimanifestasikan sebagai batas abstraksi dalam lingkungan yang lebih paralel. Jadi saya bertanya-tanya ... Apakah batas-batas ini telah diamati? Apakah ada makalah penelitian yang menganalisis ini?

Apakah arsitektur CPU bias terhadap kode prosedural dibandingkan kode konkuren; atau apakah CPU modern cukup bertujuan umum sehingga bahasa yang sangat konkuren tidak menderita?

Mungkin lebih banyak kasus bahwa arsitektur komputer modern dirancang dengan tujuan meningkatkan kualitas kode yang dihasilkan oleh kompiler terhadap anggaran biaya di daerah mati dan daya yang digunakan. Pustaka Runtime hanyalah contoh spesifik dari kode yang dikompilasi yang perlu dieksekusi secara efisien.

Untuk waktu yang sangat lama, bahasa target untuk sebagian besar arsitektur adalah bahasa "C". Ini mencerminkan tuntutan sederhana bahwa bahasa dibuat pada perangkat kerasnya dan fakta bahwa bahasa tersebut telah menjadi bahasa pemrograman sistem yang hampir universal (Sorry Rust and Go, Anda harus menempuh jalan yang jauh untuk mengalahkan C).

Konsekuensi dari hal ini adalah bahwa bahasa baru sering didefinisikan dalam istilah semantik ekuivalen C mereka hanya agar mereka tidak perlu memerlukan fasilitas prosesor yang cenderung tidak ada pada komputer saat ini.

Imbalan untuk prosesor yang cocok dengan kompiler modern adalah bahwa kode dari kompiler tersebut berjalan dengan baik dan prosesor setidaknya memiliki peluang untuk bersaing. Biaya kegagalan di sini menghancurkan prosesor sebelum dapat dimulai. Hanya dua contoh di negatif termasuk iAPX-432 dan Itanium, keduanya oleh Intel. Keduanya memiliki hubungan yang sangat buruk dengan kompiler mereka (Ada dan C masing-masing) dengan kegagalan produk berubah menjadi permainan menyalahkan antara silikon dan perangkat lunak.

Tanpa ragu, ya.

Secara khusus, model komunikasi yang tersirat oleh C99 adalah memori bersama. Bahasa konkuren yang lebih maju memiliki model komunikasi yang lebih kaya, seperti saluran lewat pesan (seperti pada Rust).

Arsitektur CPU modern memang memiliki dukungan perangkat keras eksplisit untuk memori bersama. Secara khusus, protokol koherensi cache seperti MESI diimplementasikan di gerbang dan kabel yang sebenarnya. Tidak ada dukungan nyata untuk pengiriman pesan antar proses, meskipun gagasan pengiriman pesan tidak asing dengan CPU. Bus PCI-e modern bahkan meniru memori bersama menggunakan passing pesan, sedangkan proses CPU harus mengemulasi passing pesan menggunakan memori bersama!