Big O gerçekten önemli mi?

Akademi'de en kötü durumda Big O diğer her şey üzerinde öğretilir. Alan karmaşıklığı, normal vaka analizi, karmaşıklığa göre basitlik vb.

Özellikle oyun programlama ve endüstrisi için en önemli olan nedir ve neden?

Referanslar çok yardımcı olacaktır.

"Tek Doğru Yol nedir" ile ilgili diğer tüm sorularda olduğu gibi , bunların hepsi araç kutunuzdaki araçlardır ve big-O'nun her şeyi ve önemli olmayan yerleri (tm) koyduğu durumlar vardır.

Big-O hakkında endişelenmeden bir fizik çözücü "asla" yazmazsınız. Endişelenmeden bir sıralama algoritması (en küçük veri kümeleri hariç herhangi biri için) uygulayamazsınız. Ağa bağlı bir oyun yazıyorsanız, kullanıcı başına performans ve ağ trafiğinin ölçeklenme şekli ile ilgileneceksiniz.

Büyük bir zaman konusunda o kadar endişelenmeyebilirsin, aslında, gerçekten bir zaman düşünemiyorum ama eminim biraz var. :) Neyse ki, oyunlarda yaptığımız şeylerin çoğu doğrusal olarak ölçekleniyor; diskten bir dosya mı okumak istiyorsunuz? Dosya boyutuyla doğrusal orantılı olarak biraz zaman alacaktır (sürekli arama faktörünü ve sektör boyutunun olası sonuçlarını iskonto etmek).

Ancak, varlık listesinde belirli bir varlığı bulmak isterseniz ne olur? Bu, her yaptığınızda doğrusal bir aramadır. Oynatıcıyı dünyadaki her varlık için bir kez bulmanız gerekiyorsa, bu yaklaşım sizi en önemsiz oyunlar hariç herkes için öldürecek ve o zaman bile bu aramayı sabit zaman olarak "optimize etmeye" değer (örn. oynatıcının veya bir yere bir göstericinin) göstererek, oynatıcının gerçekten görebileceği başka şeyler yapmak için daha fazla zaman tanır.

Sanırım bu özetliyor; işlemci, oynatıcıyla doğrudan temsil edilemeyen bir şey yaptığında zaman kaybediyor. İşlemcinin oynatıcıya gösterilecek verileri hesapladığı süreyi en üst düzeye çıkarmak WOW! oyuncuya veriyorsun.

Temel kuralım, siz O (korkutucu) değilseniz, diğer sorunlarınızın daha ilgili olduğudur.

Diğer önemli kuralım da verinin kraldır. Kodunuzu gerçekçi bir veri kümesiyle profillemediğiniz sürece, sadece tahminlerde bulunuyorsunuz.

Düzenleme: Biraz daha ayrıntıya girmek için, büyük O'nuz o kadar önemli değil (en azından benim deneyimime göre) veri kümelerinizin çoğu nispeten küçük. Birkaç yüzden daha az öğeye sahip bir veri yapısı ile çalışırken muhtemelen üst performans sınırınızı önemsemezsiniz. Listeleriniz 100k + elemente sahipse, algoritmalarınızın tüm yönlerini gerçekten dikkate almanız gerekir. Bu ve tecrübelerime göre bellek CPU hızından daha sınırlayıcı bir faktör. Daha hızlı bir bellek atma algoritması, kullanım durumunuza bağlı olarak daha yalın değil, daha yavaş bir algoritma olabilir.

Big O çoğu zaman önemlidir, ancak bazen teoride görünüşte "daha kötü" bir algoritma pratikte çok daha hızlı olur.

Tony Albrecht'ten harika bir örneği inceleyin: http://seven-degrees-of-freedom.blogspot.com/2010/07/question-of-sorts.html

