Performansı değerlendirmek için en iyi zaman ne zaman?

45

Yazılım geliştirme geçmişinden geliyorum. Yazılım geliştirme döngüsü boyunca, genellikle işlevsellik ve çalışan ürün üzerinde durulur. Geliştirme sonunda, kodu optimize etmeye ve performansı artırmaya başlarız.

Şimdi soru şu ki, oyun geliştirmedeki her kod satırındaki performansı düşünmemize gerek var mı?

Bunu yaparken tasarım kalıplarını ve temiz kodu özlediğimizi hissediyorum. Oyun geliştirme endüstrisinde en iyi uygulama yaklaşımının olup olmadığını merak ediyor muydum?

— Emad
kaynak

8

Erken optimizasyonla ilgili bu önceki soruyla ilgili tartışmayı faydalı bulabilirsiniz.

— DMGregory

10

Başlangıçta. Proje sürdükçe, performans daha da kötüleşecek.

— Tomáš Zato

10

Geldiğiniz yazılım geliştirme geçmişi sağlıklı gelmiyor. Tasarımlar, tüm alanlarda geçerli olan performans değerlendirmelerini dikkate almalıdır. Kaç tane ağ turu gezisi, kaç tane ve ne kadar büyük veritabanı sorgusu, ne kadar bellek kullanılmış vb. Bunu hangi mühendislik alanında yaptığınız önemli değil; Eğer performans planlaması başarısız olursa, performans başarısızlığı planlıyorsunuz.

— Jon Watte

1

Herşey. . Zaman. Sadece her zaman yaparak kendinize zamandan ve sıkıcı işlerden tasarruf edin; kodu daha önce olduğundan daha fazla optimize etmeye çalışarak (gerekirse) daha havalı ve geeky işler yaparken kendinizi çok güzel ve zorlu işler yaparken görürsünüz. Eğlencenin başladığı yer.

— Yates

6

"Göz önünde bulundurma" performansı , kullanıcıları olan bir ürün yapmaya karar verdiğiniz gün yapılmalıdır . Kullanıcıların minimum performans beklentileri vardır ve karşılanmazlarsa ürününüz başarısız olur. Performansın maliyeti vardır ve ürünlerin bütçeleri vardır . Kabul edilebilir asgari performans bütçenizden daha yüksekse, projeniz başarısız olur . Bunu düşünmek akıllıca, birinci günde değil, yüz günde.

— Eric Lippert

90

Performans için Mühendislik

Satıcı tavsiyelerine uyun.
Doğru veri yapılarını kullanın.
Doğru kullanım modellerini uygulayın.
Aptalca bir şey yapma.

Optimizasyon

Zaten yazılı kod yavaş çalışıyorsa, ölçün, nedenini bulun, hızlı hale getirmek için neyin gerekli olduğunu uygulayın.

Erken Optimizasyon

Ölçümler olmadan neyin hızlı ya da yavaş olduğu konusunda varsayımlarda bulunun, bu varsayımları kodun nasıl tasarlanıp yazıldığına yerleştirin.

Bu üç şey aynı değildir .

Özellikle Performans Mühendisliği , en baştan yapmanız gereken bir şeydir ve kesinlikle Gerçeklik Ölçümleri ile aynı olduğu için Erken Optimizasyon ile aynı değildir ; Bu durumda, donanımın nasıl çalıştığına ve hangi kullanım modellerinin hızlı veya yavaş olacağına ilişkin deneyimler ve tavsiyeler üzerine düşünün.

Performans için mühendisliği yapmak, sonuçların tamamen yeniden tasarlanmasına ihtiyaç duymak kadar kötü sonuçlara yol açabilir ve bir şeylerin yanlış olduğunu fark ettiğinizde yeniden yazabilirsiniz.

Örneğin: tüm GPU satıcıları, her karede GPU'dan yeniden okuma yapmanın yavaş olduğunu tavsiye eder. Kodunuzu geri okuma yapmamak için tasarlamak erken optimizasyon değildir .

