Mengapa suatu program membutuhkan jumlah minimum inti CPU?


55

Apakah mungkin untuk menulis kode (atau perangkat lunak lengkap, daripada sepotong kode) yang tidak akan berfungsi dengan baik ketika dijalankan pada CPU yang memiliki jumlah core kurang dari N? Tanpa mengeceknya secara eksplisit dan gagal dengan sengaja:

JIKA (noOfCores <4) MAKA tidak berjalan dengan baik dengan sengaja

Saya melihat persyaratan sistem minimum game ( Dragon Age: Inkuisisi ), dan menyatakan minimum CPU empat inti. Banyak pemain mengatakan itu TIDAK berjalan pada CPU dua-inti dan BAHKAN pada Intel Core i3s dengan dua fisik dan dua inti logis. Dan itu BUKAN masalah daya komputasi.

Dari pemahaman saya, utas sepenuhnya terisolasi dari CPU oleh OS karena itu tidak dapat dilakukan.

Hanya untuk membersihkan:

Saya TIDAK bertanya "Bisakah saya mencari tahu jumlah inti CPU dari kode, dan gagal dengan sengaja?" ... Kode semacam itu akan menjadi niat buruk (memaksa Anda untuk membeli CPU yang lebih mahal untuk menjalankan program - tanpa perlu daya komputasi). Saya meminta kode Anda, katakanlah, memiliki empat utas dan gagal ketika dua utas dijalankan pada inti fisik yang sama (tanpa secara eksplisit memeriksa informasi sistem dan sengaja gagal) .

Singkatnya, dapatkah ada perangkat lunak yang membutuhkan banyak inti, tanpa memerlukan daya komputasi tambahan yang berasal dari banyak inti? Itu hanya akan membutuhkan N inti fisik yang terpisah.


11
Jika Anda membaca pertanyaan saya dengan seksama, Anda akan melihat mereka tidak menanyakan hal yang sama.
uylmz

21
Karena jumlah inti dapat diambil, maka dapat dibandingkan dengan N, dan jika perbandingan itu bernilai true, kode dapat melakukan apa pun yang diinginkannya, termasuk tetapi tidak terbatas pada berperilaku dengan cara yang tidak diiklankan. Apa pertanyaanmu?

3
Apakah Anda yakin masalahnya benar dan langsung terkait dengan jumlah core? Mungkin game yang disebutkan sebagian didasarkan pada fitur saja (benar) yang disediakan oleh CPU dengan setidaknya 4 core?
mgoeminne

25
Perhatikan bahwa "persyaratan sistem minimum" sering "persyaratan sistem minimum untuk dijalankan dengan kinerja yang dapat diterima", terutama dengan game. Sangat mungkin bahwa Dragon Age dapat, secara teori, berjalan pada kotak inti tunggal, tetapi jika Anda melakukannya, itu akan menunjukkan penurunan bingkai besar. Jadi mereka membutuhkan jumlah inti ini bukan untuk memaksa Anda membeli perangkat keras, tetapi untuk menghindari keluhan kualitas dari pengguna perangkat keras kelas bawah.
Gort the Robot

3
@ Sleb: Saya pikir Anda ke sesuatu: jika 4 core fisik tidak berkorelasi dengan memiliki lebih banyak cache daripada 2 fisik / 4 logis, maka permainan secara alami bisa tersedak pada mesin 2x2 tanpa mencapai batas kekuatan pemrosesan mereka karena itu hilang cache semua waktu. Tesnya adalah menemukan CPU dengan 2x2 core dan banyak cache, atau 4 core dan sedikit cache, dan lihat apa yang terjadi.
Steve Jessop

Jawaban:


45

Dimungkinkan untuk melakukan ini "secara tidak sengaja" dengan penggunaan afinitas inti secara ceroboh. Pertimbangkan kodesemu berikut:

  • mulai utas
  • di utas itu, cari tahu di mana inti itu berjalan
  • atur afinitas CPU-nya ke inti itu
  • mulai melakukan sesuatu yang intensif secara komputasi / loop selamanya

Jika Anda memulai empat dari mereka pada CPU dua-inti, maka ada yang tidak beres dengan pengaturan afinitas inti atau Anda berakhir dengan dua utas memonopoli inti yang tersedia dan dua utas yang tidak pernah dijadwalkan. Pada titik tidak ada secara eksplisit bertanya berapa banyak core yang ada secara total.

(Jika Anda memiliki utas yang sudah berjalan lama, pengaturan afinitas CPU umumnya meningkatkan throughput)

Gagasan bahwa perusahaan game "memaksa" orang untuk membeli perangkat keras yang lebih mahal tanpa alasan yang baik tidak terlalu masuk akal. Itu hanya bisa kehilangan mereka pelanggan.