Bunu, işlemdeki öğelerin sayısının çok farklı bir algoritmanın daha hızlı olacağı kadar büyük olduğu veya bir sayı algoritmasının yeterli olduğu (veya önbelleğe sığdığı kadar verimli olduğu) oyun geliştirmede her yerde bulabilirsiniz. ... daha iyi bir algoritma).

Big O ile ilgili sorun, görevin karmaşıklığının genel bir tanımı ve modern hedef donanımın karmaşıklığını dikkate almaması veya kurulum süresi yükü hakkında herhangi bir fikir sunmamasıdır.

Çoğu durumda, en uygun çözüm iki adımdır. Uygulamada, oyun geliştiricileri düşük O algoritmalarına yönelme eğilimindedir, ancak zaman geliştirme veya hata ayıklama sırasında maliyetle dengelenmiştir. Makul bir çözüme sahip olduğunuzda, her zaman donanımın görevi nasıl ele aldığını ve donanımın daha kısa sürede daha fazla iş yapmasını nasıl sağlayacağınıza bakmanız gerekir.

Ben-motor kodlama ediyorum, ben genellikle sadece sabit ilgilenen ediyorum n: Zaten alıcı nesne sayısını sınırlayan bir mekansal bölüm var update(), physics()ve render()ekran ve çevresinde yaklaşık olanlara. Maksimum parti boyutu genellikle oyun başına oldukça iyi tanımlanmıştır, ancak her zaman planladığınızdan biraz daha büyüktür.

Bu durumda, sabit faktör çarpanı ve düşük dereceli terimlerle ilgilendiğim kadar big-O ile ilgilenmiyorum. Çalışma süresi a*n^2 + b*n + colan (yani O(n^2)) bir işlev için , genellikle azaltma ave muhtemelen ortadan kaldırma ile daha çok ilgileniyorum c. Bir kurulum veya sökme maliyeti c, küçük veya küçük bir oranla orantılı olarak artabilir n.

Bununla birlikte, bu big-O'nun (veya daha özel olarak big-teta'nın ) harika bir kod kokusu göstergesi olduğu anlamına gelmez . Bir O(n^4)yerde veya daha da kötüsüO(k^n) geometrik bir zaman görün ve diğer seçenekleri düşündüğünüzden emin olmanın zamanı geldi.

Ben genellikle veri yapma araçları ile uğraşırken big-O optimallik ve daha düşük big-O ile algoritmalar bulmak için çemberler arasında atlama hakkında daha fazla endişe duyuyorum. Belirli bir düzeydeki / akış alanındaki nesnelerin sayısı genel olarak iyi tanımlanmış olsa da, tüm oyundaki toplam nesne / sanat varlığı / yapılandırma dosyası / vb. Aynı zamanda çok daha büyük bir sayı. Paralel bir veri çalıştırmak bile, bir jam data-clean && jam datadöngüden geçmek için hala bir dakika bekleriz (biliyorum, whine whine - konsollar için veri yapmak saatler sürebilir - çoğunlukla küçük avuçiçi oyunuz) .

Belirli bir örnek vermek gerekirse: Bu, 8x8 256 renkli döşemeleri akan bir arka plan döşemesi akış algoritmasıyla gerçekten elden çıktı. Akış tamponlarını arka plan "katmanları" arasında paylaşmak yararlıdır ve aynı tamponu paylaşan belirli bir seviyede bunlardan 6 tanesine sahip olabiliriz. Sorun, gereken arabellek boyutunu tahmin etmenin 6 katmanın olası konumlarına dayandırılmasıdır - ve asal sayı genişliği / yüksekliği / kaydırma oranı ise, hızlı bir şekilde kapsamlı bir aramaya başlayabilirsiniz - yaklaşmaya başlarO(6^numTiles)- çoğu durumda "evrenden daha uzun olacak" kategorisinde. Neyse ki çoğu vaka sadece 2-3 kat, ancak o zaman bile, yarım saatin üzerinde çalışıyoruz. Şu anda, bu olasılıkların çok küçük bir alt kümesini örnekleyerek, belirli bir süre geçene kadar ayrıntı düzeyini artırıyoruz (veya küçük çift katmanlı yapılandırmalarda olabilecek görevi tamamladık). Bu tahminin ne sıklıkta yanlış olduğumuzun önceki istatistiklerine dayanarak biraz arttığını ve ardından iyi bir ölçü için biraz ekstra dolgu eklediğimizi tahmin ediyoruz.

