Algoritma çalışma süresi hangi programlama alanlarında gerçekten önemli bir konudur?

Bazen insanların işlemcilerin hızı ve kullanılabilir bellek miktarı nedeniyle algoritma verimliliği ve çalışma süresinin pratikte önemli bir endişe olmadığını söylediğini duyuyorum.

Ancak hala bu tür düşüncelerin büyük önem taşıdığı alanlar olduğunu düşünüyorum. Akla gelen ikisi algoritmik ticarette, binlerce işlemin bir saniyenin kesirlerinde yapılması gerekiyor ve bellek ve gücün genellikle az olduğu gömülü sistem programlama. Bu örnekler konusunda haklı mıyım? ve başka hangi alanlara örnek olacak?

Hız her zaman talep görmektedir. Sanırım haklısın. Düzgün algoritmalar talep edildiğini gösteren bazı örnekler:

1. Kriptografi

2. Büyük veritabanlarında arama yapma

3. Sıralama ve birleştirme

4. Joker karakterler dahil olmak üzere metin arama (dizine eklenmemiş)

5. Yoğun hesaplamalarda matematik problemleri

6. Simülasyon

7. Veri Madenciliği Uygulamaları

8. Animasyon

9. AI

10. Bilgisayar görüşü

Algoritmanın çalışma süresinin önemli olmayabileceği bazı durumlar vardır, çünkü daha güçlü bir donanıma sahip daha uzun çalışan bir algoritmayı kolayca delebileceğinize karar verdik. Ancak kesinlikle hızlanmaların gerekli olduğu bazı yerler var.

Genel olarak, büyük veri kümeleri kullanan her şey bir sorun olacaktır. N ile zayıf ölçeklenen bir şey olduğunda ve sonra gerçekten çok büyük bir sayı yaptığınızda, bir sorununuz var demektir. Computational Science beta sitesine gidip biraz etrafta dolaştıysanız, daha iyi, daha hızlı algoritmalara ihtiyaç duyan birçok sorun bulabileceğinizden şüpheleniyorum. Karşılaştığım bazı alanlar:

• Özellikle karmaşık istatistiksel analiz. Verimsiz algoritmaların ve büyük veri kümelerinin birleşimi büyük yavaşlamalar anlamına gelebilir. Bazı çalışmalar için bu önemli olmayabilir, ancak hızlı bir şekilde geri dönecek bir şey yapmaya çalışıyorsanız? Bir kimyasal / nükleer / biyolojik tehdit gözetim sistemi çalıştırdığınızda "sunucudan bir ay içinde çıkacaktır" muhtemelen kötü bir şeydir.
• Büyük veri kümelerinde veri madenciliği.
• Birçok değişkeni içeren simülasyonlar.

