İşlemsel karmaşıklık hakkında bilgisi olmayan bir programcı olmak sorun mu?

Üniversitemde bir alıştırma yapıldı. Eve götürdüm ve çözmek için bir algoritma programlamaya çalıştım, sanırım grafiklerle ilgili bir şeydi, bağlı bileşenleri buldum.

Sonra aklıma gelen en önemsiz şeyi yaptım ve sonra öğretim görevlisine gösterdim. Kısa bir gözlemden sonra, çözümümün çalışma zamanı karmaşıklığının yenilmez olduğunu ve daha verimli bir şey gösterdiğini algıladı. Hesaplama karmaşıklığının ne olduğu hakkında bir fikri olmayan bir programcı geleneği var (onlardan biriydim), bu nedenle bir programcının hesaplama karmaşıklığı nedir hakkında bir fikri yoksa, bu bir problem midir?

Evet, hesaplama karmaşıklığı hakkında bir şeyler bilmenin ciddi bir programcı için bir zorunluluk olduğunu söyleyebilirim. Büyük veri kümeleriyle uğraşmadığınız sürece, karmaşıklığı bilmemeniz yeterli olacaktır, ancak ciddi sorunları çözen bir program yazmak istiyorsanız, ihtiyacınız olacak.

Özel durumunuzda, bağlı bileşenleri bulma örneğiniz, düğüme kadar grafikler için çalışmış olabilir . Ancak, düğümden oluşan bir grafik denediyseniz , öğretim görevlisinin algoritması muhtemelen 1 saniyede, algoritmanızın (karmaşıklığın ne kadar kötü olduğuna bağlı olarak) 1 saat, 1 gün veya hatta 1 sonsuzluğa sahip olacağına karar vermiştir.$100$$100.000$

Algoritmalar kursumuzda öğrencilerin yaptıkları bir miktar yanlış, bunun gibi bir diziyi yinelemektir:

while array not empty
    examine first element of array
    remove first element from array

Bu en güzel kod olmayabilir, ancak karmaşık bir programda böyle bir şey programcının farkında olmadan ortaya çıkabilir. Şimdi, bu programın sorunu ne?

Diyelim ki elementten oluşan bir veri setinde çalıştırdık . Bir sonraki programla karşılaştırıldığında, eski program daha yavaş çalışacaktır .$100.000$$50.000$

while array not empty
    examine last element of array
    remove last element from array

Umarım, programınızın kat daha hızlı çalışmasını sağlayacak bilgiye sahip olmanız muhtemelen bir programcı için önemli bir şeydir. İki program arasındaki farkı anlamak, karmaşıklık teorisi hakkında temel bilgiler ve programladığınız dilin detayları hakkında bazı bilgiler gerektirir.$50.000$

Sözde kod dilimde, "bir öğeyi diziden çıkarmak", tüm öğeleri soldan bir konum kaldırılarak öğenin sağına kaydırır. Bu, son elemanın kaldırılmasını bir işlemi yapar, çünkü bunu yapmak için sadece 1 eleman ile etkileşime girmemiz gerekir. İlk elemanın çıkarılması çünkü ilk elemanın çıkarılması için diğer tüm elemanların da bir pozisyon sola kaydırılması gerekir .0 ( n ) n - $O(1)$$O(n)$$n-1$

Karmaşıklıktaki çok temel bir alıştırma, ilk programın işlem yapacağını ispatlamak , ikinci program ise sadece işlemlerini kullanmaktır. Eğer eklerseniz, bir programın diğerinden çok daha etkili olduğunu göreceksiniz.nn=$\frac{1}{2}n^2$$n$$n=100.000$

Bu sadece oyuncak bir örnek ama zaten iki program arasındaki farkı anlatmak için temel bir karmaşıklık anlayışı gerektiriyor ve aslında bu hataya sahip daha karmaşık bir programda hata ayıklamak / optimize etmek istiyorsanız Böceğin nerede olduğunu. Çünkü bu şekilde bir diziden bir elemanın çıkarılması gibi bir hata koddaki soyutlamalar ile çok iyi gizlenebilir.

İyi bir karmaşıklık anlayışına sahip olmak, bir sorunu çözmek için iki yaklaşımı karşılaştırırken de yardımcı olur. Bağlanan bileşenler sorununu kendi başınıza çözmek için iki farklı yaklaşım bulduğunuzu varsayalım: aralarında karar vermek için, karmaşıklıklarını hızlı bir şekilde tahmin edip daha iyisini seçebilmeniz çok yararlı olacaktır.