Bir başka eğlenceli örnek: bir süre önce bir PC oyununda, baş mühendis atlama listelerini bir süre denedi . Bellek yükü daha fazla önbellek etkisine neden olur, bu da tüm mesele için bir çeşit sabit olmayan çarpan ekler - bu yüzden küçükler için gerçekten iyi bir seçenek değildir n. Ancak, aramaların sık görüldüğü daha büyük sıralı listeler için bir avantaj sağlar.

(Çoğu zaman saf algoritmanın daha yüksek big-O olduğunu, daha küçük veri kümelerinde daha hızlı olduğunu ve daha kolay anlaşıldığını görüyorum; daha ilginç / karmaşık olanları (örneğin patricia trie) insanlar için anlamak ve korumak daha zordur, ancak daha büyük veri kümeleri.)

Kullanışlı olabilir, ancak alakasız da olabilir. Örneğin, bir Smash TV klonunun bir parçası olan en son oyunumu ele alalım. Yukarıdan aşağıya oyun, yanlardan canavarlar dökün, onları vurun.

Şimdi çarpışmaları belirlemenin birçok akıllı yolu var. KDtrees'i alanı ayırmak için kullanabilirsiniz, böylece mermileri vuramayacakları canavarlara karşı test etmiyorsunuz. Ve elbette zeki olabilirdim ve bunu yapabilirdim.

Ama tembel hissediyordum, bu yüzden her mermiyi her canavara karşılaştırdım. En yoğun durumlarda bile, çarpışma kodu 60 fps'de oyun CPU'sunun% 10'undan daha azını kullanıyordu. Big-O: Önemsiz.

Benzer şekilde, adalara şehirler inşa ettiğiniz 4x tarzı bir oyunum vardı ve bazen şehirler yok edildi. Akıllı olabilirdim ve yıkılan şehrin gelirini gelir değişkenlerinden çıkarmaya çalışabilirdim. Ama etmedim. Sadece geliri sildim ve her şey değiştiğinde sıfırdan yeniden hesapladım. CPU açısından tamamen alakasız.

Big-O, oyunlarda diğer her şeyde olduğu kadar önemlidir: yani, kritik olana kadar, tamamen önemsizdir.

Git biraz kod yaz. Çok yavaşsa, profil yapın.

Big-O analizi önemlidir, ancak oyun geliştirmede düşünülecek ilk şey değildir. Oyunları çok sayıda karmaşık kod içerdiğinden, her zaman bir algoritma için ilk kriter olarak Kod Basitliğini öneriyorum . Karmaşık defter tutma ile algoritmalar sadece zamanınızı boşa harcar.

Oyununuzun geliştirme sırasında her zaman 60 fps'de çalışmasının gerçekten önemli olduğunu düşünüyorum. Bunun altına daldığınızda, ilk yaptığınız şey bir profil oluşturucudur. Darboğaz bulduktan sonra saldırırsın. Çoğu zaman seviye tasarımcılarına bir alana daha az şey koymalarını söyleyin (ve onlara bunun için araçlar verin) gibi kodlamayan şeyler yapmanız gerekir.

Bazen hızlandırılması gereken bazı kodları tanımlayabilirsiniz. Bunu eğlenceli bir mühendislik olarak görüyorum! Keşke bunu yapmak için daha fazla fırsatım olsaydı. Ve elbette, her seferinde bir şeyi değiştirerek ve performansı ölçerek tekrar etmek istersiniz. Bulduğum tipik sorunlar:

1. Her kareyi yeni aramadığınızdan veya her kareyi yanlış konumlandırdığınızdan emin olun (bu her zaman 1 numaralı sorundur)
2. İşi azaltın: daha az ışın atımı, daha az adam, vb.
3. Big-O algoritma tipi problemleri
4. Önbellek tutarlılığı: Dosyaları dağınık bellek yerine dizilere koyun
5. Hata ayıklama modunda STL kullanmayın. (ve her zaman hata ayıklama modunun çalışmasını istersiniz)

Big-O notasyonu, tanım gereği asimptotik karmaşıklıktır - yani, N (veya sahip olduğunuz değişkenler) zamanın nasıl "çok" büyüdüğünü gösterir. Tetrad'ın (ki ben yükselttiğim) yorumunu tekrarlamak için “veriler kraldır”. Eğer özel durumunuzda N "çok büyük" ise, önemliyse, N "çok küçük" ise önemli değil. Deneyim ve pratik size "çok büyük" ve "çok küçük" miktarını nasıl ölçeceğiniz konusunda bir fikir verecektir.

Açıkçası, her zaman önce profil oluşturun ve sonuncuyu optimize edin (bir özellik fizibilite çalışması yapmıyorsanız).

Yazılımınızda Big-O'nun önemi O (N ² ) 'dir. N büyüdükçe doğru algoritmaya sahip olmanın önemi daha da büyüyor. :)

Big-O sadece bir kılavuzdur - size bir algoritmadan bekleyebileceğiniz kaba performansı ve veri kümesinin boyutunu artırırken performansın nasıl ölçeklenmesini beklediğinizi anlatan bir şeydir . Big-O ile ilgili iki ana şeyi hatırlamanız gerekir:

1) Çoğunlukla aynı şeyi yapan iki algoritmanız varsa, ancak daha iyi bir O'ya sahipseniz, muhtemelen bunu almalısınız (açıkçası)

2) Big O asimtotik analiz ile ilgilidir . Big-O sadece n büyük olduğunda devreye girer . Örneğin, bir O (n) algoritması performans olarak O (n ^ 2) olana çok benzer olabilir . Küçük n için . Eğer vertex n ^ 2 işlemleri gerektiren bir algoritma bahsediyoruz ama n = 2 ve n = 3 ediyorsanız, o zaman orada değil bir O (n ^ 2) algoritması arasında pek bir fark (4 ve 9 op solunu alarak) ve bir O (n) bir (2 ve 3 op. sırasıyla). Ancak, n = 9 ise, aniden O (n ^ 2) algoritması için 81 işlemden ve O (n) bir için sadece 9 işlemden bahsediyorsunuz - daha büyük bir fark - ve n = 100 ise, 100 ops vs 10000 hakkında konuşmak - çok daha büyük bir fark.

Bu yüzden Big-O'yu her zaman bu ışıkta düşünmelisiniz: n'yi büyüdükçe en kötü durum performansına dayalı olarak aynı şeyi yapan algoritmaları karşılaştırmak içindir . N çok küçük olduğunda algoritmalar arasındaki farklar göz ardı edilebilir.

Referansım yok ama Big O en azından bir problemi ve tartışmayı analiz ederken farkında olmak için kullanışlıdır. Diğer yandan, elbette, eğer O (log n) versiyonunun O (n) versiyonundan daha fazla karışan bir O değeri varsa, bu bir tartışmadır. Ve her şeyde olduğu gibi, her zaman bir değiş tokuş vardır. Uzay karmaşıklığı bir sorun olabilir, ancak bu genel olarak O ile ifade edilebilir. Normal vaka analizi ... daha az, çünkü aykırı değerlerin de artmasını istemezsiniz. Karmaşıklık üzerindeki sadelik, bence, oyun geliştirmede nispeten neredeyse işe yaramaz, çünkü hız neredeyse her zaman bir sorundur, bu nedenle basitlik hızlanmaya neden olmadıkça (ancak karmaşık durumunuzun yanlış nedenlerden dolayı yanlış olduğu anlamına gelir) basitlik gitmek zorunda kalacaktır. hız lehine pencereden dışarı. Ama Big O kesinlikle faydalıdır,