Genel olarak konuşursak, bilimsel hesaplama genellikle, programlanan şeyin karmaşıklığının, algoritmanız yavaşsa (birçoğu çok büyük n'lerden muzdaripse) ciddi yavaşlama fırsatları yarattığı bir alan gibi görünmektedir. Ve belirttiğiniz gibi, finansal uygulamalar var. Milisaniye, bir ticarette para kazanıp kazanmayacağınızı veya kaybettiğinizi belirleyebildiğinde, yapılabilecek daha iyi bir şey varsa "yeterince iyi" algoritmalar onu kesmeyecektir.

Bazen insanların işlemcilerin hızı ve kullanılabilir bellek miktarı nedeniyle algoritma verimliliği ve çalışma süresinin pratikte önemli bir endişe olmadığını söylediğini duyuyorum.

Bir tuz tanesi ile alın. Daha fazla hesaplama gücü temel olarak, n'nizin önemli ölçüde yavaşlamadan çok daha büyük olabileceği anlamına gelir. Çoğu günlük problem için, bu n artık ilgilenmeniz gerekmeyecek kadar büyük. Bununla birlikte, algoritmalarınızın karmaşıklıklarını hala bilmelisiniz.

Daha fazla kaynakla, daha sonra daha fazla veriyi kırmak gerekebilir. Bugün 10.000 günlük dosyasını 100.000 satır ile analiz etmeniz gerekiyor. Bir yılda 1.000.000.000 satırlık 100GB günlük dosyasına sahip olabilirsiniz. Veri miktarı kaynak güçlerinden daha hızlı büyürse, daha sonra sorun yaşarsınız.

Daha fazla kaynakla, birbiri üzerine daha fazla katman istiflenir. İşletim sistemi, işletim sistemi çerçevesi, 3. taraf çerçevesi, dil yorumlayıcısı ve son olarak kendi aracınızın üstünde. Tüm farklı katmanlardaki gereksiz tüm verimsizlikler çoğalır. Yarın, aracınız daha fazla zil ve ıslık ile yeni bir işletim sisteminde çalışabilir;

Bu nedenle, sorunuzu cevaplamak için, daha fazla verinin nerede kırılması gerektiğine (diğer cevaplarda verilen yeterli örnekler) ve son aracı değil, diğer araçlar için başka bir soyutlama katmanına sahip olduğunuza dikkat etmeniz gerekir.

Birkaç yıl önce, nraflar üzerinde düzenlenmiş test tüplerini iki ayrı bölüme ayıran bir algoritma yazmak zorunda kaldım : yani tüplerin bir alt kümesi 'seçildi' ve geri kalanı 'seçilmedi' ve sonuçta raf olmaması üzerinde hem 'seçilmiş' hem de 'seçilmemiş' bir tüp olurdu (sıkıştırma gibi bazı ekstra gereksinimler vardı). Her rafta maksimum 100 tüp bulunur.

Algoritma, farmasötik bir laboratuvarda bir tüp ayırma robotunu çalıştırmak için kullanılacaktı.

Orijinal şartname bana verildiğinde, çok acı verici olmayan kullanılabilirlik akıllıca olduğunu düşündüğümüz için 2000 tüp civarında sıralamak için 1 dakikalık hesaplama süresi bölgesinde ayrıldım. Robotun kendisi yavaş olduğundan , tüm olası kombinasyonlar üzerinde hareket sayısının minimum olması gerekliliği vardı .

Örtülü varsayım, karmaşıklığın tüp sayısı ile üstel olacağıydı. Bununla birlikte, algoritma tasarımı üzerinde çalışırken , tüplerin en uygun şekilde bölünmesini sağlayan raf sayısının O(n)olduğu hızlı bir algoritmanın olduğunu keşfettim n. Bunun sonucu, algoritma sıralama süresinin anlık olmasıydı, böylece sıralama ekranı, kullanıcı sıralama işlemini yapılandırırken gerçek zamanlı olarak güncellenecekti.

Benim için, her değişiklikten sonra bir dakika boyunca oturan kullanıcı ile anında yanıt veren bir GUI'ye sahip olmak arasındaki fark, işlevsel olarak yeterli olan bir yazılım ile kullanmaktan zevk alan bir yazılım arasındaki farktı.

Diğer alanlar arasında gerçek zamanlı sinyal işleme, geri bildirim kontrol sistemleri, petrol arama dekonvolüsyonu, video sıkıştırma, ışın izleme ve film karesi oluşturma, sanal gerçeklik sistemleri, yüksek kare hızının önemli bir rekabet avantajı olabileceği oyunlar ve akıllı telefonlar ve diğer alanlar yer alır. çok sayıda CPU döngüsünün kullanıcıların pil ömrünü daha hızlı tüketeceği mobil cihaz uygulamaları.

Bu soruyu bile sormak beni şaşırttı, çünkü şimdiye kadar yapılmış herhangi bir Top-500 süper bilgisayar için, bunu en üst düzeye çıkarabilecek ve bazı problemleri çözmek için daha fazla hesaplama gücü veya büyüklükte daha iyi algoritmalar isteyen büyük bir araştırmacı bekleme listesi var. (kanseri çözmek için bir miktar protein katlayın vs.) emekli olmadan önce.

Bence gibi arama motorları Google ve Bing karmaşık algoritmalar kullanılır büyük alanlardan biri olan ve kullanıcılara daha yarar getiren alaka (sıralama sayfası) sonuçlarını hızlandırmak önemli bir rol oynamaktadır.

Algoritma verimliliği günümüzde büyük bir endişe kaynağı değildir çünkü verimli algoritmalar kullanıyoruz. O (n!) Algoritması kullandıysanız, her türlü donanımda yavaş olacaktır.

Çok miktarda veri arttıkça, algoritma karmaşıklığı gittikçe önem kazanmaktadır. Neyse ki, yaygın programlama problemleri (genellikle arama ve sıralama) için etkili genel çözümler hemen hemen her modern programlama dilinin standart kütüphanesine dahil edilmiştir, bu nedenle normalde bir programcı bu şeyler hakkında fazla endişelenmek zorunda değildir. Dezavantajı, birçok programcının kaputun altında neler olup bittiğini ve kullandıkları algoritmaların özelliklerinin ne olduğunu bilmemesidir.

Birçok uygulama düzgün bir şekilde test edilmediğinden bu özellikle sorunlu hale gelir: İnsanlar küçük test veri kümeleri için iyi çalışan kod yazarlar, ancak birkaç bin kat daha fazla veriyle karşılaştıklarında kod durma noktasına gelir. Veri kümesi büyüdükçe on kayıt için iyi çalışan bir şey hızla patlar. Gerçek dünya örneği: herhangi bir kategoriye bağlı olmayan öğeleri temizlemesi gereken bir kod parçası, artık O (n ^ 3) olan üç seviyeli iç içe bir döngü kullandı. Test veritabanındaki sadece 10 kayıtla, bu 1000 kontrol anlamına geliyordu - mükemmel bir şekilde yapılabilir ve gözle görülür bir gecikme yaratmaz. Bununla birlikte, üretim veritabanı hızla yaklaşık 1000 satırla doluydu ve aniden kod her seferinde bir milyar kontrol yapıyor.

Yani: Hayır, her türlü temiz algoritmanın uygulanmasının iç ve dış yönlerini bilmenize gerek yok ve kendiniz icat edebilmenize gerek yok, ancak ortak algoritmalar hakkında temel bilgilere ihtiyacınız var, güçlü ve zayıf noktalar, ne zaman ve ne zaman kullanılmayacaklarıdır ve algoritmik karmaşıklığın olası etkisinin farkında olmanız gerekir, böylece hangi karmaşıklık düzeyinin kabul edilebilir olduğuna karar verebilirsiniz.

Bu, hangi uygulama alanlarının çalışma zamanına duyarlı olduğu sorusu değildir. Herhangi bir program, herhangi bir yerde, altında etkili bir şekilde değersiz olan minimum performansa sahiptir. Algoritma karmaşıklığının noktası, artan girdi boyutuna göre nasıl değiştiği. Başka bir deyişle, hızın özellikle önemli olduğu alanlar, sadece mevcut sorun büyüklüğünüzün değil, büyüklük sırasının ötesinde ölçeklenmeyi beklediğiniz alanlardır .Mevcut sorun boyutunuz. Fransa'nın bir bölümünün vatandaşlarının vergi başvurularını işlerseniz, görev büyük olabilir, ancak nüfusun büyüklüğünün veya bir kaydı işlemenin karmaşıklığının hiç on veya yüz kat artacağı muhtemel değildir, bu yüzden ne işe yararsa şimdi siz, muhtemelen çalışmaya devam edeceksiniz. Eğer internet hacimlerinde çıkarmak olacak bir şey oluşturmaya çalışırsanız Ama, algoritma karmaşıklığı anahtarıdır: daha doğrusal veya daha log-doğrusal giriş büyüklüğüne bağlıdır şey olacak çok hızlı çok daha pahalı hale gelir ve sonuçta işlemci hızı yapamam büyümeye ayak uydurmak.

Alanımda (yol izleme, bilgisayar animasyonu, parçacık simülasyonu, akışkan dinamiği, görüntü işleme, vb. Gibi şeyleri kapsayan VFX) algoritmik karmaşıklık esastır. Lineeritmik zamandan daha kötü çalışan herhangi bir şeyin, milyonlarca köşe noktasına, çokgenlere, voksellere, parçacıklara, teknelere, özellikle de bu şeylerin çoğunun sağlamak için saniyede birçok kez tamamlanması gerektiğinde, girişlerde makul bir sürede tamamlamayı umması mümkün değildir. gerçek zamanlı, etkileşimli geri bildirim.

Bununla birlikte, tipik olarak meslektaşlar arasında tartışmadaki algoritmik karmaşıklığa vurgu yapılmasının güçlü bir yanı yoktur, çünkü belki de biraz kabul edilmiş ve daha ziyade "ilkel" için alınmıştır. Genellikle bir yol izleyici yazıyorsanız, logaritmik veya daha iyi bir zamanda çalışacağı ve sınırlayıcı hacim hiyerarşileri gibi veri yapılarının okuyucu için uygulanması tanıdık ve nispeten önemsiz olduğu varsayılır. Multithreading ve SIMD'nin algoritmalardan daha önemli olduğunu söyleyen yetenekli bir meslektaşım bile vardı ve bir kabarcık türünü paralelleştirmekten çok daha fazlasını bekleyebileceğiniz anlamına geldiğini düşünmüyorum. Sanırım bunu söyledi çünkü mantıklı algoritmalar uygulayacağımızı kabul etti,

Çoğu zaman bu günlerde odak noktası, bu tanıdık algoritmaların çoğunu alıp CPU önbelleği, SIMD kayıtları ve talimatları, GPU'lar ve çoklu çekirdekler gibi donanımın temel özelliklerinden daha iyi yararlanmalarını sağlamaktır. Örneğin Intel, tanıdık eski BVH'yi alıp "ışın paketleri" kavramını bulmanın yeni bir yolunu bulmuş, temelde birden fazla tutarlı ışınları tek seferde yinelenen bir ağaç gezintisiyle test ediyordu (ki bu kulağa hoş gelebilir) karmaşıklık ve ek yük payı ile birlikte gelirdi, ancak bu ışınların artık SIMD talimatları ve kayıtları aracılığıyla ışın / AABB ve ışın / üçgen kavşakları için aynı anda test edilebilmesinden daha fazlasıdır).

