Victoria 3 geliştirici günlüklerinde bu hafta 1.2 yamasında performans bakımından yapılan iyileştirmelerden bahsediliyor.

Selamlar. Bu haftanın Victoria 3 geliştirici günlüğüne hoş geldiniz. Bu sefer biraz performanstan ve oyun motorunun kaputun altında aslında nasıl çalıştığından bahsedeceğiz. Anlatış boyunca ayrıntılara değineceğiz ve çoğunlukla 1.2’de nelerin geliştiğiyle ilgileniyorsanız, aradığınızı sonlara doğru bulabilirsiniz.

Beni tanımayanlar için söyleyeyim, adım Emil ve 2018’den beri Paradox’tayım. Victoria 3 ekibine 2020 yılında Teknik Lider olarak katıldım ve daha önce başka projelerde aynı rolde çalışıyordum.

Performans Nedir?

Öncelikle neyi kastettiğimize karar vermeden performans hakkında konuşmak zordur. Birçok oyun için bu, çoğunlukla grafik ayarlarını çok fazla kısmak zorunda kalmadan ne kadar yüksek fps elde edebileceğinizle ilgilidir. Ancak PDS’de yaptığımız gibi simülasyon ağırlıklı oyunlarda başka bir özellik devreye giriyor. Yani tik hızı. Bu metrik, oyun endüstrisinde fps kadar tutarlı bir şekilde adlandırılmamıştır, ancak diğer bazı oyunlardan Saniye Başına Tik veya Saniye Başına Güncelleme adlarına aşina olabilirsiniz. Burada bunun yerine ters metriği ya da bir tikin saniye veya milisaniye cinsinden ortalama ne kadar sürede tamamlandığını kullanacağım. Bazı grafikler hata ayıklama derlemelerinden, bazıları ise mevcut sürüm derlemelerinden alınacaktır, bu nedenle sayılar her zaman doğrudan karşılaştırılabilir olmayabilir.

Oyun içi zaman açısından bir tikin tam olarak ne anlama geldiği biraz değişir. CK3 ve EU4’te bir tik tek bir gün iken, HOI4’te sadece bir saattir. Victoria 3 için bir tik altı saat veya bir günün çeyreğidir. Yine de tüm tikler eşit değildir. Bazı işlerin diğerleri kadar sık yapılması gerekmeyebilir, bu nedenle tik’leri kategorilere ayırıyoruz. Victoria 3’te yıllık, aylık, haftalık, günlük ve (düzenli) tiklerimiz var.

Eğer 1.1 sürümünün yavaş olduğunu düşünüyorsanız, oyunu piyasaya sürülmeden bir yıl önce görmeliydiniz…

Bir Tikin İçeriği

Victoria 3 oldukça simülasyon odaklıdır ve bu nedenle tik içinde gerçekleşmesi gereken çok fazla iş vardır. Kodu düzenli tutmak için tikimizi tik görevleri dediğimiz gruplara ayırdık. Bir tick görevi, ne sıklıkta gerçekleşmesi gerektiği ve çalışmasına izin verilmeden önce hangi diğer tick görevlerine bağlı olduğu hakkında bilgilerle birlikte oyun durumu üzerinde gerçekleştirilecek farklı bir dizi işlemdir.

Oyundaki bazı tik görevlerine genel bir bakış. Konsol komutu TickTask.Graph ile kullanılabilir.

Tik görevlerinin çoğu sadece bir veya birkaç değeri güncelleyen küçük şeylerdir. Öte yandan bazıları oldukça büyüktür. Ne sıklıkta çalıştıklarına ve hangi oyun nesneleri üzerinde çalıştıklarına bağlı olarak oyun hızı üzerindeki etkileri değişecektir. Oyundaki en maliyetli şeylerden biri istihdam güncellemesidir, bunu nüfus ihtiyacı cache güncellemesi ve modifier güncellemesi takip eder.

Şubat 15 itibariyle günlük derlenen sürümlerde yaptığımız testlerimizde en maliyetli on tik görevi. Saniye cinsinden sayılar, hata ayıklama derlemesi kullanılarak birden fazla çalıştırmanın ortalaması alınmıştır.

Yukarıdaki grafikten de görebileceğiniz gibi, en maliyetli tik görevlerimizin çoğu haftalık olarak yürütülmektedir. Bu durum, haftalık tick’in tüm günlük ve diğer tick görevlerini de içerdiği gerçeğiyle birleştiğinde, genellikle oldukça uzun sürdüğü anlamına gelir. O halde haftalık tik sırasında neler olup bittiğini biraz daha derinlemesine inceleyelim. Bunu yapmak için bir profilleyici kullanabiliriz. PDS’de kullandığımız profilleyicilerden biri, özellikle oyun geliştirmeyi hedefleyen açık kaynaklı bir profilleyici olan Optick’tir.

