Pendekatan umum untuk mengambil keuntungan dari banyak core adalah, terus terang, hanya sesat. Memisahkan subsistem Anda menjadi utas yang berbeda memang akan membagi beberapa pekerjaan di beberapa inti, tetapi ia memiliki beberapa masalah besar. Pertama, sangat sulit untuk dikerjakan. Siapa yang mau bercanda dengan kunci dan sinkronisasi dan komunikasi dan hal-hal ketika mereka bisa saja menulis langsung rendering atau kode fisika saja? Kedua, pendekatan tersebut tidak benar-benar ditingkatkan. Paling-paling, ini akan memungkinkan Anda untuk mengambil keuntungan dari mungkin tiga atau empat core, dan itu jika Anda benar - benar tahu apa yang Anda lakukan. Hanya ada begitu banyak subsistem dalam sebuah gim, dan dari mereka bahkan ada lebih sedikit lagi yang memakan waktu CPU yang besar. Ada beberapa alternatif bagus yang saya tahu.
Salah satunya adalah memiliki utas utama bersama dengan utas pekerja untuk setiap CPU tambahan. Terlepas dari subsistem, utas utama mendelegasikan tugas yang terisolasi ke utas pekerja melalui semacam antrian; tugas-tugas ini sendiri dapat membuat tugas-tugas lain, juga. Satu-satunya tujuan utas pekerja adalah untuk masing-masing mengambil tugas dari antrian satu per satu dan menjalankannya. Namun, hal yang paling penting adalah bahwa segera setelah utas membutuhkan hasil tugas, jika tugas tersebut selesai, ia dapat memperoleh hasilnya, dan jika tidak, ia dapat dengan aman menghapus tugas dari antrian dan melanjutkan dan melakukan itu tugas itu sendiri. Artinya, tidak semua tugas pada akhirnya dijadwalkan secara paralel satu sama lain. Memiliki lebih banyak tugas daripada yang dapat dieksekusi secara paralel adalah baikhal dalam hal ini; itu berarti bahwa kemungkinan untuk skala ketika Anda menambahkan lebih banyak inti. Satu kelemahan untuk ini adalah bahwa itu membutuhkan banyak pekerjaan di muka untuk merancang antrian yang layak dan lingkaran pekerja kecuali Anda memiliki akses ke perpustakaan atau runtime bahasa yang sudah menyediakan ini untuk Anda. Bagian tersulit adalah memastikan tugas Anda benar-benar terisolasi dan aman, dan memastikan tugas Anda berada di jalan tengah yang menyenangkan antara yang berbutir kasar dan berbutir halus.
Alternatif lain untuk thread subsistem adalah memparalelkan setiap subsistem secara terpisah. Artinya, alih-alih menjalankan rendering dan fisika di utasnya sendiri, tulis subsistem fisika untuk menggunakan semua core Anda sekaligus, tulis subsistem rendering untuk menggunakan semua core Anda sekaligus, kemudian mintalah dua sistem berjalan secara berurutan (atau disisipkan, tergantung pada aspek lain dari arsitektur gim Anda). Misalnya, dalam subsistem fisika Anda bisa mengambil semua titik massa dalam permainan, membaginya di antara inti Anda, dan kemudian minta semua inti memperbaruinya sekaligus. Setiap inti kemudian dapat bekerja pada data Anda dalam loop ketat dengan lokasi yang baik. Gaya paralelisme kunci-langkah ini mirip dengan apa yang dilakukan GPU. Bagian tersulit di sini adalah memastikan bahwa Anda membagi pekerjaan Anda menjadi potongan-potongan halus sehingga membagi secara meratasebenarnya menghasilkan jumlah pekerjaan yang sama di semua prosesor.
Namun, kadang-kadang itu hanya termudah, karena politik, kode yang ada, atau keadaan frustasi lainnya, untuk memberikan setiap subsistem sebuah utas. Dalam hal ini, yang terbaik adalah menghindari membuat lebih banyak thread OS daripada core untuk beban kerja CPU yang berat (jika Anda memiliki runtime dengan thread ringan yang kebetulan menyeimbangkan seluruh core Anda, ini bukan masalah besar). Selain itu, hindari komunikasi yang berlebihan. Salah satu trik yang bagus adalah mencoba pipelining; setiap subsistem utama dapat bekerja pada kondisi permainan yang berbeda pada suatu waktu. Pipelining mengurangi jumlah komunikasi yang diperlukan di antara subsistem Anda karena mereka tidak semua memerlukan akses ke data yang sama pada saat yang sama, dan itu juga dapat menghapuskan beberapa kerusakan yang disebabkan oleh kemacetan. Sebagai contoh, jika subsistem fisika Anda cenderung membutuhkan waktu yang lama untuk diselesaikan dan subsistem rendering Anda berakhir selalu menunggunya, laju bingkai absolut Anda bisa lebih tinggi jika Anda menjalankan subsistem fisika untuk frame berikutnya sementara subsistem rendering masih bekerja pada sebelumnya bingkai. Bahkan, jika Anda memiliki hambatan seperti itu dan tidak dapat menghapusnya dengan cara lain, pipelining mungkin merupakan alasan paling sah untuk repot dengan utas subsistem.