Bilgisayar grafiklerinde çok temel şeyler olan catmull-clark alt bölümü ile benzer bir şey. Ancak günümüzde rekabetçi ve sıcak ve süper verimli olan şey, Charles Loop tarafından popülerleştirilen ve daha sonra Pixar tarafından benimsenen Gregory Patches kullanarak CC alt bölümünü yaklaşık olarak gösteren GPU uygulamalarıdır. Daha basit CPU uygulaması artık oldukça eskidir, algoritmik karmaşıklık açısından yerini aldığı için değil, GPU ile iyi oynayan bir şeyin yerini aldığı için.

Ve bu, genellikle bu günlerde donanımın altta yatan özelliklerinden nispeten bağımsız bir şekilde en iyi algoritma ile karşılaşılmaması gereken bir çok zorluktur. Aslında 90'lı yıllarda karakterleri ve diğer yumuşak bedenleri canlandırmak için çarpışma tespitini önemli ölçüde hızlandıran yeni bir hızlanma yapısı bulmaya başlayarak endüstride ayağımı aldım, bu da beni çok fazla alan olan bir hiyerarşik segmentasyon yaklaşımı kullanarak ancak bu kadar etkileyici CPU önbellekleri ve birden çok çekirdeği ve programlanabilir GPU'ları olmadan önce yayınladığımdan beri çok etkileyici değil ve bugünlerde, önemli değişikliklerin bir sonucu olarak tamamen farklı bir yaklaşım kullanıyorum. temel donanım.