— Maximus Minimus
kaynak

28

Bunu söylediğiniz için çok teşekkür ederim. Geliştiriciler, her zaman erken optimizasyonun kötülüklerini, noktayı vurgulamak için son derece ifade edilen tavsiyelerde bulundular, ancak çoğu zaman daha az deneyimli geliştiriciler nüansı anlamıyor. En baştan doğru tasarlayın. Bu erken optimizasyon DEĞİL. Diyelim ki yazdığınız her satır için performans bilincinde olmalısınız. Bir geliştirici olarak, aptalca şeyler yapmamanız için en iyi uygulamaların farkında olmalısınız. Bununla birlikte, optimizasyonla kendinizi felç etmemelisiniz. Önce koşacak bir şey bul, sonra yavaşlayan şeye odaklan.

— AC

2

Ayrıca, iyi bir tasarımın başlaması için zaman alabileceğini de belirtmek isterim ama sonunda sonuçta daha hızlı bir şekilde bitmiş olacağınız anlamına gelir, bu da gerekirse optimizasyon için daha fazla zaman anlamına gelir. Tecrübelerim (bunu desteklemek için yarı yarıya yapılan tek başına bir hobi projesiyle), projeniz yeterince genişlediğinde, büyük zaman tüketimi 1) "Bunu zaten orada olan herşeye nasıl öreceğim" ve 2) "Kahretsin, bir hafta önce yazdığım kod, tam olarak uyan, sonra ne yapmak istediğimle hiç çalışmıyor". İyi tasarım (yapmadım) her ikisine de yardımcı olur.

— Arthur,

5

Performans için doğru bir şekilde mühendisliği yapamamak, tasarımı karamsarlaştırmak olarak da düşünülebilir. Öyleyse, erken optimizasyon tüm kötülüklerin kökü ise , bu erken pesimizasyonun sebebi nedir? P

— ninjalj

1

@Arthur "optimizasyon için daha fazla zaman kaldı"? Bu, ona bakmak için iyi bir yoldur, kendi sınırlı geliştirme kaynaklarınızı (ve iş akışını) optimize eder, böylece optimizasyon çabalarınızdan optimum etki elde edersiniz! Ayrıca, Yığın Taşması konusunda uygun olmadığımızı da biliyorum, ancak optimizasyondan bahsetmemizi şaşırtıyor ve Pareto Prensibi henüz bir cevapta bahsedilmedi bile ... "Yüzde" kelimesini bile görmüyorum!

— AC

1

Veri yapılarınızı iyi performans için tasarlarken, bilgisayarların verimli şekilde yapabileceklerini ve yapamadıklarını bilmeniz gerekir. Örneğin, diziler üzerinde döngü yapan modern CPU'lar, özellikle derleyiciler SSE / AVX ile otomatik olarak vektörleşebilsinler diye büyük miktarda kaba kuvvet uygulayabilir. (örneğin x koordinatlarına ve y koordinatlarının, xy çifti yapılar veya xyz üçe değil Dizilerin diziler kullanımı diziler bakın. stackoverflow.com/tags/sse/info özellikle bazı bağlantılar için Insomniac Games SIMD (2015 GDC)

— Peter Cordes

22

Doğru zamanlarda optimizasyon yapmak istiyorsanız, yavaş makinelere sahip olun ve bunları kullanın. Küçük bir dükkan için, gidip gelmek için yavaş bir dizüstü bilgisayar ve ofisteki hızlı bir masaüstünü kullanmak iyi bir seçenek. Ek bir avantaj olarak, tek kişilik bir mağazaysanız, bu sizi tüm yapı ortamını düzgün bir şekilde yedeklemeye zorlar.

Yavaş bir makine kullanarak performansı ne zaman arttırmanız gerektiğini bilirsiniz.

Oyun geliştirmedeki her kod satırındaki performansı düşünmemize gerek var mı?

