Kapan mesin tugas paralel menjadi solusi yang baik?

Saya sering tergoda untuk memecahkan permainan yang sedang saya kerjakan untuk mencoba arsitektur berbasis tugas paralel, tapi itu sepertinya bukan persyaratan besar untuk proyek saya jadi saya menghindari ini untuk saat ini. Saya berencana untuk mencobanya di proyek mainan terlebih dahulu, untuk "bermain dengan konsep."

Sekarang, yang saya tanyakan adalah, karena banyak game (non AAA) tidak membutuhkan kinerja yang sangat tinggi, rasanya seperti menggunakan mesin berbasis tugas tidak perlu repot sampai ... kasus apa?

Saat ini, saya hanya menebak bahwa itu perlu ketika Anda benar-benar perlu mengeksploitasi kinerja maksimal perangkat keras (multi-core). Apakah ada kasus lain di mana itu ide yang baik untuk menggunakan mesin berbasis tugas? Atau mungkin, untuk proyek baru, selalu baik untuk memulai dengan mesin berbasis tugas?

multithreading

— Klaim
sumber

Jawaban:

Threading digunakan dalam dua situasi:

Ketika Anda memiliki pekerjaan berat untuk dilakukan tetapi perlu respons pengguna untuk dipertahankan.
Ketika Anda membutuhkan kekuatan lebih dari satu inti pemrosesan pada platform favorit Anda / persyaratan minimum.

Jika Anda dapat mengharapkan salah satu atau kedua hal ini secara wajar, maka lakukanlah. Lain, jangan. Tentu saja, tidak ada yang akan menghentikan Anda dari threading untuk bersenang-senang karena Anda bisa, atau mencari-cari dan menyelidikinya, tetapi dalam hal melakukan threadng untuk mendapatkan manfaat sebenarnya dari mendapatkan aplikasi multi-threaded, maka kedua use case di atas adalah cukup banyak.

— DeadMG
sumber

+1 untuk responsif: salah satu persyaratan untuk proyek utama saya adalah tidak memiliki layar pemuatan, pengalaman yang berkelanjutan untuk perendaman maksimum. Itu poin yang bagus.

— Klaim

+1 persis mengapa saya menggunakan banyak utas dalam permainan puzzle: pekerjaan berat (memeriksa jutaan kombinasi) tanpa membekukan UI.

— ashes999

"tanpa memuat layar, pengalaman terus menerus" - Anda harus membangun seluruh arsitektur Anda di sekitar ide ini, ini adalah istirahat dari "memuat satu tingkat dan bermain di dalamnya, kemudian memuat desain tingkat lain" yang digunakan sebagian besar mesin kecil.

— Patrick Hughes

Jika gim Anda akan menjadi perangkat keras jarak jauh maka Anda perlu utas untuk mengatasi semua perangkat keras modern; CPU di masa depan yang akan keluar dalam satu atau dua tahun mendatang mulai membuat 4 core menjadi minimum dan hingga 16 core umum untuk pasar penggemar / kinerja. Jika Anda melakukan multi-threading sama sekali, pasti lakukan arsitektur berorientasi tugas karena model threading lainnya secara inheren rusak untuk mesin game yang berpandangan ke depan.

Sekarang perlu diingat bahwa dengan "tugas" yang saya maksud "pekerjaan" dan bukan "utas terpisah untuk subsistem mesin yang berbeda." Anda benar-benar benar-benar tidak ingin melakukan sesuatu seperti memiliki satu utas grafik, satu utas fisika, satu utas AI, dll. Itu tidak berskala di luar segelintir inti dan itu sebenarnya tidak memberi Anda paralelisme nyata. Fisika seharusnya tidak menjalankan lebih dari satu pembaruan per pembaruan AI (Anda ingin AI Anda dapat bereaksi terhadap peristiwa fisika), dan grafik hampir tidak ada yang baru untuk dirender jika fisika tidak berjalan, sehingga setiap subsistem secara alami berjalan secara berurutan memesan. Kamu tidak