Bir zamanlar bir algoritmanın genellikle O (n) 'de çalıştığı bir soruna rastladım, ancak nadir ve son derece olası olmayan durumlarda O (n ^ 3) süresine ihtiyaç duyacağım - "nadir" koşullar, geçerli adlara sahip dosyalar içeren bir dizindi bir işletim sistemi, diğerinde değil.

Hiç kimse sorun yaşamadı. Daha sonra bir müşteri, sistematik olarak O (n ^ 3) durumunda çalıştırılacak dosyaları adlandırmak için bir strateji kullandı ve orada birkaç 100 dosyayla sistem sanal olarak durdu. Sonuç, algoritmanın değiştirilmesi gerektiğiydi.

Bahsedilmemiş üç tane daha:

1) Birçok gerçek zamanlı strateji oyunu. Konumu paylaşamayan birimlere sahip olanlara bakın. Büyük bir birim grubu sınırlı arazide hareket ettiğinde yol bulmaya ne olduğunu izleyin. Bu konuda önemli bir sorun olmadan bir oyunla karşılaşmadım çünkü yeterli CPU gücü yok.

2) Birçok optimizasyon problemi. (Düzenleme: Bu cevabı yazdığım için bir tane vurdum. Amacım, bağlantı yollarının minimum ağırlığıyla bağlantılı tüm düğümleri bırakmak için gereksiz yolları budamaktı. Budama daha fazla hareket edene kadar orijinal yaklaşımım oldukça iyi çalıştı Bu rutine göre, o zaman 2 ^ n olduğunu fark ettim. Bu bazen n ^ 2.

3) Gerçek zamanlı olarak büyük miktarlarda veri üzerinde çalışması gereken şeyler. Bir DVD düşünün: 4,7 gb genellikle 2 saatlik video alırsınız. Aynı çözünürlükte tipik bir video dosyası düşünün: Bu 2 saatlik video genellikle 1GB'ın altında olacaktır. Bunun nedeni, DVD spesifikasyonunun ortaya konmasıyla, daha modern formatları yeterince hızlı bir şekilde çözebilecek makul fiyatlı bir DVD oynatıcı yapamamanızdır.