Sunting: posting ini sekarang telah mendapat 33 upvotes, yang cukup banyak mengingat bahwa itu didasarkan pada tebakan yang dididik!

Tampaknya orang-orang telah mendapatkan DA: Saya menjalankan, buruk, pada sistem dual-core: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ Analisis itu menyebutkan bahwa situasinya akan sangat membaik jika hyperthreading dihidupkan. Mengingat bahwa HT tidak menambahkan unit instruksi masalah atau cache lagi, itu hanya memungkinkan satu utas berjalan sementara yang lain ada dalam ruang cache, yang menunjukkan dengan kuat bahwa itu terkait dengan murni jumlah utas.

Poster lain mengklaim bahwa mengubah driver grafis berfungsi: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; mengingat bahwa driver grafis cenderung menjadi sarang sampah dan penjahat, ini tidak mengejutkan. Satu set driver yang terkenal memiliki mode "benar & lambat" versus "cepat & salah" yang dipilih jika dipanggil dari QUAKE.EXE. Sangat mungkin bahwa driver berperilaku berbeda untuk jumlah CPU yang berbeda. Mungkin (kembali ke spekulasi) mekanisme sinkronisasi yang berbeda digunakan. Penyalahgunaan spinlocks ?

"Penyalahgunaan penguncian dan sinkronisasi primitif" adalah sumber bug yang sangat, sangat umum. (Bug yang seharusnya saya lihat di tempat kerja saat menulis ini adalah "macet jika mengubah pengaturan printer bersamaan dengan pekerjaan cetak selesai").

Sunting 2: komentar menyebutkan OS berusaha menghindari kelaparan utas. Perhatikan bahwa gim ini mungkin memiliki penjadwal kuasi internal sendiri untuk menetapkan pekerjaan ke utas, dan akan ada mekanisme serupa dalam kartu grafis itu sendiri (yang secara efektif merupakan sistem multitasking sendiri). Peluang bug di salah satu dari mereka atau interaksi di antara mereka cukup tinggi.

www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) adalah tesis pascasarjana tentang penjadwalan yang lebih baik untuk kartu grafis yang secara eksplisit menyebutkan bahwa mereka biasanya menggunakan penjadwalan pertama datang pertama dilayani, yang mudah diimplementasikan dalam sistem non-preemptive. Apakah situasinya membaik? Mungkin tidak.


1
Ya ada dua bagian untuk menjawab pertanyaan ini: Afinitas CPU memungkinkan seseorang untuk kode sesuatu yang akan membuat ini persyaratan teknis di Windows, jawaban alternatifnya adalah sistem realtime dapat sangat membutuhkan hal-hal seperti itu. +1 karena menjadi satu-satunya orang yang menyebutkan afinitas CPU yang sebenarnya merupakan penyebab paling mungkin untuk apa yang ditanyakan di sini.
Jimmy Hoffa

3
Apa yang bisa salah jika Anda mengatur afinitas ke inti saat ini? Dengan preemptive multitasking, utas tunggu akan dijadwalkan kecuali yang saat ini memiliki prioritas semaksimal mungkin ("realtime" pada Windows). Saya akan melihat skenario lain: masing-masing dari 4 utas diberi afinitas yang ditentukan secara statis sebesar 1,2,4,8, dalam hal ini dua utas yang terakhir tidak akan pernah dijadwalkan (walaupun saya tidak yakin apakah mengatur afinitas menjadi efektif nol akan berhasil).
Ruslan

@Ruslan Mungkin mencoba mengatur afinitas yang tidak valid akan menyebabkan crash aplikasi di tempat pertama?
Luaan

1
@Luaan dengan baik itu bukan operasi yang berisiko menyebabkan crash. Maksimum yang saya harapkan adalah kesalahan yang dikembalikan oleh OS. Saya baru saja memeriksa, di Linux saya mendapatkan kesalahan "Argumen tidak valid". Tidak tahu apa yang akan dikatakan Windows.
Ruslan

@Ruslan Setiap OS utama selama lebih dari satu dekade sudah termasuk kode untuk menghindari kelaparan thread (biasanya dengan meningkatkan prioritas utas setelah tidak berjalan cukup lama).
Voo

34

Mungkin perlu memiliki 4 core karena aplikasi menjalankan empat tugas dalam utas paralel dan mengharapkannya untuk menyelesaikan hampir secara bersamaan.

Ketika setiap utas dieksekusi oleh inti yang terpisah dan semua utas memiliki beban kerja komputasi yang sama persis, mereka kemungkinan besar (tetapi jauh dari jaminan) untuk menyelesaikan kira-kira waktu yang sama. Tetapi ketika dua utas berjalan pada satu inti, waktunya akan jauh lebih mudah diprediksi karena inti akan mengubah konteks antara dua utas sepanjang waktu.

