Saya selalu menemukan istilah, "optimasi mikro", agak ambigu. Jika beberapa perubahan tingkat instruksi ke tata letak memori dan pola akses membuat sesuatu 80 kali lebih cepat dari seorang profesional yang disiplin mengukur hotspot mereka tanpa pengurangan kompleksitas algoritmik, apakah itu "optimasi mikro"? Bagi saya itu adalah "mega-optimasi" untuk membuat sesuatu yang 80 kali lebih cepat pada kasus penggunaan dunia nyata. Orang-orang cenderung membicarakan hal-hal ini seperti optimisasi semacam itu memiliki efek mikroskopis.
Saya tidak lagi bekerja di gamedev tapi saya bekerja di VFX di bidang-bidang seperti penelusuran jalur, dan saya telah melihat banyak implementasi pohon-pohon BVH dan KD di luar sana yang memproses ~ 0,5 juta sinar per detik pada pemandangan yang kompleks (dan ini dengan evaluasi multithreaded). Secara kasar saya cenderung melihat implementasi langsung dari BVH dalam konteks raytracing di bawah 1 juta sinar / detik bahkan dengan evaluasi multithreaded. Kecuali Embree memiliki BVH yang dapat memproses lebih dari 100 juta sinar pada adegan yang sama dengan perangkat keras yang sama.
Itu sepenuhnya karena "optimasi mikro" bahwa Embree adalah 200 kali lebih cepat (algoritma dan struktur data yang sama), tetapi tentu saja alasannya jauh lebih cepat adalah karena pengembang di Intel di belakangnya adalah para profesional yang bersandar pada profiler dan pengukuran mereka dan benar-benar mengetahui area yang penting. Mereka tidak mengubah kode mau tak mau dari firasat dan melakukan perubahan yang membuat peningkatan 0,000000001% dengan biaya pemeliharaan yang merendahkan secara signifikan. Ini adalah optimasi yang sangat tepat diterapkan di tangan yang bijaksana - mereka mungkin mikroskopis dalam hal fokus tetapi makroskopis dalam hal efek.
Biasanya dengan persyaratan frame rate waktu-nyata dari game, tergantung pada seberapa tinggi atau rendah level Anda bekerja dengan mesin game (bahkan game yang dibuat dengan UE 4 sering diimplementasikan setidaknya sebagian dalam skrip tingkat tinggi, tetapi tidak, katakanlah, bagian paling kritis dari mesin fisika), optimasi mikro menjadi persyaratan praktis di bidang tertentu.
Area lain yang sangat mendasar yang mengelilingi kita setiap hari adalah pemrosesan gambar, seperti mengaburkan gambar beresolusi tinggi secara real-time dan mungkin melakukan efek lain pada mereka sebagai bagian dari transisi yang mungkin kita semua pernah lihat di suatu tempat, bahkan mungkin efek OS. Anda tidak dapat serta merta mengimplementasikan operasi gambar seperti itu dari perulangan awal melalui semua piksel gambar dan mengharapkan hasil waktu-nyata seperti itu pada kecepatan bingkai yang cocok. Jika itu CPU, kita biasanya melihat SIMD dan beberapa tuning mikro, atau kita melihat GPU shaders yang cenderung membutuhkan semacam pola pikir tingkat mikro untuk menulis secara efektif.
Jika ya, seiring dengan peningkatan perangkat keras haruskah kita mengharapkan bahasa tingkat lebih tinggi untuk mengambil alih industri game?
Saya agak meragukan kemajuan perangkat keras saja yang dapat melakukan itu, karena seiring dengan kemajuan perangkat keras, demikian pula instruksi dan teknologi (mis: fisika pada GPU), dan teknik, serta harapan pelanggan untuk apa yang ingin mereka lihat, dan persaingan, dalam cara yang sering membuat pengembang kembali ke level rendah, seperti halnya pengembang web sekarang menulis shader GLSL tingkat rendah di WebGL (pengembangan web semacam ini bisa dibilang bahkan lebih rendah daripada level satu atau dua dekade lalu, karena GLSL adalah bahasa tingkat C yang sangat rendah, dan saya tidak akan pernah menduga satu atau dua dekade yang lalu bahwa beberapa pengembang web akan merangkul penulisan shaders GPU tingkat rendah seperti itu).
Jika akan ada cara agar area yang kritis terhadap kinerja pindah ke bahasa tingkat yang lebih tinggi, itu harus berasal lebih dari perangkat lunak dan kompiler serta alat yang kami miliki seperti yang saya lihat. Masalahnya bagi saya di masa mendatang adalah perangkat keras tidak cukup kuat. Ini lebih berkaitan dengan bagaimana kita tidak dapat menemukan cara untuk berbicara secara efektif setiap kali itu berubah dan maju tanpa bekerja kembali ke bahasanya sendiri lagi. Sebenarnya ini adalah langkah cepat di mana perubahan perangkat keras yang membuat pemrograman tingkat tinggi agak sulit dipahami untuk area ini seperti yang saya lihat, karena jika secara hipotetis perangkat keras kita berhenti bergerak maju secara tiba-tiba selama beberapa dekade berikutnya,
Lucunya hari ini, ketika saya sedang bekerja di bidang kritis kinerja asli, saya harus berpikir lebih rendah daripada yang saya mulai (meskipun saya mulai di era Borland Turbo C DOS). Karena saat itu cache CPU hampir tidak ada. Itu sebagian besar hanya DRAM dan register, yang berarti saya bisa lebih fokus pada kompleksitas algoritmik dan menulis struktur terkait seperti pohon dengan cara yang sangat mudah tanpa mengambil banyak kinerja. Saat ini detail tingkat rendah dari cache CPU mendominasi pemikiran saya hampir seperti algoritma itu sendiri. Dan juga kami memiliki mesin multi-core yang harus membuat kami berpikir tentang multithreading dan atomics dan mutexes dan thread safety dan struktur data bersamaan dan sebagainya, yang saya katakan adalah, dalam banyak hal, fokus level yang jauh lebih rendah (seperti dalam, tidak begitu manusiawi intuitif) daripada ketika saya mulai.
Anehnya itu tampaknya sangat benar bagi saya sekarang. Saya pikir saya lebih terpengaruh oleh kompleksitas dan detail perangkat keras yang mendasari dan tingkat rendah saat ini daripada 30 tahun yang lalu, mencoba yang terbaik untuk melepas kacamata nostalgia. Tentu saja kami mungkin telah berbicara sedikit tentang perakitan di sini dan harus berurusan dengan beberapa detail mengerikan seperti XMS / EMS. Tetapi untuk sebagian besar saya akan mengatakan ada kurang kompleksitas dan perangkat keras dan kesadaran penyusun yang saya butuhkan saat itu daripada yang saya lakukan hari ini ketika saya bekerja di bidang yang sangat kritis terhadap kinerja. Dan itu hampir tampak benar bagi seluruh industri jika kita menyisihkan seperti menulisif/else pernyataan dengan cara yang sedikit lebih dapat dibaca secara manusiawi dan mempertimbangkan seberapa banyak orang pada umumnya saat ini lebih memikirkan detail perangkat keras tingkat rendah (dari beberapa inti hingga GPU hingga SIMD ke cache CPU dan rincian internal tentang bagaimana kompiler / juru bahasa mereka / perpustakaan berfungsi dan sebagainya).
Tingkat Tinggi! = Kurang Efisien
Kembali ke pertanyaan ini:
Jika ya, seiring dengan peningkatan perangkat keras haruskah kita mengharapkan bahasa tingkat lebih tinggi untuk mengambil alih industri game?
Bagi saya ini bukan tentang perangkat keras. Ini tentang pengoptimal dan alat. Ketika saya mulai orang praktis menulis semua game konsol dalam perakitan, dan ada keuntungan kinerja asli kemudian terutama mengingat kurangnya kompiler berkualitas menghasilkan 6502.
Ketika optimisasi kompiler C menjadi lebih pintar dalam optimasi mereka, maka mereka mulai mencapai titik di mana kode tingkat tinggi yang ditulis dalam C bersaing dan kadang-kadang bahkan mengungguli kode yang ditulis oleh para ahli perakitan terbaik di banyak bidang (meskipun tidak selalu), dan yang membuatnya jadi saat itu adalah no-brainer untuk mengadopsi C untuk setidaknya sebagian besar pengkodean untuk permainan. Dan pergeseran serupa secara bertahap terjadi di beberapa titik dengan C ++. Adopsi C ++ lebih lambat karena saya pikir peningkatan produktivitas pergi dari perakitan ke C mungkin bisa mencapai kesepakatan dengan suara bulat dari gamedevs yang menulis game non-sepele sepenuhnya di ASM sebagai lawan dari C ke C ++.
Tetapi perubahan ini tidak berasal dari perangkat keras yang menjadi lebih kuat karena pengoptimal untuk bahasa-bahasa ini membuat tingkat yang lebih rendah sebagian besar (meskipun tidak selalu sepenuhnya, ada beberapa kasus tidak jelas) usang.
Jika Anda dapat membayangkan skenario hipotetis di mana kita dapat menulis kode dalam kode tingkat tertinggi yang dapat dibayangkan, tanpa khawatir tentang multithreading atau GPU atau kehilangan cache atau semacamnya (mungkin bahkan bukan struktur data tertentu), dan pengoptimalnya seperti kecerdasan buatan pintar dan bisa mengetahui tata letak memori paling efisien menata ulang dan memadatkan data kami, mencari tahu itu bisa menggunakan beberapa GPU di sana-sini, memparalelkan beberapa kode di sana-sini, menggunakan beberapa SIMD, mungkin profil itu sendiri dan terus mengoptimalkan IR-nya seperti kita manusia menanggapi hotspot profiler, dan melakukan itu dengan cara yang mengalahkan para ahli terbaik dunia, maka itu akan menjadi no-brainer bahkan bagi mereka yang bekerja di bidang paling kritis untuk mengadopsinya ... dan itu adalah kemajuan datang dari pengoptimal yang sangat pintar, bukan perangkat keras yang lebih cepat.