Bir oyun işlevini veya oyunun bir yönünü prototiplendirdiğinizde, onu en iyi duruma getirme konusunda endişelenmemelisiniz .

Prototip oluşturma ve bu işlevselliğin kendine özgü özelliklerini öğrenme sürecinde, gerekli optimizasyonlar açık hale gelecek ve çoğu zaman 2. doğa gibi nihai tasarıma etki edecektir.

Terleme.

Hepsi ve sonu olmamalı. Ancak performans isabetlerine neden olabilecek bariz sorunları çözmeye yardımcı olur; neden O (n ^ 2) zamanında bir şey kullanıyorsunuz, aynı şeyi O (log n) zamanında yapabiliyorsunuz?

Bence bu, diğer birçok endüstriden daha fazla oyun için geçerli, çünkü piyasa hız problemlerini en çok fark eden pazar. Bir kelime işlemci kullanan biri X eylemini yapmak için yarım saniyelik bir gecikme olup olmadığını umursamaz, ancak oyuncular muhtemelen 'omg omg oyunu Y o kadar yavaştır ki Z eylemi yapmak çok zaman alır.

Oyun geliştirmede (ve diğer birçok) geliştirmede, döngü başına yapılan yaklaşık bir ekstra işlem sızlanıyor:

for (int i = 0; i < array.length; i ++) { /* ... */ }

vs.

for (int i = 0, l = array.length; i < l; i ++) { /* ... */ }

Modern oyunların çoğunda fizik vardır ve n-beden simülasyon problemini bulacaksınız . Saf bir algoritmada, O (n ^ 2), ancak onu O (n log n) yapan bir optimizasyon var (ancak bazı doğruluklardan fedakarlık ediyor).

Yerçekimi ve parçacık etkileşimlerini programlamıyorsunuz, ama bir ordunun (zombilerin) başka yerlere bağlı olarak hareket ettikleri takım davranışına (daha spesifik bir kelime: swarming) ne dersiniz?

Geleneksel bir çarpışma tespit algoritmasında, zaman karmaşıklığı n-gövdesi gibi O (n ^ 2) 'dir. Bununla birlikte, daha iyi bir yol var: Dünyayı birçok küçük parçaya ayırın, böylece sadece aynı parça içindeki nesneler çarpışma tespit edilir. Bkz. Http://www.videotutorialsrock.com/opengl_tutorial/collision_detection/text.php .

Oyun yazılabilir ise, komut dosyasının, kullanıcının çantasını arama gibi komut dosyasında O (n ^ 2) (ve üstü) sayı kırma algoritmaları yazmasını YAPMAYIN. Bunun yerine kodda yerleşik bir işlev oluşturun.

Gerçek dünyada sadece ham performans önemlidir. Şimdi, bir algoritmanın Big-O'su ne kullanılacağına dair ilk gösterge olabilir, ancak donanıma bağlı olarak uygulama son derece verimsiz olabilir. Örneğin doğrusal bir arama yapmak, ikili bellek aramasından daha hızlı olabilir, çünkü doğrusal bellek erişimi elde edersiniz ve dallar olmaz.

Ayrıca, çok iş parçacıklı platformlarda ve mimarilerde mevcut yön nedeniyle, Big-O, algoritmanın nasıl çalıştığını hesaba katmak yerine, yalnızca işlem başına belleğin veya veri dokunuşlarının dikey ölçeklenebilirliğini dikkate aldığı için çok fazla önem kaybediyor. çok sayıda iş parçacığı ile ölçeklendirir.