Bug yang terjadi karena timing thread yang tidak terduga disebut sebagai " kondisi balapan ".

Dalam konteks pengembangan game, satu arsitektur yang masuk akal dengan masalah seperti ini bisa menjadi salah satu di mana fitur yang berbeda dari game disimulasikan secara real-time oleh utas CPU yang berbeda. Ketika setiap fitur berjalan pada inti sendiri, mereka semua disimulasikan dengan kecepatan yang kira-kira sama. Tetapi ketika dua fitur berjalan pada satu inti, keduanya hanya akan disimulasikan setengah secepat dunia permainan, yang dapat menyebabkan semua jenis perilaku aneh.

Perhatikan bahwa arsitektur perangkat lunak yang bergantung pada utas independen yang berjalan dengan timing spesifik sangat rapuh dan merupakan tanda pemahaman yang sangat buruk tentang pemrograman bersamaan. Ada fitur yang tersedia di hampir semua API multithreading untuk menyinkronkan utas secara eksplisit untuk mencegah masalah seperti ini.


11
Tetapi setiap game memiliki ketergantungan yang rapuh untuk dapat menyelesaikan semua perhitungan untuk frame berikutnya pada waktunya untuk membuatnya dengan frekuensi yang masuk akal. Bahkan jika 4 utas Anda disinkronkan dengan benar, mungkin tidak mungkin untuk melakukan secara tepat waktu, dan tidak ada manfaat dalam permainan yang secara komputasi benar tetapi tidak dapat dimainkan karena lag dan gagap.
berguna

1
@Useless: Itu tidak sepenuhnya benar. Misalnya Anda dapat buffer frame atau data simulasi untuk menyembunyikan gagap, dan ada desain bersamaan yang lebih konsisten. Mengerjakan semua pemrosesan Anda dalam waktu X dan memastikan sinkronisasi yang tepat dari pemrosesan itu adalah hal yang berbeda.
DeadMG

23
"arsitektur perangkat lunak yang bergantung pada utas independen yang berjalan dengan timing spesifik sangat rapuh" Itulah sebabnya saya tidak bisa membayangkan permainan yang tidak berjalan sama sekali dengan 2 core, tetapi andal bekerja dengan 4 core. Bahkan dengan 4 core, waktunya akan tidak dapat diprediksi, sehingga kondisi balapan akan terjadi juga, bahkan jika lebih jarang.
svick

8
@vick tentu saja. Tetapi pertanyaannya adalah "apakah itu mungkin?" bukan "apakah ini waras?"
user253751

5
Kode apa pun dengan "kondisi ras" semacam ini benar-benar rusak , tidak peduli berapa banyak inti yang Anda jalankan. (Terutama karena sama sekali tidak ada jaminan tentang apa lagi yang berjalan pada sistem.) Saya serius meragukan hal ini menjadi penyebabnya, mengingat betapa mudahnya hal itu akan membuat game tersandung bahkan pada sistem hexacore ...
DevSolar

16

Tidak mungkin "persyaratan minimum" ini mewakili sesuatu di bawah ini yang tidak akan dijalankan oleh game. Jauh lebih mungkin adalah bahwa mereka mewakili sesuatu di bawah ini yang tidak akan dijalankan oleh permainan dengan kinerja yang dapat diterima. Tidak ada perusahaan game yang ingin berurusan dengan banyak pelanggan yang mengeluh tentang kinerja jelek ketika mereka menjalankannya pada kotak single core 1 Ghz, bahkan jika perangkat lunaknya dapat berjalan secara teknis. Jadi mereka mungkin sengaja merancang untuk gagal keras pada kotak dengan core lebih sedikit daripada yang akan memberi mereka kinerja yang dapat diterima.

Salah satu metrik penting dalam kinerja game adalah frame rate. Biasanya mereka berjalan pada 30 atau 60 frame per detik. Ini berarti bahwa mesin permainan harus membuat tampilan saat ini dari keadaan permainan dalam jumlah waktu yang tetap. Untuk mencapai 60 fps, hanya perlu sedikit lebih dari 16 msec untuk melakukan ini. Game dengan grafis kelas atas sangat terikat dengan CPU, jadi ada memberi dan menerima yang besar antara mencoba untuk mendorong kualitas yang lebih tinggi (yang membutuhkan lebih banyak waktu) dan kebutuhan untuk tetap berada dalam anggaran waktu ini. Dengan demikian, anggaran waktu untuk setiap frame sangat ketat.