Mevcut sürümden 1890’lar civarında Optick ile yakalanmış profil örneği.

Yukarıdaki ekran görüntüsünde çok fazla şey var, bu yüzden biraz ufak parçalara parçalayalım. Sol tarafta baktığımız iş parçacıklarının adlarını görüyorsunuz. İlk olarak oyun mantığının ana iş parçacığı olan Network/Session iş parçacığı var. Simülasyonu çalıştırmaktan ve oyuncu komutlarına göre hareket etmekten sorumludur. Sonra birincil görev iş parçacıklarımız var. Bu sayı makineden makineye değişecektir çünkü motor işlemcinizin kaç çekirdeğe sahip olduğuna bağlı olarak farklı sayıda görev iş parçacığı oluşturacaktır. Burada, işleri daha okunabilir hale getirmek için yapay olarak sekiz ile sınırlandırdım. Görev iş parçacıkları paralelleştirilebilecek işleri yapmaktan sorumludur. Sonra Ana İş Parçacığımız var. Bu, oyun başladığında işletim sistemi tarafından oluşturulan ilk iş parçacığıdır ve arayüz ve grafik güncellemelerini işlemekten sorumludur. Daha sonra gerçek render işlemini yapan Render İş Parçacağı ve son olarak da ikincil görev iş parçacıklarımız vardır. Bunlar birincil olanlara benzer ancak genellikle grafik güncellemesine yardımcı olmak veya oyunu kaydetmek gibi oyun mantığı olmayan şeylerden sorumludur.

İçlerinde metin bulunan tüm renkli kutular, profil oluşturucuda görünmesini sağlayacak kadar ilginç bulduğumuz kodun farklı bölümleridir. Daha da derinlemesine bir inceleme istiyorsak, bunun yerine Superluminal veya VTune gibi doğrudan fonksiyon seviyesine ve hatta assembly’ye bakmamızı sağlayacak farklı bir profilleyici kullanabiliriz.

Pembe çubuklar bir iş parçacığının bir şey beklediğini gösterir. Görev iş parçacıkları için bu genellikle daha fazla iş bekledikleri anlamına gelirken, oturum iş parçacığı için genellikle oyun durumunu değiştirmesinin engellendiği anlamına gelir çünkü arayüz veya grafik güncellemelerinin ondan okunması gerekir.

Tik hızına bakarken çoğunlukla oturum iş parçacığı ve birincil görev iş parçacıkları ile ilgileniriz. Haftalık tikte neler olup bittiğini görebilmemiz için oturum başlığını burada genişlettim. Burada göze çarpan bazı şeyler var.

İlk olarak, yaygın olarak meydana gelen kırmızı CScopedGameStateRelease bloklarımız var. Bunlar, arayüzün ve grafiklerin mümkün olduğunca 60 fps’ye yakın render almaya devam etmek için ihtiyaç duyduğu verileri okumasına izin vermek için güncellemeye ara vermemiz gereken zamanlardır. Ancak bu her yerde gerçekleşemez, tik görevleri arasında veya tik görevleri içindeki belirli adımlar arasında sınırlıdır. Bu, veri tutarlılığını garanti etmek içindir, böylece arayüz, ülke bütçesinin sadece yarısı güncellendiğinde veri getirmez.

Göze çarpan bir sonraki şey, yukarıdaki grafikte görüldüğü gibi yine UpdateEmployment tik görevidir. Ancak burada biraz daha fazla bilgi ediniyoruz. Sadece bir bakışta (en azından) iki parçaya bölündüğünü görebiliriz. Bir paralel ve bir seri. İdeal olarak tüm işlerin paralel olarak yapılmasını isteriz çünkü bu modern işlemcileri daha iyi kullanmamızı sağlar. Ne yazık ki, nüfus nesneleri oluşturma ve yok etme ve komut dosyası yürütme gibi küresel işlemler yapması gerektiğinden, istihdam sırasında devam eden her şey paralel olarak yapılamaz. Bu yüzden seri kısmı mümkün olduğunca azaltmak için mümkün olduğunca paralel bir ön adıma ayırdık. Aslında arada çok hızlı olduğu için görülemeyen üçüncü bir adım var ancak paralel yürütme sırasının çok oyunculu oyunlarda oyun istemcileri arasında senkronizasyon sorunlarına neden olmasını önlemek için arada bir sıralama adımımız var.