Kesinlikle hayır. Bir kod satırının performansı, herhangi bir gelişimde genellikle alakasızdır. Satırlar yerine , algoritmalar ve algoritmik karmaşıklık açısından düşünmeniz gerekir . Pek çok durumda, düzgün programlama, kod satırlarını optimize ederek yaklaşık 2 kat daha fazla hız alabileceğiniz anlamına gelir, ancak doğru veya yanlış algoritmayı seçmek, onlarca ve milyonlarca faktöre neden olur.

Erken optimizasyon hakkında konuşmak aslında optimizasyonun kötü bir şey olduğu ile ilgili değil. Doğru şeyi optimize etmekte başarısız olan insanlar hakkında. Zamanınız, optimize edilmesi gereken değişkenlerden biridir; bu, her 30 milisaniyede bir çağrılan ve yürütülmesi için 100 mikrosaniyelik bir işlevi "optimize etmek" için zaman harcayarak elde edilir.

Başka bir deyişle: "Daha hızlı" bir şey yapmak anlamsızdır. Amacınız "yeterince hızlı". Zaten "yeterince hızlı" olan bir şeyi "hızlı" yapmak, zaman kaybıdır ve hala "yeterince hızlı" olmayan "daha hızlı" bir şeyi yapmak, hala çok yavaş olduğu anlamına gelir. "daha hızlı" alakasız, sadece "yeterince hızlı" alakalı.

— Peter
kaynak

1

algoritmalar çözümün sadece yarısıdır, veri yapılarının doğru kullanımı da çok önemlidir. Ayrıca, çoklu okuma ve 64 bit derlemesini tanıtmak için önceden plan yapın; her durumda gerekli olmasa da, bazen bu özellikler önemlidir ve genellikle planlanmadıkça geriye dönük olarak takılması kolay / ucuz değildir. (Bu iki sorunun da muzdarip olduğu bazı oyunlar biliyorum.).

— Hoffmale

Sürüm sürümünden çok daha yavaş olan Debug sürümleri ile çok fazla gelişme yapılır. Bu, geliştirme için oyunu kabul edilebilir bir hızda çalıştırmak için gerekenden çok daha hızlı bir makinenin gerekli olduğu anlamına gelir.

— Jack Aidley,

Önbellek erişim düzenleri de önemlidir ve 10 veya 100 fark faktörleri yapabilir. örneğin, bir saf matris çarpımını düşünün (büyük bir matris için). Bir satır majör matrisin bir sütunu üzerinde döngü yapmak korkunçtur. örneğin, bu soru-cevap , sadece korkunç erişim modelini sabitlemek için ilmeklerden önce bir transpozisyon eklemek için aynı algoritmik karmaşıklık için 13 perf fark faktörüne sahiptir. (Önbellek ve SIMD hakkında daha da fazla önem veren, optimize edilmiş bir BLAS kütüphanesinden 10 veya daha fazla başka bir faktör elde edilebilir ...)

— Peter Cordes

9

Hayır, her satırdan sonra kontrol etmeniz gerekmez, çünkü her satır performansla ilgili değildir. Çoğunlukla bir çizginin ne sıklıkla yürütüldüğüne bağlıdır. Yürütülmesi 1 msn süren bir kod bölümü, oyun başlangıcında bir kez çalıştırıldığında, her karenin yürütülmesi sırasında izlemeye değerdir ve her karenin her oyun nesnesi için çalıştırıldığında kesinlikle iyileştirilmesi gerekir.

Aynı zamanda ne tür bir oyun geliştirdiğinize de bağlı. Çok yoğun grafikli bir 3d nişancı geliştirirken, retro tarzı bir RPG oyunu programladığınızdan çok daha fazla performans farkında olmanız gerekir.

Sonunda en iyi tavsiye test, test, testtir. Oyununuz için, gerçek oyunda beklenenden biraz daha fazla şey bırakan gerçekçi test sahneleri oluşturun. Hedeflediğiniz özelliklerin altında bulunan donanımda test edin. Performansın beklendiği gibi olduğundan emin olun. Kötüleştiğinde, tıkanıklıkları bulmak için bir profiler kullanın.