Karena anggaran waktu terbatas, pengembang idealnya menginginkan akses eksklusif ke satu atau lebih inti. Mereka juga mungkin ingin dapat melakukan rendering barang-barang mereka dalam sebuah inti, secara eksklusif, karena apa yang harus dilakukan pada anggaran waktu itu, sementara hal-hal lain, seperti menghitung negara dunia, terjadi pada proses terpisah di mana itu tidak akan mengganggu.

Anda bisa, secara teori, menjejalkan semua ini ke satu inti, tetapi kemudian semuanya menjadi lebih sulit. Tiba-tiba Anda harus memastikan semua hal keadaan permainan terjadi cukup cepat, dan memungkinkan rendering Anda terjadi. Anda tidak bisa hanya membuat mereka dua utas perangkat lunak karena tidak ada cara untuk membuat OS memahami "utas A harus menyelesaikan jumlah pekerjaan X dalam 16 msecs terlepas dari apa yang dilakukan thread B".

Pengembang game tidak tertarik untuk membuat Anda membeli perangkat keras baru. Alasan mereka memiliki persyaratan sistem adalah karena biaya untuk mendukung mesin kelas bawah tidak sepadan.


Meskipun ini benar, itu terjadi bahwa Anda dapat membeli perangkat keras dual-core yang cukup kuat sehingga dapat mencapai lebih banyak dalam kerangka waktu tertentu daripada perangkat keras quad-core yang dijelaskan dalam spesifikasi minimum. Mengapa vendor tidak mencantumkan perangkat keras yang dapat diterima, suatu keputusan yang hanya dapat membuat mereka kehilangan penjualan?
Jules

4
Hal untuk membandingkan bukan 2 vs 4 core. Ini pada dasarnya 1 vs 3 core, karena CPU # 0 akan dipatok cukup banyak oleh driver grafis dan DPC. Ada juga efek cache dan migrasi yang signifikan jika Anda terlalu banyak berlangganan CPU dengan beberapa jenis tugas dalam sistem pekerjaan game modern pada umumnya. Persyaratan ada di sana karena Frostbite (mesin DA: I) dirancang dari bawah ke atas dengan penyetelan yang sangat hati-hati yang membutuhkan sejumlah inti.
Lars Viklund

6
@LarsViklund Sepertinya Anda tahu lebih banyak detail daripada siapa pun di sini. Sudahkah Anda mempertimbangkan untuk mengumpulkan jawaban?
Gort the Robot

1
"Tidak mungkin bahwa" persyaratan minimum "ini mewakili sesuatu di bawah ini yang tidak akan dijalankan oleh game. Jauh lebih mungkin bahwa mereka mewakili sesuatu di bawah ini yang tidak akan dijalankan oleh game dengan kinerja yang dapat diterima." - Intel G3258 adalah prosesor dual core yang sangat kuat yang banyak digunakan oleh gamer yang mampu menjalankan game dengan sumber daya yang sama atau lebih intensif daripada Dragon Age Inquisition, tetapi banyak pemain melaporkan game tidak berjalan di atasnya.
uylmz

2
@Reek Saya ragu bahwa pengguna akhir dapat dengan mudah mengetahui seberapa intensif sumber daya permainan tertentu dibandingkan dengan yang lain.
Gort the Robot

9

Tiga utas realtime yang tidak pernah tidur dan satu utas lainnya. Jika ada kurang dari empat core, utas keempat tidak pernah berjalan. Jika utas keempat perlu berkomunikasi dengan salah satu utas realtime agar utas realtime selesai, kode tidak akan selesai dengan kurang dari empat inti.

Jelas jika utas realtime sedang menunggu sesuatu yang tidak memungkinkan mereka untuk tidur (seperti spinlock) perancang program mengacau.


1
Dapat diperdebatkan, ketika aplikasi pengguna meminta utas secara langsung di tempat pertama, perancang mengacau: D
Luaan

2
Saya sudah melakukannya. Setengah juta baris kode. Satu case menggunakan sekitar 300 baris. Utas waktu-nyata menghabiskan sebagian besar waktunya menunggu input sehingga dapat mencocokkan waktu input dan menyerahkannya ke utas prioritas yang lebih rendah.
Yosua

2
@Luaan Untuk sebagian besar aplikasi saya setuju dengan Anda, tetapi game adalah binatang yang berbeda, seperti aplikasi yang disematkan. Dalam kedua kasus tersebut, kepedulian untuk bermain baik dengan aplikasi bersamaan lainnya sebagian besar hilang karena mendukung kinerja.
reirab

Meskipun tidak akan terlalu efisien, skenario ini tidak akan menyebabkan kebuntuan - inversi prioritas akan menanganinya (dengan asumsi penjadwal setengah layak dalam OS utama apa pun dari dekade terakhir)
Voo