Bu Tom van der Zanden'in cevabının çürütüsüdür , ki bu bir zorunluluktur.

Mesele şu ki, çoğu zaman 50.000 kat daha yavaş alakalı değil (Google’da elbette çalışmadığınız sürece).

Yaptığınız işlem mikrosaniye sürerse veya N'niz hiçbir zaman belirli bir eşiğin üstüne çıkmıyorsa (bugünlerde yapılan kodlamanın büyük bir kısmı) HİÇBİR önemli olmayacaktır. Bu durumlarda hesaplama karmaşıklığını düşünmek sadece zaman kaybetmenizi sağlar (ve büyük olasılıkla para).

Hesaplamalı karmaşıklık, bir şeyin neden yavaş yavaş ya da ölçeklendirilebileceğini ve bunun nasıl iyileştirilebileceğini anlamaya yarayan bir araçtır, ancak çoğu zaman tam anlamıyla tamamlanmıştır.

Beş yıldan fazla bir süredir profesyonel bir programcı oldum ve hiçbir döngü O (M * N) içinde döngü yaparken hesaplama karmaşıklığı hakkında düşünmeye ihtiyacım olmadı, çünkü her zaman işlem gerçekten hızlı ya da M ve N çok küçük.

Programlama işi yapan herkes için anlaşılması gereken çok daha önemli, genellikle kullanılan ve daha zor şeyler var (diş çekme ve profilleme performans alanında iyi örneklerdir).

Elbette, hesaplama karmaşıklığını anlamadan asla yapamayacağınız bazı şeyler var (örneğin: bir sözlükte anagram bulmak), ancak çoğu zaman buna ihtiyacınız yoktur.

Yaklaşık otuz yıldır yazılım geliştiriyorum, hem yüklenici hem de çalışan olarak çalışıyorum ve bu konuda oldukça başarılı oldum. İlk dilim BASIC'ti, ancak hızlı bir şekilde güç kaynağımdaki kutunun hızını almak için kendime makine dilini öğrettim. Profilcilerde yıllar boyu çok zaman harcadım ve hafızayı verimli kullanan kodları hızlıca üretmeyi çok öğrendim.

Söylemeye gerek yok, ben kendi kendime öğrendim. Birkaç yıl önce görüşmeye başlayana kadar O notalarına hiç rastlamadım. Mülakatlar sırasında ÇALIŞMAK profesyonel işimde asla ortaya çıkmaz. Bu yüzden röportajlarda sadece bu soruyu ele almak için temelleri öğrenmek zorunda kaldım.

Notalar okuyamayan caz müzisyeni gibi hissediyorum. Hala iyi oynayabilirim. Hashtag'leri biliyorum (heck, zaten icat edildiklerini öğrenmeden önce hashtable'leri icat ettim) ve diğer önemli veri yapılarını ve hatta okulda öğretmedikleri bazı püf noktalarını bile biliyorum. Fakat bence gerçek şu ki, eğer bu meslekte başarılı olmak istiyorsanız, ya indie olmanız ya da görüşmeler sırasında soracağınız soruların cevaplarını öğrenmeniz gerekir.

Bu arada, en son web geliştiricisi rolü için röportaj yaptım. Bana cevabın hem hesaplama karmaşıklığı hem de logaritma bilgisi gerektirdiği bir soru sordular. Yirmi yıl önce, az çok doğru cevap verebilecek kadar matematiği hatırlamayı başardım, ama biraz sıkıcıydı. Hiçbir ön uç gelişiminde logaritma kullanmak zorunda kalmamıştım.

Sana iyi şanslar!

Soru oldukça öznel, bu yüzden cevabın buna bağlı olduğunu düşünüyorum .

Küçük miktarda verilerle çalışıyorsanız bu kadar önemli değil. Bu durumlarda, örneğin, dilinizin standart kütüphanesinin sunduğu her şeyi kullanmak genellikle iyidir.