UpdateEmployment tik görevine daha yakından bakın.

Değiştiriciler Yavaştır

PDS oyunlarında yaygın olan bir kavram değiştiricilerdir ve Victoria 3 de bir istisna değildir. Tam tersi. CK3 ile karşılaştırıldığında değiştirici kurulumumuz yaklaşık bir kat daha karmaşık. Bunu yönetmek için Stellaris’e benzer, değiştirici düğümleri adını verdiğimiz bir sistem kullanıyoruz. Özünde bu, değiştiricileri kirli olarak işaretlememize ve yalnızca kirli olan ve ona bağlı olan diğer değiştiricileri yeniden hesaplamamıza olanak tanıyan bir zincir yönetim sistemidir. Bir değiştiriciyi yeniden hesaplamak biraz maliyetli olduğu için bu oldukça faydalıdır.

Bununla birlikte, bu sistem eskiden tek iş parçacığına çok yük bindiriyordu, bu da tikimizin büyük bir kısmının hala değiştiricileri güncellemek için harcandığı anlamına geliyordu. Bu geliştirici günlüğünün üst kısmındaki grafiğe bakarsanız, 2022’nin başlarında performansın oldukça hızlı bir şekilde arttığını görebilirsiniz. Buna katkıda bulunan ana etkenlerden biri, değiştirici düğüm hesaplamalarının paralelleştirilmesiydi. Hangi düğümlerin hangilerine bağlı olduğunu bildiğimizden, düğümleri her bir partinin yalnızca önceki partilere bağlı olduğu partilere bölebildiğimizden emin olabiliriz.

RecalculateModifierNodes tik görevine daha yakından bakın.

Her Boyutta Ülke Var

Bir tik üzerinde yapılan çalışmaların çoğunun dünyadaki her ülke için yapılması gerekir. Ancak Lüksemburg gibi küçük bir ülke ile Rusya gibi büyük bir ülke arasındaki büyük ölçek farkı nedeniyle bazı işlemler bazen bir ülke için diğerine kıyasla yüz kat daha uzun sürebilir. İşleri seri olarak yaptığınızda bu gerçekten önemli değildir çünkü tüm işlerin gerçekleşmesi gerekir ve hangisini önce yaptığınız gerçekten önemli değildir. Ancak işleri paralelleştirmeye başladığımızda, çok sayıda büyük ülkenin aynı iş parçacığında yer aldığı bir sorunla karşılaşabiliriz. Bu, tüm iş parçacıkları işlerini bitirdikten sonra hala bu son iş parçacığının bitmesini beklememiz gerektiği anlamına gelir. Bunu aşmak için tik görevlerinin güncellemenin her bir parçası için sezgisel bir maliyet belirleyebildiği bir sistem geliştirdik. Bu daha sonra beklenen hesaplama süresinin standart sapmasını kontrol ederek öne çıkan parçaları belirlememize ve bunları ayrı ayrı programlamamıza olanak tanır.

Bunun büyük fark yarattığı yerlerden biri de ülke bütçe güncellemeleridir. Örneğin Çin, Rusya ve Büyük Britanya’nın aynı iş parçacağında güncelleme yapmaması, bütçe güncellemesi için gereken süreyi önemli ölçüde azaltıyor.

(Ve bu aynı zamanda dünya fethi oyunlarınız sırasında oyunun daha yavaş çalışmasının nedenidir!)

WeeklyCountryBudgetUpdateParallel tik görevine daha yakından bakın. Maliyetli ve düşük maliyetli işlere dikkat edin.

1.2’deki Geliştirmeler

Çoğunuzun ilgilendiği kısmın bu olduğunu tahmin ediyorum. İrili ufaklı pek çok iyileştirme yapıldı.

Şu ana kadar açık betaya dikkat ettiyseniz, inşaat kuyruğuyla ilgili bazı arayüz değişikliklerini fark etmiş olabilirsiniz. Oyunu kaç kişi oynarsa oynasın, kuyruk oldukça büyük olabiliyor. Ne yazık ki buradaki eski arayüz, düzgün bir şekilde düzenlemek için tüm öğelerinin boyutunu hesaplaması gereken bir widget türü kullanıyordu. Ekranda görünmeyen öğeler de buna dahil.

Yeni inşaat kuyruğu arayüzü.