2
@ Yosua > Windows tidak tahu apa itu inversi prioritas. Apa? support.microsoft.com/kb/96418 , msdn.microsoft.com/en-us/library/windows/desktop/ms684831.aspx . Juga, inversi prioritas adalah istilah yang menjelaskan masalah , bukan solusi (@Voo).
Bob

3

Pertama-tama utas perangkat lunak tidak ada hubungannya dengan utas perangkat keras dan sering kali dicampuradukkan. Utas perangkat lunak adalah potongan kode yang dapat dikirim dan dijalankan sendiri dalam konteks proses. Utas perangkat keras sebagian besar dikelola oleh OS dan dikirim ke inti prosesor ketika berbicara tentang program reguler. Utas perangkat keras ini dikirim berdasarkan beban; dispatcher ulir perangkat keras bertindak kurang lebih seperti penyeimbang beban.

Namun ketika datang ke game, terutama game high-end, kadang-kadang utas perangkat keras dikelola oleh permainan itu sendiri atau permainan memerintahkan dispatcher utas perangkat keras apa yang harus dilakukan. Itu karena setiap tugas atau kelompok tugas tidak memiliki prioritas yang sama seperti dalam program normal. Karena zaman naga berasal dari studio game high-end menggunakan mesin-mesin high-end, saya dapat membayangkan bahwa itu menggunakan pengiriman "manual" dan kemudian jumlah core menjadi persyaratan sistem minimal. Program apa pun akan macet ketika saya mengirim sepotong kode ke inti fisik ke-3 yang berjalan pada mesin dengan hanya 1 atau 2 core.


Ini. Ingatlah bahwa mengatakan "jangan pilih inti" berarti bahwa perusahaan membuat produk perangkat lunaknya dengan cara tertentu untuk memaksa pengguna membeli perangkat keras yang lebih mahal (yang tidak dimaksudkan dengan baik).
uylmz

2
Masalah-masalah ini ada selama ada game PC. Pada awalnya kami memiliki 486dx dan 486sx, kemudian MMX dan non-MMX Pentium, inti dan non-inti dan hari ini kami memiliki persyaratan n-core. Ini adalah salah satu alasan mengapa konsol masih ada.
dj bazzie wazzie

4
Apakah Anda memiliki referensi untuk gim yang mengambil alih penjadwalan CPU sendiri? Sejauh yang saya ketahui, ini tidak mungkin secara langsung di bawah Windows, setidaknya tidak dengan cara yang akan gagal seperti yang Anda sarankan.
Jules