Ancak, büyük miktarda veriyle uğraşırken veya başka bir nedenden ötürü programınızın hızlı olması konusunda ısrar ediyorsanız, o zaman hesaplama karmaşıklığını anlamanız gerekir. Yapmazsanız, bir problemin nasıl çözülmesi gerektiğini veya bunu çözmenin ne kadar çabuk mümkün olduğunu nereden biliyorsunuz? Fakat sadece teoriyi anlamak gerçekten iyi bir programcı olmak için yeterli değil. Son derece hızlı kod üretmek için, örneğin makinenizin nasıl çalıştığını (önbellek, bellek düzeni, komut seti) ve derleyicinizin ne yaptığını (derleyiciler ellerinden gelenin en iyisini yapar ama mükemmel değil) anlamanız gerektiğine inanıyorum.

Kısacası, karmaşıklığın anlaşılmasının sizi daha iyi bir programcı yaptığını düşünüyorum.

Önemli bir algoritma geliştiren birinin algoritma karmaşıklığını anlamaması kesinlikle bir problemdir. Bir algoritmanın kullanıcıları genellikle iyi performans özelliklerine sahip iyi bir uygulama kalitesine güvenirler. Karmaşıklık, bir algoritmanın performans özelliklerine tek katkıda bulunmamakla birlikte, önemli bir tanesidir. Algoritma karmaşıklığını anlamayan birinin yararlı performans özelliklerine sahip algoritmalar geliştirme olasılığı daha düşüktür.

Bir algoritma kullanıcıları için problem daha azdır, mevcut algoritmaların iyi kalitede olduğunu varsayarsak. Bu, belirgin, iyi tanımlanmış, standart bir kütüphaneye sahip dilleri kullanan geliştiriciler için geçerlidir - sadece ihtiyaçları karşılayan bir algoritmayı nasıl seçeceklerini bilmeleri gerekir. Sorun, onların bir kütüphane içerisinde mevcut olan bir tür (örneğin, sıralama) çoklu algoritmaları olduğu durumlarda ortaya çıkar, çünkü karmaşıklık genellikle seçim için kullanılan kriterlerden biridir. Karmaşıklığı anlamayan bir geliştirici daha sonra eldeki görevleri için etkili bir algoritma seçmenin temelini anlayamaz.

Daha sonra algoritmik olmayan kaygılara odaklanan geliştiriciler var (daha iyi bir açıklama için). Örneğin, sezgisel kullanıcı arayüzleri geliştirmeye odaklanabilirler. Bu tür geliştiricilerin sıklıkla algoritma karmaşıklığı konusunda endişelenmelerine gerek kalmayacak, yine de yüksek kalitede kütüphaneler veya başka bir kodun geliştirilmesine güvenebilecekler.

Bu, birlikte çalıştığınız verilere değil, yaptığınız çalışmalara ve geliştirdiğiniz programlara bağlıdır.

Kavramsal karmaşıklığı bilmeyen programcıyı adsız programcı olarak adlandıralım.

Noobish programcısı şunları yapabilir:

• büyük veri veritabanları geliştirmek - içeride nasıl çalıştığını bilmek zorunda değil, tek bilmesi gereken veritabanı geliştirmekle ilgili kurallar. Şeyleri bilir: neyin endekslenmesi gerektiği, ... verilerde artıklık sağlamanın daha iyi olduğu, nerede olmadığı ...
• Oyun yapmak - sadece oyun motorunun nasıl çalıştığını incelemek ve paradigmalarını takip etmek zorundadır, oyunlar ve bilgisayar grafikleri oldukça büyük veri problemleridir. 1920 * 1080 * 32bit = cca tek resim / çerçeve için 7.9 MB düşünün ... @ 60 FPS en az 475 MB / s. Gereksiz bir tam ekran resmin sadece bir kopyasının saniyede yaklaşık 500 MB bellek verimi boşa harcayacağını düşünün. Ancak, bununla ilgilenmesine gerek yok çünkü sadece motor kullanıyor!

Noobish programcısı yapmamalı:

• Çalıştığı veri boyutuna bakılmaksızın çok sık kullanılan karmaşık programlar geliştirmek, örneğin, küçük veriler geliştirme sırasında yanlış bir çözüm fark edilmesine neden olmaz, çünkü derleme zamanından daha yavaş olacaktır. Basit bir program için sn, noobish programcı perspektifinden pek fazla değildir, peki, bu programı saniyede yirmi kez çalıştıran sunucu sunucusunu düşünün. Bu yükü kaldırabilmek için 10 çekirdek gerekir!
• gömülü cihazlar için programlar geliştirmek. Gömülü cihazlar küçük verilerle çalışır ancak mümkün olduğu kadar verimli olmaları gerekir, çünkü gereksiz işlemler gereksiz güç tüketimi sağlar

