Mengapa paralelisme / konkurensi implisit tidak lebih luas? [Tutup]

13

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 4 tahun yang lalu .

Paralelisme implisit ^ dapat mengambil beban besar dari banyak programmer, menempatkannya di komputer. Jadi ... mengapa saat ini tidak lebih luas?

^ Paralelisme implisit adalah membuat komputer dapat mengetahui sendiri bagaimana melakukan lebih dari satu hal pada satu waktu, alih-alih seorang programmer yang perlu melakukan pekerjaan ini menggunakan utas dan sejenisnya.

concurrency parallelism

— Abbafei
sumber

Lihat bahasa pemrograman parasail, mereka tampaknya menjadi satu-satunya yang mencoba paralelisme implisit forge.open-do.org/plugins/moinmoin/parasail

11

Karena dengan beberapa pengecualian (Haskell) tidak mungkin kompiler dapat membuka bungkusan. Masalahnya adalah bahwa setiap iterasi melalui loop dapat mengubah status global. Jadi melakukannya dengan urutan yang berbeda dapat menyebabkan kerusakan. Dalam haskell, Anda dapat mengandalkan fungsi yang murni, yang artinya tidak membaca atau mengubah keadaan global, sehingga mereka dapat dieksekusi dalam urutan apa pun.

Masalah sebenarnya adalah bahwa dengan beberapa pengecualian bagaimana melakukan konkurensi dengan baik masih merupakan masalah terbuka. Komunitas Erlang dan Haskell tampaknya berjalan cukup baik tetapi masih jauh sebelum kita benar-benar mengerti bagaimana memprogram sistem N-core untuk N. besar.

— Zachary K
sumber

1

Dalam Skema, ada beberapa loop yang secara eksplisit memilih untuk tidak menjamin pesanan.

— Javier

Keren saya tidak tidak tahu tentang skema

— Zachary K

5

Sebagian besar bahasa pemrograman yang kami gunakan sekarang datang pada saat di mana pemrograman berulir tunggal dan interaksi pengguna tunggal adalah yang paling banyak digunakan untuk banyak aplikasi (mis: aplikasi desktop yang berdiri sendiri). Dengan meningkatnya aplikasi web, komputasi awan dan aplikasi multi-pengguna sekarang kita membutuhkan lebih banyak aplikasi multi-ulir.

Bahasa pemrograman lawas mencoba untuk mendukung fitur multi-threaded dari bahasa itu sendiri secara perlahan (Seperti java menambahkan java.util.concurrent).

Bahasa baru yang akan datang di masa depan akan lebih baik dalam membangun threading dan dukungan konkurensi.

— Dhanunjai
sumber

4

Terlepas dari poin yang disebutkan dalam jawaban lain (sulit untuk membuktikan bahwa operasi adalah independen, dan programmer berpikir secara seri), ada faktor ketiga yang perlu dipertimbangkan: biaya paralelisasi.

Yang benar adalah, paralelisme utas itu memiliki biaya yang sangat signifikan terkait dengannya:

Pembuatan utas sangat mahal: Untuk Kernel, memulai utas hampir sama dengan memulai suatu proses. Saya tidak yakin tentang biaya yang tepat, tetapi saya percaya itu dalam urutan sepuluh mikrodetik.
Komunikasi utas melalui mutex itu mahal: Biasanya, ini membutuhkan panggilan sistem di setiap sisi, mungkin menempatkan utas untuk tidur dan membangunkannya lagi, yang menghasilkan latensi serta cache dingin dan TLB yang memerah. Rata-rata, mengambil dan melepaskan biaya mutex sekitar satu mikrodetik.

Sejauh ini baik. Mengapa ini masalah paralelisme implisit? Karena paralelisme implisit paling mudah untuk dibuktikan pada skala kecil. Ini adalah satu hal untuk membuktikan bahwa dua iterasi dari loop sederhana adalah independen satu sama lain, itu adalah hal yang sama sekali berbeda untuk membuktikan bahwa mencetak sesuatu ke stdoutdan mengirim permintaan ke database independen satu sama lain dan dapat dieksekusi secara paralel ( proses database bisa di sisi lain dari pipa!).