2
@djbazziewazzie sebenarnya windows memang menyediakan api untuk melakukan hal itu, yaitu mengatur utas untuk selalu menggunakan inti yang sama; ini disebut afinitas utas, dan tidak memungkinkan Anda untuk secara manual memilih bagian kode mana yang berjalan di mana dan kapan, dan tidak dapat menyebabkan kegagalan sistem seperti yang Anda sarankan (sistem akan mengabaikan permintaan untuk mengatur afinitas ke inti yang tidak ada, dan terus penjadwalan utas ke inti apa pun saat tersedia. Saya cukup yakin ini adalah apa yang digunakan Tech, dan itu tidak benar-benar berarti "mengelola utas perangkat keras itu sendiri."
Jules

1
@djbazziewazzie Anda juga tampaknya salah paham tentang titik Grand Central Dispatch, yang tidak memberi pengembang lebih banyak kontrol atas bagaimana kode mereka dijadwalkan ke inti; sebenarnya, tujuannya adalah kebalikannya: mengambil pilihan berapa banyak utas yang akan dibuat dan kode mana yang harus dijalankan pada utas mana yang keluar dari tangan aplikasi sehingga dapat dioptimalkan untuk perangkat keras yang tersedia pada tingkat sistem. Ketergantungan pada jumlah inti tertentu adalah jenis masalah yang dirancang untuk dicegah oleh GCD.
Jules

1

Karena dimungkinkan untuk menggunakan virtualisasi untuk memiliki lebih banyak core virtual daripada fisik dan perangkat lunak tidak akan tahu itu berjalan pada virtualisasi dan sebaliknya berpikir bahwa itu memang memiliki banyak core fisik, saya akan mengatakan perangkat lunak seperti itu tidak mungkin.

Artinya, tidak mungkin untuk menulis perangkat lunak yang akan selalu berhenti di kurang dari N core.

Seperti yang telah ditunjukkan orang lain, ada solusi perangkat lunak yang berpotensi memeriksa, terutama jika OS dan kode yang digunakan memiliki sedikit perlindungan terhadap kondisi balapan ketika proses N dijalankan pada <N prosesor. Trik sebenarnya adalah kode yang akan gagal saat Anda memiliki prosesor kurang dari N tetapi tidak akan gagal ketika Anda memiliki prosesor N tetapi memiliki OS yang dapat menetapkan pekerjaan untuk prosesor yang kurang dari N.


1

Bisa jadi ada tiga utas yang melakukan sesuatu (menghasilkan latar belakang atau menghasilkan gerakan NPC) dan meneruskan acara ke urutan keempat, yang seharusnya mengagregasi / memfilter acara dan memperbarui model tampilan. Jika utas keempat tidak mendapatkan semua acara (karena tidak dijadwalkan pada inti) maka model tampilan tidak dapat diperbarui dengan benar. Ini mungkin hanya terjadi secara sporadis, tetapi inti tersebut harus tersedia kapan saja. Ini mungkin menjelaskan mengapa Anda tidak melihat penggunaan CPU yang tinggi sepanjang waktu, tetapi permainan tetap gagal berfungsi dengan baik.


1
Dalam skenario seperti itu, permainan juga akan gagal secara acak ketika layanan latar belakang dijadwalkan untuk berjalan, yang cukup sering pada kebanyakan komputer.
Jules

1

Saya pikir Joshua sedang menuju jalan yang benar, hanya saja tidak sampai pada kesimpulan itu.

Misalkan Anda memiliki arsitektur di mana ada tiga utas yang ditulis untuk melakukan sebanyak yang mereka bisa - ketika mereka menyelesaikan apa yang mereka lakukan, mereka melakukannya lagi. Untuk menjaga kinerja agar utas ini tidak melepaskan kontrol untuk apa pun - mereka tidak ingin mengambil risiko kelambatan dari penjadwal tugas Windows. Selama ada 4 atau lebih core ini berfungsi dengan baik, gagal jika tidak ada.

Secara umum ini akan menjadi pemrograman yang buruk tetapi permainan adalah masalah lain - ketika Anda dihadapkan dengan pilihan antara desain yang lebih rendah pada semua perangkat keras atau desain yang lebih unggul pada perangkat keras yang cukup baik atau kegagalan pada perangkat keras yang lebih rendah biasanya pengembang permainan memilih membutuhkan perangkat keras.


Biasanya tidak mungkin untuk menulis utas yang tidak akan melepaskan kontrol ke utas lainnya. Semua sistem operasi non-RTOS modern menggunakan preemptive multitasking, yang dengan sengaja membuatnya tidak mungkin untuk utas (mode pengguna) untuk tidak melepaskan kontrol dari inti yang diberikan. Utas kernel, tentu saja, adalah masalah yang berbeda.
reirab

@reirab Tingkatkan prioritasnya.
Loren Pechtel

@ Loren Tidak mengubah fakta bahwa penjadwal masih mati fungsinya yang berarti Anda harus berbagi waktu dengan utas lainnya dengan prioritas yang sama dan penjadwal meningkatkan prioritas utas kelaparan. Anda tidak dapat melakukan itu pada OS normal dan bahkan jika Anda bisa, game tentu tidak akan menjadi aplikasi yang dapat diterima untuk melakukannya juga.
Voo

1

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

Benar. Penggunaan utas real-time akan menjadi contoh yang baik dari situasi di mana ini, tidak hanya mungkin, tetapi cara yang diinginkan (dan seringkali, satu-satunya cara yang benar) untuk menyelesaikan pekerjaan. Namun, utas waktu-nyata biasanya terbatas pada kernel OS, biasanya untuk driver yang perlu dapat menjamin bahwa peristiwa perangkat keras semacam itu ditangani dalam beberapa periode waktu tertentu. Anda seharusnya tidak memiliki utas real-time dalam aplikasi pengguna normal dan saya tidak yakin bahwa ada kemungkinan untuk memilikinya di aplikasi mode pengguna Windows. Secara umum, sistem operasi sengaja membuatnya mustahil untuk melakukan ini dari tanah pengguna justru karena itu memungkinkan aplikasi yang diberikan untuk mengambil alih kendali sistem.

Mengenai aplikasi pengguna lahan: Asumsi Anda bahwa memeriksa jumlah utas tertentu untuk menjalankannya tentu jahat maksudnya tidak benar. Misalnya, Anda dapat memiliki 2 tugas yang telah lama berjalan, kinerja-intensif yang membutuhkan inti untuk diri mereka sendiri. Terlepas dari kecepatan inti CPU, berbagi inti dengan utas lain dapat menjadi penurunan kinerja yang serius dan tidak dapat diterima karena meronta-ronta cache bersama dengan hukuman normal yang ditimbulkan oleh penggantian ulir (yang cukup besar.) Dalam hal ini, akan sangat masuk akal, khususnya untuk sebuah game, untuk mengatur setiap utas ini untuk memiliki afinitas hanya pada satu inti tertentu untuk masing-masing dan kemudian mengatur semua utas Anda yang lain untuk tidak memiliki afinitas pada 2 inti tersebut. Untuk melakukan ini, Anda


1

Kode apa pun yang menggunakan spinlocks dengan jumlah kunci pertentangan yang terlihat akan berkinerja sangat buruk (sampai batas di mana - untuk aplikasi seperti game - Anda dapat mengatakan "tidak berfungsi" ) jika jumlah utas melebihi jumlah inti.

Bayangkan, misalnya, sebuah utas produsen yang mengirimkan tugas ke antrian yang melayani 4 utas konsumen. Hanya ada dua inti:

Produser mencoba memperoleh spinlock, tetapi dipegang oleh konsumen yang menjalankan core lainnya. Dua core berjalan berbaris sementara produser berputar, menunggu kunci untuk dirilis. Ini sudah buruk, tetapi tidak seburuk yang akan didapat.
Sayangnya, utas konsumen berada di akhir kuantum waktunya, jadi sudah diutamakan, dan utas konsumen lain dijadwalkan. Mencoba untuk mendapatkan kunci, tetapi tentu saja kunci diambil, jadi sekarang dua core berputar dan menunggu sesuatu yang tidak mungkin terjadi.
Utas produsen mencapai akhir irisan waktu dan didahului, konsumen lain bangun. Sekali lagi, dua konsumen sedang menunggu kunci untuk dirilis, dan itu tidak akan terjadi sebelum dua kuantum waktu berlalu.
[...] Akhirnya konsumen yang memegang spinlock telah melepaskan kunci. Ini segera diambil oleh siapa pun yang berputar pada inti lainnya. Ada kemungkinan 75% (3 banding 1) bahwa itu adalah utas konsumen lainnya. Dengan kata lain, kemungkinan 75% produsernya masih mandek. Tentu saja ini berarti konsumen juga berhenti. Tanpa produser menghentikan tugas, mereka tidak akan melakukan apa pun.

Perhatikan bahwa ini bekerja pada prinsipnya dengan segala jenis penguncian, tidak hanya spinlocks - tetapi efek yang menghancurkan jauh lebih menonjol dengan spinlocks karena CPU terus membakar siklus sementara itu tidak mencapai apa-apa.

Sekarang bayangkan bahwa selain di atas beberapa programmer memiliki ide cemerlang untuk menggunakan utas khusus dengan afinitas ditetapkan ke inti pertama, sehingga RDTSC akan memberikan hasil yang dapat diandalkan pada semua prosesor (itu tidak akan tetap, tetapi beberapa orang berpikir begitu).


Itulah sebabnya spinlocks yang bagus menurunkan versi ke jenis kunci lain setelah beberapa saat, dan bahkan yang lebih baik melakukannya dengan lebih cepat jika penggunaan sebelumnya dari kunci yang sama harus di-downgrade.
Ian

-1

Jika saya mengerti apa yang Anda minta, itu mungkin, tetapi itu adalah hal yang sangat, sangat buruk.

Contoh kanonik dari apa yang Anda gambarkan adalah mempertahankan penghitung yang ditambahkan oleh banyak utas. Ini hampir tidak memerlukan apa pun dalam daya komputasi, tetapi membutuhkan koordinasi yang cermat di antara semua utas. Selama hanya satu utas pada satu waktu melakukan peningkatan (yang sebenarnya merupakan pembacaan diikuti oleh penambahan diikuti oleh penulisan), nilainya akan selalu benar. Ini karena satu utas akan selalu membaca nilai "sebelumnya" yang benar, tambahkan satu dan tulis nilai "selanjutnya" yang benar. Dapatkan dua utas ke tindakan pada saat yang sama dan keduanya akan membaca nilai "sebelumnya" yang sama, mendapatkan hasil yang sama dari kenaikan dan menulis nilai "berikutnya" yang sama. Penghitung secara efektif akan bertambah hanya sekali meskipun dua utas berpikir mereka masing-masing melakukannya.

Ketergantungan antara waktu dan kebenaran inilah yang oleh ilmu komputer disebut kondisi balapan .

Kondisi balapan seringkali dihindari dengan menggunakan mekanisme sinkronisasi untuk memastikan utas yang ingin beroperasi pada sepotong data yang dibagikan harus mengantre untuk akses. Penghitung yang dijelaskan di atas mungkin menggunakan kunci baca-tulis untuk ini.

Tanpa akses ke desain internal Dragon Age: Inkuisisi , yang dapat dilakukan siapa pun hanyalah berspekulasi tentang mengapa berperilaku seperti itu. Tapi saya akan mencoba berdasarkan beberapa hal yang saya lihat dilakukan dalam pengalaman saya sendiri:

Mungkin saja program ini didasarkan pada empat utas yang telah disetel sehingga semuanya berfungsi ketika utas sebagian besar berjalan tanpa gangguan pada inti fisik mereka sendiri. "Penyetelan" dapat dilakukan dalam bentuk penyusunan ulang kode atau memasukkan tidur di tempat-tempat strategis untuk mengurangi bug yang disebabkan oleh kondisi ras yang muncul selama pengembangan. Sekali lagi, ini semua dugaan, tetapi saya telah melihat kondisi balapan "diselesaikan" dengan cara itu lebih dari yang saya perhitungkan.

Menjalankan program seperti itu pada sesuatu yang kurang mampu daripada lingkungan yang disetelnya memperkenalkan perubahan waktu yang merupakan hasil dari kode yang tidak berjalan secepat atau, lebih mungkin, konteks switch. Sakelar konteks terjadi dalam cara fisik (yaitu, inti fisik CPU beralih di antara pekerjaan yang dipegang inti logisnya) dan logis (yaitu, OS pada CPU memberikan pekerjaan pada inti) cara, tetapi keduanya merupakan perbedaan yang signifikan dari apa yang akan menjadi waktu eksekusi "yang diharapkan". Itu bisa memunculkan perilaku buruk.

Jika Dragon Age: Inkuisisi tidak mengambil langkah sederhana untuk memastikan ada cukup inti fisik yang tersedia sebelum melanjutkan, itu salah EA. Mereka mungkin menghabiskan banyak uang dukungan panggilan dan email dari orang-orang yang mencoba menjalankan permainan pada perangkat keras yang terlalu sedikit.


1
Beberapa pemain mengatakan itu disebabkan oleh DRM yang berjalan di 2 core dan gim yang sebenarnya berjalan di 2 juga. Saat DRM dan utas permainan berjalan pada inti yang sama, ia akan kacau. Tapi ini kedengarannya tidak benar bagiku, itu mungkin sedikit cerita yang dibuat oleh pemain yang tidak tahu banyak tentang arsitektur sw atau hw.
uylmz

4
kondisi balapan benar-benar tidak banyak hubungannya dengan jumlah inti, -1 ... mesin inti tunggal dengan beberapa utas virtual dapat memiliki kondisi perlombaan yang sepenuhnya tergantung pada teknik pengiris waktu runtime, atau banyak sistem inti dapat menghindari semua kondisi perlombaan bergantung pada seberapa ketatnya dengan operasi membar ...
Jimmy Hoffa

1
@Reek: Tanpa pengetahuan mendalam tentang cara kerja program, apa pun hanyalah dugaan. Dua core untuk mengerjakan DRM sepertinya sedikit berlebihan bagi saya.
Blrfl

1
@JimmyHoffa: Saya tidak setuju. Kondisi ras masih merupakan kondisi ras bahkan ketika itu tidak menyebabkan perilaku yang tidak diinginkan. Hitungan inti dapat memengaruhi apakah perilaku itu terjadi atau tidak, itulah yang ditanyakan penanya, tetapi saya tidak menyebutkannya sebagai satu-satunya variabel.
Blrfl

-1

Windows memiliki fungsionalitas bawaan untuk ini: fungsi GetLogicalProcessorInformation ada di Windows API . Anda dapat memanggilnya dari program Anda untuk mendapatkan informasi tentang core, core virtual, dan hyperthreading.

Jadi jawaban untuk pertanyaan Anda adalah: Ya.


3
Saya tidak bertanya, "Bisakah saya menemukan inti dari kode?" ... Kode seperti itu akan disengaja (memaksa Anda untuk membeli CPU yang lebih mahal untuk menjalankan program - tanpa perlu daya komputasi).
uylmz

3
Fungsi ini memberikan lebih banyak informasi daripada sekadar "jumlah inti". Dengan informasi ini Anda dapat memotong inti fisik, inti logis, dan banyak lagi. Jika Anda dapat mengurangi itu, maka Anda dapat menulis perangkat lunak untuk menggunakan informasi ini. Dalam cara yang baik atau buruk (crash program ketika Anda melihat 4 core tetapi kurang dari 4 core fisik).
Pieter B

1
Ini mungkin bekerja di Windows, tetapi bagaimana dengan OSX / Linux / iOS / Android / dll.? Sementara itu merujuk permainan sebagai contoh di mana perilaku ini terlihat (dan korelasi alami adalah Windows = Gaming), itu tampaknya bukan permintaan khusus game.
Robert

Untuk gim seperti Dragon Age, sistem yang dimaksud adalah Windows / XBox / PS4.
Gort the Robot

Linux memiliki /proc/cpuinfodan sysconf(_SC_NPROCESSORS_ONLN)(yang terakhir disebutkan dalam POSIX). Menggunakan info untuk menegakkan ambang batas kinerja minimum masih merupakan bentuk yang sangat buruk.
cao
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.