Sıraya alınan yapıların tamamlanana kadar geçen süre ve benzeri şeyleri hesaplamak için birbirlerine çok fazla bağımlılıkları vardı ve bu sorunu daha da karmaşık hale getiriyordu. Bu da ele alındı ve bugünün beta sürümünde mevcut olacak.

Eski ve yeni inşaat kuyruğunun alt alta karşılaştırması.

Tik hızındaki büyük bir gelişme, grafik güncellememizde yaptığımız değişikliklerin bir sonucudur. Oyunun ilerleyen bölümlerinde haritanın güncellenmesi bazen çok zaman alabiliyordu ve bu da oyun mantığının grafik güncellemesi için çok fazla beklemek zorunda kalmasına neden oluyordu. Grafik güncellemesi için gereken süreyi azaltmak amacıyla burada hem motor iyileştirmeleri hem de oyun tarafı kodumuzda değişiklikler yapıldı. Bunlardan bazıları harita adı güncellemesinin iş parçacığının iyileştirilmesi, hava varlığı güncellemesinin optimize edilmesi ve binaların şehir grafiklerinde nerede görünmesi gerektiğini bulmak için gereken çalışmanın azaltılmasıdır.

Grafik güncellemesinin optimizasyondan önceki ve sonraki hali.

Yukarıda bahsettiğimiz gibi, istihdam güncellemesinin performans üzerinde önemli bir etkisi vardır. Bu, oyundaki nüfus sayısı ile çok güçlü bir şekilde ilişkilidir. Nüfus grupları olarak ilişkili, toplam nüfus sayısı olarak değil. Özellikle oyunun sonlarında, istihdam güncellemesini son derece yavaşlatacak çok sayıda küçük nüfus grubu ile karşılaşabilirsiniz. Bu durumu hafifletmek için, oyunun küçük nüfus gruplarını ne kadar agresif bir şekilde birleştirdiğini ayarladık ve bu da oyunun sonundaki performansı artıracak. Modcular için bu durum POP_MERGE_MAX_WORKFORCE ve POP_MERGE_MIN_NUM_POPS_SAME_PROFESSION tanımları ile değiştirilebilir.

1.2 için yaptığımız bir diğer iyileştirme de Clausewitz’de bellek ayırma yöntemimizi değiştirmek oldu. Özel durumlar (havuz ayırıcılar, oyun nesnesi “veritabanları” vb.) için her zaman özel ayırıcılarımız olsa da, işletim sistemine ertelenen varsayılan ayırıcı ile sonuçlanan çok sayıda tahsis vardı. Ve özellikle Windows’ta bu yavaş olabiliyordu. Bunu çözmek için şimdi mimalloc adlı bir kütüphaneden yararlanıyoruz. Bu çok performanslı bir bellek ayırıcı kütüphanesidir ve temelde işletim sistemi tarafından sağlanan işlevselliğin yerine geçmektedir. Unreal Engine gibi diğer büyük motorlar tarafından zaten kullanılıyor. Yukarıdaki iki şey kadar önemli olmasa da, zaman çizelgesinin yaklaşık üçte ikisinde bir yıl boyunca ölçüldüğünde oyunun yaklaşık %4 daha hızlı çalışmasını sağladı. Ve bu bir motor iyileştirmesi olduğu için muhtemelen gelecekte bir gün CK3’te de görebilirsiniz.

Bu büyük değişikliklere ek olarak, bir araya geldiklerinde çok şey ifade eden birçok küçük iyileştirme de yapıldı. Sonuç olarak, aşağıdaki grafikte de görebileceğiniz gibi oyun 1.1’e kıyasla 1.2’de fark edilir derecede daha hızlı olacaktır. Ne yazık ki 1.1’de yaptığımız günlük derlenen sürümlerdeki testler 1.2 kadar istikrarlı değildi, bu yüzden netlik adına grafiği 1871’de kestim, ancak genel olarak 1.2’deki performans iyileştirmeleri oyunun sonlarında daha da belirgindir.

Yıllara göre 1.1 ve 1.2 arasındaki tik sürelerinin karşılaştırması, 1.2 çok daha hızlıdır. Rakamlar, hata ayıklama derlemeleri kullanılarak birkaç hafta boyunca yapılan çoklu günlük testlerden elde edilen yıllık ortalamalardır.

Bu hafta benden bu kadar. Gelecek hafta Nik, yeni Stratejik Hedefler özelliği de dahil olmak üzere 1.2’de savaş mekaniğinde yapılan çeşitli iyileştirmeleri sunacak.