Peki, genellikle bir süper bilgisayarda ( en büyük makinelerin listesi) çalışan herhangi bir uygulama hak kazanır. Bunlar çeşitlidir, ancak bunların büyük bir alt sınıfı fizik simülasyonlarıdır:

• Fizik simülasyonları:
  • Hava Durumu tahmini
  • İklim simülasyonları
  • Patlayan yıldızların simülasyonları vb.
  • Patlayan nükleer simülasyonlar
  • Otomobil / uçak / tren vs.'nin aerodinamik simülasyonları
  • ...
• Radyo teleskop verilerinden görüntü hesaplama
• Biyolojik uygulamalar:
  • DNA dizileri olan şeyler (Gerçekten bunlara dahil değilim)
  • Protein katlanması gibi biyokimyasal maddeler
  • Sinir hücrelerinin bilgiyi işlemek için nasıl birlikte çalıştıklarının simülasyonları
  • Ekosistemler gibi diğer karmaşık etkileşimlerin simülasyonları
  • ...
• ...

Bunlar sadece başlığımın en üstünde, ancak sadece farklı süper bilgisayarların listesini okuyun ve bunların her birinin böyle devasa makineler olmadan mümkün olmayacak bir tür hesaplama sağlamak için inşa edildiğini fark edin.

Ve bu makinelere gerçekten ihtiyacımız olduğunu gördüğünüzde , sadece bu uygulamayı% 10 hızlandırarak ne kadar maliyetten tasarruf edilebileceğini anlayın . Bu kodların herhangi bir optimizasyonu, bu makinelerden elde edebileceğimiz sonuçların miktarını doğrudan artırır.