Artinya, paralelisme implisit yang dapat dibuktikan program komputer kemungkinan tidak dapat dieksploitasi karena biaya paralelisasi lebih besar daripada keuntungan pemrosesan paralel. Di sisi lain, paralelisme skala besar yang benar-benar dapat mempercepat aplikasi tidak dapat dibuktikan untuk kompiler. Coba pikirkan berapa banyak pekerjaan yang dapat dilakukan CPU dalam mikrodetik. Sekarang, jika paralelisasi seharusnya lebih cepat daripada program serial, program paralel harus dapat membuat semua CPU sibuk selama beberapa mikrodetik antara dua panggilan mutex. Itu membutuhkan paralelisme berbutir kasar, yang hampir tidak mungkin dibuktikan secara otomatis.

Akhirnya, tidak ada aturan tanpa pengecualian: Eksploitasi paralelisme implisit bekerja di mana tidak ada utas yang terlibat, yang merupakan kasus dengan vektorisasi kode (menggunakan set instruksi SIMD seperti AVX, Altivec, dll.). Itu memang bekerja paling baik untuk paralelisme skala kecil yang relatif mudah dibuktikan.

— cmaster - mengembalikan monica
sumber

0

Pemrogram berpikir secara serial, dan bahasa saat ini dibangun untuk mendukung model itu. Dengan perkecualian bahasa pinggiran seperti Haskell Erlang dll, bahasa (saya tidak menggunakan kata sifat "modern") pada dasarnya adalah perakitan tingkat tinggi di mana kami masih memberi tahu komputer apa yang harus dilakukan, kapan melakukannya, dan bagaimana melakukannya. Sampai kita memiliki sistem-echo di mana kita memberi tahu komputer apa hasil yang kita inginkan tersedia, kita tidak memiliki kapasitas mental, sebagai programmer, untuk memanfaatkan sepenuhnya kemampuan multithreading.

yaitu tidak alami ......

— mattnz
sumber

Pemrogram berpikir bagaimana mereka diajarkan untuk berpikir, sama seperti mereka memprogram dalam cara bahasa pemrograman mereka mendorong mereka untuk memprogram. Jika seorang programmer tidak mengekspos diri mereka sendiri ke apa yang disebut bahasa pinggiran Anda , mereka tidak akan pernah belajar bahwa ada cara lain untuk berpikir tentang masalah. Saya pikir inilah sebabnya mengapa Tujuh Bahasa dalam Tujuh Minggu termasuk dalam daftar yang direkomendasikan banyak orang.

— Mark Booth

Pinggiran Perhap adalah kata yang salah - maksud saya bahasa tidak banyak digunakan dalam aplikasi komersial (yaitu bukan C ++ atau Java).

— mattnz

1

Namun saya mendukung pernyataan saya (dengan pendapat saya sendiri untuk mendukungnya), bahwa programmer, sebagai manusia, tidak memiliki kemampuan logam untuk benar-benar "mendapatkan" multithreading dan parrallisum besar-besaran. Bukan sifat manusia untuk melakukan lebih dari satu tugas pada saat bersamaan. Setiap buku tentang manajemen waktu penting mempromosikan konsep memulai sesuatu, selesaikan kemudian lakukan hal berikutnya, karena itulah cara kita terhubung. Untuk menggunakan paradigma ini secara efisien dan efektif, kita membutuhkan dukungan alat besar, yang saat ini tidak tersedia. Sedikit yang "mendapatkannya", dan perlu mengembangkan alat-alat ini.

— mattnz

1

Saya pikir don't have the patienceini penilaian yang lebih akurat don't have the mental capacity. Selama karier saya, saya telah melihat lebih banyak programmer yang malas daripada yang pernah saya lihat yang bodoh . Namun saya beruntung, saya diajari pemrograman fungsional dan pemrograman paralel berbutir halus di sisi prosedural dan OO, pada tahun pertama saya di universitas. Saya curiga banyak programmer yang tidak seberuntung itu dan proses pemikiran mereka telah dibalut secara langsung.

— Mark Booth

0

Transaksi harus ACID, jadi, programmer terutama cenderung memikirkan satu utas.

Bahasa dan platform harus melindungi programmer dari konkurensi sebanyak yang mereka mampu

Dan concurrency tidak semudah menguji sebagai funcionality itu sendiri, sehingga programmer cenderung meninggalkan selain masalah ini dan, bahkan, tidak berpikir tentang melakukan concurrency handling, apa itu kesalahan

— Daftar Sugra
sumber