Yang Anda inginkan adalah melakukan ini. Buat spool utas. Jalankan putaran game Anda dengan urutan klasik pembaruan subsistem. Namun, untuk masing-masing subsistem, pisahkan beban kerja menjadi kumpulan terpisah yang berbeda, dan distribusikan ke kumpulan benang. Tunggu semua pekerjaan diselesaikan sebelum menjalankan status berikutnya dari loop pembaruan game. Beberapa subsistem mungkin memiliki beberapa subtasi; misalnya, gambar dapat mengeluarkan serangkaian pekerjaan untuk melakukan pemusnahan dan kemudian seri kedua pekerjaan untuk melakukan pembuatan antrian. Pendekatan ini menghindari masalah sinkronisasi dari pendekatan pertama, menskala ke jumlah core yang jauh lebih besar, dan terus terang hanya lebih mudah untuk kode, debug, dan pemeliharaan.

— Sean Middleditch
sumber

Terima kasih atas sarannya tentang cara membangun mesin seperti ini, tetapi saya sudah mendokumentasikannya dengan baik sehingga tidak perlu. Ini lebih merupakan pertanyaan "kapan itu sepadan" yang saya tanyakan. Saya pikir itu masih hal yang baik untuk mengarahkan informasi tersebut untuk mereka yang tidak tahu jadi jangan hapus mereka :)

— Klaim

Kedengarannya sangat masuk akal

— Den

Sama seperti Apple, setelah Anda terbiasa dengan pekerjaan, tidak ada jalan untuk kembali =) Ini adalah saran arsitektur yang bagus untuk setiap mesin baru.

— Patrick Hughes

@SeanMiddleditch Bukankah Anda hanya mengubah granularity dari threading seperti itu? Alih-alih hanya thread per sistem (yang memang tidak scalable, beberapa sistem jauh lebih haus daya daripada yang lain dan ada juga lebih banyak sistem yang tersedia core) yang Anda lakukan berpotensi beberapa thread per sistem. Jadi, Anda menyetel rincian data dari setiap utas. Tidak yakin bagaimana ini akan berjalan, tetapi saya tidak punya yang lebih baik untuk ditambahkan. Apakah Anda masih memegang pendapat ini setelah 7 tahun? Terima kasih.

— Nikos

@ Nik-Lz: tidak, karena "multiple threads per system" menyiratkan bahwa Anda tahu seperti apa thread-per-sistem itu. Haruskah Anda memiliki 2 utas untuk rendering dan 3 untuk fisika? Berapa banyak untuk AI? Bukankah itu semua tergantung pada adegan spesifik dan bahkan di mana dalam adegan itu pemain melihat dan apa yang terjadi pada saat itu? Suatu sistem pekerjaan dengan mudah secara dinamis mengukur kebutuhan yang mendesak daripada membuang seluruh utas ke subsistem yang mungkin tidak membutuhkannya saat ini.

— Sean Middleditch

ada dua kegunaan dalam multithreading, satu untuk meningkatkan kinerja program Anda dan yang lainnya adalah membiarkan program berjalan ketika ada proses besar yang sedang berlangsung. misalnya ketika Anda mencoba memuat beberapa data, itu mengganggu jika program Anda ditutup, jadi Anda dapat menggunakan utas lainnya untuk memuat dan menjaga utas utama bebas untuk melanjutkan loop utama. meningkatkan kinerja menggunakan utas adalah hal yang sangat sulit. karena biasanya Anda melakukan segala sesuatu dalam proses linear dan itu adalah sesuatu yang berbeda dengan pemrosesan paralel. dan Anda selalu harus menggunakan utas utama Anda untuk pembaruan perangkat grafis yang membuatnya semakin sulit untuk membagi tugas di antara utas.

— Ali1S232
sumber

Threading tidak sulit. :) Itu hanya sesuatu yang banyak orang tidak pernah belajar untuk melakukannya dengan benar, jadi mereka pikir itu sulit karena kurang pengalaman. Khususnya dalam gim banyak algoritma dan struktur data inti cukup mudah untuk ditangani dengan banyak utas. Pembaruan fisika misalnya dapat dipecah menjadi pulau-pulau objek, dan masing-masing diarahkan ke utas berbeda untuk integrasi dan resolusi. Demikian juga, pemusnahan objek untuk grafis hampir sepenuhnya bebas dari pertengkaran akses data baca-tulis.

— Sean Middleditch

@ seanmiddleditch Saya tidak mengatakan menggunakan utas itu sendiri adalah hal yang sulit tetapi mengelola untuk menggunakan utas secara efektif dan menyeimbangkannya untuk berbagi beban yang sama adalah sesuatu yang sulit.

— Ali1S232