Yani, sadece teknolojiler kullanmak istediğinizde, noobish programcı iyidir. Bu nedenle, yeni çözümler, özel teknolojiler, vb. Geliştirildiğinde, noobish programcıyı işe almamak daha iyidir.

Ancak, eğer şirket yeni teknolojiler geliştirmezse, daha önce yapılmış olanları kullanmaktadır. Yetenekli ve yetenekli bir programcı işe almak yetenek kaybı olacaktır. Aynı şey, yeni teknolojiler üzerinde çalışmak istemiyorsanız ve müşterilerin fikirlerini daha önce yapılmış çerçeveleri kullanarak tasarımlara ve programlara koyma konusunda iyiyseniz, o zaman, asla gerekmeyecek bir şey öğrenmek için zamanınızı boşa harcarsınız. senin hobinse ve mantıklı zorluklardan hoşlanıyorsan.

Buraya bir cevap yazmakta biraz tereddütlüyüm ama kendimi birkaç kişiyle nitpicking yaparken buldum '

Hesaplamada bir çok şeyin bilgisi / derecesi var (ve bu terim ile kabaca bilgisayar biliminin bilgi teknolojisi ile birleşmesini kastediyorum). Hesaplama karmaşıklığı kesinlikle geniş bir alandır (OptP'in ne olduğunu biliyor musunuz? Abiteboul-Vianu teoreminin ne dediğini biliyor musunuz?) Ve ayrıca çok fazla derinlikli olduğunu itiraf ediyor: CS derecesine sahip çoğu kişi araştırmaya katılan uzman kanıtlarını üretemiyor hesaplamalı karmaşıklıktaki yayınlar.

$n^2$

Dürüst olmak gerekirse, hesaplama karmaşıklığı kavramlarının ne zaman uygulanacağını bilmekle (ve bunları ne zaman güvenli bir şekilde göz ardı edeceğinizi bilmek), C’de performansa duyarlı bir kod ve performansa duyarsız olan bazı uygulamaları (Java dünyasının dışında) ne zaman uygulayacağımı bilmek isterim. Python vb. (Bir kenara, bir Julia konuşmasında “standart uzlaşma” olarak adlandırılmıştır .) Performansı düşünmek zorunda olmadığınızı bilmek, programlama zamanından tasarruf etmenizi sağlar, ki bu da oldukça değerli bir üründür.

Ve bir başka nokta ise, hesaplama karmaşıklığının bilinmesinin otomatik olarak programları optimize etmenize yardımcı olmayacağı; önbellek yerelliği, [bazen] boru hatları ve günümüzde paralel / çok çekirdekli programlama gibi mimariyle ilgili şeyleri anlamanız gerekir; ikincisi hem kendi karmaşıklık teorisine hem de pratik düşüncelere sahiptir; Bir 2013 SOSP kağıdındaki sonuncunun tadı "Her kilitleme planının on beş dakikalık bir şöhreti vardır. Tüm kilitleme planlarında hiçbiri, hedef mimariler veya iş yüklerinde sürekli olarak diğerlerinden daha iyi bir performans sergilememektedir . bu nedenle, kilitleme algoritması donanım platformuna ve beklenen iş yüküne göre seçilmelidir. "

Büyük O'yu tanımıyorsan öğrenmelisin. Zor değil ve gerçekten faydalı. Aramaya ve sıralamaya başlayın.

Birçok cevap ve yorumun profil oluşturmayı önerdiğini ve neredeyse her zaman bir profil oluşturma aracı kullandıkları anlamına geldiğini fark ediyorum .

Sorun şu ki, profilleme araçları harita üzerinde her yerde, hızlandırmak için neye ihtiyacınız olduğunu bulmak için ne kadar etkili oldukları açısından. Burada, profilleyicilerin uğradığı yanlış anlamaları listeledik ve açıkladım.

Sonuç olarak, eğer akademik bir egzersizden daha büyüklerse , programlar en iyi otomatik profilleyicinin bile gösteremeyeceği uyku devleri içerebiliyor . Bu gönderide performans sorunlarının profilcilerden nasıl gizlenebileceğine dair birkaç örnek gösterilmektedir.

Ancak bu teknikten saklanamazlar .