Her zaman "mikro-optimizasyon" terimini oldukça belirsiz buldum. Bellek düzeninde ve erişim düzenlerinde bazı talimat düzeyinde değişiklikler, disiplinli bir profesyonelden sıcak noktalarını algoritmik karmaşıklıkta bir azalma olmadan ölçen 80 kat daha hızlı bir şey yaparsa, bu bir "mikro optimizasyon" mudur? Bana göre bu, gerçek dünyadaki kullanım durumunda 80 kat daha hızlı bir şey yapmak için kullanılan bir "mega optimizasyon". İnsanlar bu tür optimizasyonların mikroskobik etkileri olduğu gibi bunlar hakkında konuşma eğilimindedir.
Artık gamedev'de çalışmıyorum ama yol izleme gibi alanlarda VFX'de çalışıyorum ve karmaşık bir sahnede saniyede ~ 0,5 milyon ışın işleyen BVH ve KD ağaçlarının birçok uygulamasını gördüm (ve bu, çok iş parçacıklı değerlendirme). Kabaca konuşmak gerekirse, çok iş parçacıklı değerlendirme ile bile 1 milyon ışın / sn'nin altındaki ışın izleme bağlamında bir BVH'nin basit bir uygulamasını görme eğilimindeyim. Embree hariç aynı sahnede aynı donanım ile 100 milyondan fazla ışın işleyebilen bir BVH'ye sahiptir.
Bu tamamen Embree'nin 200 kat daha hızlı (aynı algoritma ve veri yapısı) olduğu "mikro-optimizasyonlardan" kaynaklanıyor, ancak elbette çok daha hızlı olmasının nedeni, arkasındaki Intel'deki geliştiricilerin profilerlerine ve ölçümlerine ve gerçekten önemli olan alanları ayarladım. Onlar önsezi dışında willy-nilly kodunu değiştirmediler ve değişiklikleri önemli ölçüde düşüren sürdürülebilirlik pahasına% 0.000000001 iyileştirmeler yaptılar. Bunlar, akılcı ellerde uygulanan çok hassas optimizasyonlardır - odak açısından mikroskopik, etki açısından makroskopik olabilirler.
Doğal olarak, oyun motoruyla ne kadar yüksek veya düşük seviyede çalıştığınıza bağlı olarak oyunların gerçek zamanlı kare hızı gereksinimleriyle (UE 4 ile yapılan oyunlar bile en azından kısmen yüksek seviye komut dosyasında uygulanır, ancak, fizik motorunun en kritik kısımları değil), mikro optimizasyonlar belirli alanlarda pratik bir gereklilik haline gelir.
Bizi her gün çevreleyen bir diğer temel alan, yüksek çözünürlüklü görüntüleri gerçek zamanlı olarak bulanıklaştırmak ve belki de muhtemelen bir yerde gördüğümüz bir geçişin bir parçası olarak, belki de bir OS etkisi gibi görüntü işleme. Bu tür görüntü işlemlerini sıfırdan bir görüntünün tüm pikselleri arasında döngüden yürütmek ve bu gibi gerçek zamanlı sonuçları eşleşen kare hızlarında bekleyemezsiniz. CPU ise, genellikle SIMD'ye ve bazı mikro ayarlara bakıyoruz veya etkili bir şekilde yazmak için mikro düzeyde bir zihniyet gerektiren eğilimli GPU gölgelendiricilerine bakıyoruz.
Cevabınız evetse, donanım geliştikçe daha üst düzey dillerin oyun endüstrisini devralmasını mı beklemeliyiz?
Donanım gelişmelerinin bunu yapabileceğinden şüpheliyim, çünkü donanım ilerledikçe, talimatlar ve teknoloji de (ör: GPU'da fizik) ve teknikler ve görmek istedikleri şey ve rekabet için müşteri beklentileri de web geliştiricilerinin artık WebGL'de düşük seviyeli GLSL gölgelendiricileri yazdığı gibi, genellikle geliştiricilerin tekrar düşük seviyeye gitme yolları (bu türden web geliştirme, muhtemelen on veya iki yıl öncesine göre daha düşük seviyededir) GLSL son derece düşük seviyeli C benzeri bir dildir ve bazı web geliştiricilerinin böyle düşük seviyeli GPU gölgelendiricileri yazmayı kucaklayacağını asla tahmin edemezdim.
Performans açısından kritik alanların daha üst düzey dillere geçmesi için bir yol olacaksa, gördüğüm yazılım ve derleyicilerden ve araçlardan daha fazla gelmek zorunda kalacak. Öngörülebilir bir gelecekte benim için sorun, donanımın yeterince güçlü olmaması değil. Kendi diline geri dönmeden her değiştiğinde ve ilerlediğinde onunla en etkili şekilde konuşmanın yollarını nasıl bulamayacağımızla daha fazla ilgilidir. Aslında, gördüğüm gibi, bu alanlar için yüksek seviyeli programlamayı oldukça zorlaştıran donanımın değiştiği hızlı tempo, çünkü varsayımsal olarak donanımımız önümüzdeki on yıllar boyunca maviden ilerlemeyi bıraktıysa,
Bugünlerde, performans açısından kritik öneme sahip alanlarda çalıştığım zaman, (Borland Turbo C DOS döneminde başlamış olmama rağmen) başladığımdan biraz daha düşük seviyede düşünmek zorundayım. Çünkü o zamanlar CPU önbelleği neredeyse yoktu. Çoğunlukla sadece DRAM ve kayıtlardı, bu da algoritmik karmaşıklığa daha fazla odaklanabileceğim ve ağaçlar gibi bağlantılı yapıları çok fazla performans göstermeden çok basit bir şekilde yazabileceğim anlamına geliyordu. Bu günlerde CPU önbelleğinin düşük düzeyli ayrıntıları, neredeyse algoritmanın kendisi kadar benim düşünceme hakim. Aynı şekilde, çok iş parçacıklı ve atomik ve muteksler ve iş parçacığı güvenliği ve eşzamanlı veri yapıları vb. insani sezgisel değil).
İşin garibi şu an benim için çok doğru görünüyor. Sanırım bugün donanımın altta yatan ve düşük seviyeli karmaşıklıklarından ve ayrıntılarından 30 yıl önce olduğundan daha fazla etkilendim ve nostalji gözlüklerini çıkarmak için elimden gelenin en iyisini yapmaya çalışıyorum. Tabii ki burada biraz montajdan söz etmiş olabiliriz ve XMS / EMS gibi bazı ayrıntılarla uğraşmak zorunda kalabilirdik. Ancak çoğunlukla, performans açısından kritik alanlarda çalışırken bugüne kadar ihtiyacım olandan daha az karmaşıklık ve donanım ve derleyici farkındalığı olduğunu söyleyebilirim. Ve yazmak gibi bir kenara bırakırsak, bu neredeyse tüm endüstri için doğru görünüyorif/else ifadelerini biraz daha insanca okunabilir bir şekilde okuyun ve bu günlerde genel olarak ne kadar insanın donanımın daha düşük düzey ayrıntıları hakkında daha fazla düşündüğünü düşünün (birden fazla çekirdekten GPU'lara, SIMD'den CPU önbelleğine ve derleyicilerinin / yorumlayıcılarının / kütüphaneler çalışır vb.).
Yüksek Seviye! = Daha Az Verimli
Bu soruya dönersek:
Cevabınız evetse, donanım geliştikçe daha üst düzey dillerin oyun endüstrisini devralmasını mı beklemeliyiz?
Benim için bu donanım ile ilgili değil. Optimize ediciler ve araçlar hakkında. Başladığımda insanlar tüm konsol oyunlarını montajda yazdılar ve özellikle 6502 üreten kaliteli derleyicilerin eksikliği göz önüne alındığında gerçek bir performans avantajı vardı.
Optimizasyon C derleyicileri optimizasyonlarında daha akıllı hale geldiklerinde, C'de yazılan daha yüksek seviyeli kodun rakip olduğu ve bazen de her zaman olmasa da en iyi montaj uzmanları tarafından yazılan koddan daha iyi performans gösterdiği bir noktaya ulaşmaya başladılar ve bu nedenle, en azından bir oyun kodlamasının büyük kısmı için C'yi benimsemek bir beyinsizdi. Ve benzer bir değişim C ++ ile bir noktada yavaş yavaş oldu. C ++ benimsemesi daha yavaştı çünkü meclisten C'ye gitmenin verimlilik artışı, C'den C ++ 'ya gitmekten ziyade tamamen ASM'de önemsiz oyunlar yazan gamedev'lerden oybirliğiyle anlaşmaya varabileceğini düşünüyorum.
Ancak bu değişimler, donanımın daha güçlü hale gelmesinden kaynaklanmadı, çünkü bu diller için optimize ediciler daha düşük seviyeye gitmeyi büyük ölçüde (her zaman tamamen olmasa da, bazı belirsiz durumlar var) geçersiz kılıyor.
Çoklu iş parçacığı veya GPU'lar veya önbellek özledikleri veya bunun gibi herhangi bir şey (belki de belirli veri yapıları bile değil) ile ilgili hiçbir endişe olmadan, akla gelebilecek en üst düzey kodda kod yazabileceğimiz varsayımsal bir senaryo hayal edebiliyorsanız ve optimize edici yapay zeka gibiydi. akıllıdır ve verilerimizi yeniden düzenleyen ve düzenleyen en verimli bellek düzenlerini çözebilir, burada ve orada bazı GPU'ları kullanabileceğini, burada bazı kodları paralelleştirebileceğini, bazı SIMD kullanacağını, belki de profilin kendisini ve IR'yi insanlar olarak daha da optimize edebileceğini anlayabilir profiler hotspot'larına yanıt veriyor ve bunu dünyanın en iyi uzmanlarını yenecek şekilde yaptı, o zaman bunu benimsemek için en kritik performans alanlarında çalışanlar için bile beyinsiz olurdu ... ve bu bir gelişme gülünç akıllı optimize edicilerden geliyor, daha hızlı donanım değil.