— Philipp
kaynak

3

En azından gitmek için yeterince çaba sarf etmeniz gerekiyor "bu potansiyel olarak bir darboğaz olacak ve eğer öyleyse, bunu düzeltmek için ne kadar bir değişiklik söz konusu olacak?"

Genel olarak konuşursak, bu bir şeyin doğru yönde olup olmadığını anlamak için harcanan zaman / kaynaklar ile kötü kararları almak için harcanan zaman / kaynaklar arasındaki dengeyi içerir.

Bir daireyi yenilemek gibi biraz düşünün. Bazı kararlar kalıcı sonuçlar verebilir ("Boynuzlar, buzdolabı artık dolabına uymuyor" örneğin binanın yapısal dengesini etkileyebilir.

Ya da başka bir deyişle, kendinizi bir köşeye sokmayın. Veya en azından kendinizi bir köşeye döndüğünüzde bilir ve geri dönmesini istediğiniz köşenin bu olduğundan emin olun. Örneğin:

Oyun güncelleme oranını grafik kare hızına mı bağlıyorum?
Eşzamanlı kaydetmeye zorluyorum mu?
Belirsiz (belirsiz) ben mi zorluyorum?

— TLW
kaynak

1

Bir oyun için, birincil hedefiniz, hedef minimum özellik makinesinde (ve muhtemelen maksimum yükleme süresi vs.) hedef kare hızına ulaşmaktır.

Bunu yapmak için, hayır, her satırdan sonra endişelenmenize gerek yok.

Belirli bir strateji, algoritma veya kapsayıcı seçtiğinizde erken endişelenmeniz gerekir. Yetersiz tasarım kararları vererek hedefi tam anlamıyla karşılamayı imkansız hale getirirseniz, daha sonra yapabileceğiniz herhangi bir optimizasyon boşuna olmaz.

Daha sonra, bir şey paralel veya paralelleştirilebilir olduğunda endişelenmeniz gerekir . Oyunlar büyük ölçüde paraleldir, başka bir nedenden ötürü, o zaman grafik çünkü.
Bu nedenle, paralel sadece "thread" anlamına gelmez, aynı zamanda örneğin grafik API, disk erişimi veya ağ. Bir şey olmasının fırsatı kaçırmak zaman olabilir nedeniyle kötü senkronize örneğin kolayca ve doğal olarak paralel parallelized çalıştırmak gibi, (ya ödenmesi gereken bir asenkron API kullanarak değil), diğer yollarla sizden daha hiç optimize fazla kaybederler.
Ayrıca bir şey ne zaman endişelenmelisinbir tıkanıklık veya bir durak kaynağı, ya da ölçeklendirmenin önlenmesi olarak bilinir. Örneğin, oluşturma durumlarını değiştirmek, çağrılar yapmak, GPU'dan geri okumak veya dosyaları açmak gibi.

Son, işiniz bittiğinde ve sen bunu gösterir test yok hedef kare hızını karşılamak, sen optimize gerekir. Zamanın% 90'ını alan en büyük darboğazı bulun ve bunu optimize edin. Bu yeterli değilse, en büyük saniyeyi bulun.
Hedefi gerçekleştirirseniz tebrikler. Devam et ve unut gitsin.

— Damon
kaynak

0

Gerçekçi ol. Cevap basitçe tamamen HAYIR. Tartışma yok.

Asıl sorun, sorma şekliniz:

Oyun geliştirmedeki her kod satırındaki performansı düşünmemize gerek var mı?

Ayrıca yapılandırma ekranları gibi şeylerde de demek istiyorsun? Küçük bir 1kb max config dosyası için tek seferlik bir çözümleyici gibi mi? Ciddi anlamda?

Kodunuzun çoğu zaman ne kadar kritik olduğu önemli değil. Her bir satırın zaman açısından kritik olduğu tek bir yazılım yoktur. Hiçbir yerde.

— TomTom
kaynak