Programcılar bugün için ne mikro-optimize ediyor? [kapalı]

"İyi ol 'günleri" ne geri dönersek, shareware'i arkadaşlar için disketlere kopyalayacağımızda, aynı zamanda adil bir montaj kullandık. Ortak bir "mikro-optimizasyon" uygulaması vardı, burada daha az bir talimatla ifade etmenin bir yolunu bulana kadar montaj hatlarına bakıp bakacaksınız. Matematiksel olarak imkansız olan bir deyiş bile vardı, " Her zaman bir talimat daha kaldırabilirsiniz. " Çalışma zamanı performansını küçük sabit faktörlerle değiştirmenin, bugün (çoğu) programlama için önemli bir sorun olmadığı göz önüne alındığında, programcılar bu mikro- optimizasyon çabaları başka yerlerde?

Başka bir deyişle, en iyi uygulama artık değerli bir şey eklemediği aşırı bir duruma götürülebilir mi? Bunun yerine zaman kaybetmek mi?

Örneğin: Programcılar yalnızca bir yerden çağrılan özel yöntemleri genelleştirmek için zaman harcıyor mu? Test senaryosu verilerini azaltarak zaman kaybı mı var? Programcılar (hala) kod satırlarını azaltmak konusunda aşırı endişe duyuyorlar mı?

Aşağıda aradığımın iki harika örneği var: (1) Doğru değişken adlarını bulmak için zaman harcamak, hatta her şeyi yeniden adlandırmak; ve (2) Küçük ve sürekli kod çoğaltmasının bile kaldırılması.

Bunun " Ne için optimizasyon yapıyorsunuz? " Sorusundan farklı olduğunu unutmayın , çünkü diğer programcıların en üst düzeye çıkardığı şeyleri soruyorum, çünkü bunların damgası "mikro" optimizasyonlar ve dolayısıyla verimli bir zaman kullanımı değil.

Kod Biçimlendirme

Don't     get    me   wrong             ,
code      should be   consistent        & 
readable                                , 
but       some   take it         too far.

Eskiden bir sürü montajcı yazardım. Sadece derleyiciler daha iyi değil, çoğu donanımın artık kodun sıra dışı yürütülmesine adanmış birçok mantığı var. Gerçek mikro sorun zamanlamadır, çoğu bilgisayar talimatı bir sonuç üretmek için birkaç makine saati alır - ve önbelleği kaçıran bir bellek yükü birkaç yüz sürebilir! Bu nedenle fikir, bir sonuç beklemek yerine yararlı bir şeyler yapmak için diğer talimatları planlamaktı. Ve modern makineler saat başına birkaç talimat verebilir. Bir kez sıra dışı uygulama HW almaya başladığımızda, el kodlaması ile mükemmel performans elde etmeye çalışmanın bir kupa oyunu haline geldiğini buldum. İlk olarak sipariş dışı HW, talimatları özenle hazırlanmış siparişinizde yerine getirmez, havalı yeni HW mimarisi, yetersiz yazılım programlamasının cezasını, derleyicinin genellikle performansınızın yüzde birkaçında olacağı kadar azaltmıştır. Ayrıca derleyiciler şimdi unrolling, alt yükleme, yazılım boru hattı vb gibi iyi bilinen ama karmaşıklık üreten hileler uyguladıklarını öğrendim. Hepsini kullanın ve ihtiyacınız olan montajcı sayısını birkaç kat artırın!

Muhtemelen daha da önemlisi, çoğu performans sorunu, talimat sorun oranları ile ilgili değil, verileri CPU'ya almakla ilgilidir. Yukarıda bahsettiğim gibi, bellek gecikmesi şimdi yüzlerce döngüdür ve CPU saat başına birkaç komut yürütebilir, bu nedenle program ve özellikle veri yapıları önbellek isabet oranı son derece yüksek olacak şekilde tasarlanmadıkça, talimatta mikro seviyesinin getirisi olmayacaktır. Tıpkı askeri tiplerin amatörlerin taktikleri, profesyoneller de lojistik konuşmasını söyledikleri gibi. Performans programlama artık% 90'dan fazla lojistik (hareketli veri). Modern bellek yönetimi tipik olarak birden çok önbellek seviyesine sahip olduğundan ve sanal bellek sayfaları TLB adı verilen bir donanım birimi tarafından işlendiğinden, bu rakamı belirlemek zordur. Ayrıca, gerçek veri aktarımları bayt biriminde olmadığından, adreslerin düşük düzeyli hizalanması önemli hale gelir, hatta 64bit uzun ömürlüdür, ancak önbellek birimleri halinde gelirler. Daha sonra, modern makinelerin çoğu, yakın gelecekte hangi önbellek hattını özleyebileceğinizi tahmin etmeye çalışan ve önbelleğe almak için otomatik ön getirmeler yayınlayan donanıma sahiptir. Gerçek şu ki, modern CPU'larda performans modelleri neredeyse anlaşılamayacak kadar karmaşıktır. Ayrıntılı donanım simülatörleri bile cipslerin tam mantığıyla asla eşleşemez, bu nedenle kesin ayarlama artık imkansızdır.

Bazı el kodlamaları için hala bir yer var. Daha önemli doğrusal cebir işlemleri (matris çarpımı gibi) gibi matematik kütüphaneleri (exp fonksiyonu gibi) hala donanım satıcısı (örn. Intel veya AMD veya IBM) için çalışan uzmanlar tarafından elle kodlanmaktadır, ancak muhtemelen sadece mega-bilgisayar corp başına birkaç üst çentik montajcı programcı gerekir.

Bazen bir değişken veya yöntem için iyi bir isim seçerken zaman harcıyorum (israf?).

Tüm çalışmaları (bir programı) aynı dilsel stile sokmaya çalıştığımda biraz daha ileri gidiyor. Bazen fikrim değişir ve kitabı revize ederim. :)

Hayır, bu kadar zaman alıyor. Oldukça nadirdir. Ama programlarımda iyi gramer tutmayı seviyorum.

Zaman karmaşıklığı. Programın gerçekçi bir şekilde karşılaşacağını bildiğim her şeyden daha büyük bir büyüklükteki bir ölçekte en kötü durum performansı için işleri optimize etmek için çok fazla zaman harcıyorum.

Ben gitmesine izin sadece çok obsesif değilim 'ama olabilir diğer tasarım kararları gelen gerçekçi oluyor o engel bile, o büyük büyümek' kemik.

Ancak, savunmamda, gerçekçi olmayan gerçeklik olsaydı .. optimizasyon artık 'mikro' değil. Not, imkansız demedim ama gerçekçi değil .

Elbette gereksinimler önceliklidir.

Java istisna işleyicileriyle uğraşmak için haftalarca zaman harcadığımı düşünüyorum.

Bu, yılda iki veya üç kez başarısız olan kod için çok fazla iştir. Bu bir uyarı mı yoksa bilgi mi? Hata mı yoksa ölümcül mü? İşlem beş dakika içinde yeniden ortaya çıkacak mı ölümcül mü? Her şey hala varsayılan durumundaysa gerçekten bir uyarı mıdır?

Göbek bakan bir sürü ve bir IO hatasının doğası hakkında tartışma. Ağ üzerinden dosya okuyamıyorsanız, bu bir dosya hatası mı yoksa ağ hatası mı? Ve bunun gibi.

Bir noktada tüm concat dizelerini değiştirdim, String.formatböylece yıllık dosya hatası öbekte fazladan nesnelere neden olmaz. Bu bir israftı.

Sanırım LOC'larla çok ilgiliyim. Çok fazla LOC değil, daha çok sayıda ifade ve hatta daha fazla sayıda yinelenen ifade. Yinelenen kodlara alerjim var. Genel olarak yeniden düzenleme seviyorum, ama ne yaptığımın yaklaşık% 50 kod önemli ölçüde güzel yapmıyoruz varsayalım.

Tüm satırı bir dizeye okumak yerine bir satır satır okumak ve dizeyi tek seferde işlemek.

Elbette, yürütme hızında bir fark yaratır, ancak nadiren ekstra kod satırlarına değer. Kodu daha az bakım yapılabilir hale getirir ve kod boyutunu artırır.

Evet, dosya 3GB büyükse bu muhtemelen anlamsızdır, ancak dosyaların çoğu o kadar büyük değildir (en azından ;-) ile çalıştığım olanlar değil).

Montaj dilini yazarken baytlar ve döngüler üzerinde nitpick yapmak mantıklıydı, ama bu uzun zaman önceydi ve derleyiciler o zamandan beri çok yol kat etti. Şimdi manuel olarak optimize etmek denemek olmaz.

Benzer şekilde, C'de yazmaya geçtiğimde, C derleyicilerinden daha iyi bir iş yapmak oldukça kolaydı, ancak her yıl Borland veya Microsoft veya birileri, bir öncekini odanın etrafında tekmeleyen yeni geliştirilmiş bir tane yayınlayacaktı. Derleyicinin yaydığı gerçek montaj koduna dikkat etmeye başladım ve güzel ve sıkı bir kod yazmıyorsa, döngülerin açılması, değişkenlerin döngülerin dışına taşınması vb.

Şimdi Perl, Python ve Ruby gibi çok daha yüksek dillerde yazıyorum. Derleyici hilelerinden bazılarını kullanıyorum, eğer mantıklıysa döngü açma, döngüsel değişkenleri döngülerin dışına taşıma, vb.Ama neredeyse endişelenmiyorum çünkü CPU'lar artık daha hızlı bir weeeeee biraz daha hızlı. Bir uygulama beklenmedik bir şekilde sürükleniyor gibi görünüyorsa, bir profiler kullanacağım ve ne bulabileceğimi göreceğim ve sonra bir şey geliştirilebilirse, bir şeyi daha hızlı yapmayı düşündüğüm çeşitli yollarla karşılaştırmaya başlayacağım ve ölçeklendirir.

Genel olarak yılların tecrübesine dayanarak nasıl kod yazacağım konusunda akıllı olmaya çalışıyorum.

Mikro optimizasyon: paralelleştirilebilen veya yeni donanımla iyileştirilebilen şeylerin tek iş parçacıklı performansını iyileştirme.

Bir bilgisayarda 10 yıl önce bir şey yavaşsa, daha ucuz bir çözüm muhtemelen programcı zaman optimizasyonunu boşa harcamak yerine daha yeni ve daha hızlı bir bilgisayar satın almaktır. Bununla birlikte, dikkate alınan optimizasyonların büyük bir odağı, bugün elde edebileceğiniz 8 çekirdeği veya ekstra çöp maliyeti gibi minutia hakkında acı vermek yerine birkaç yıl içinde alabileceğiniz 64'ü kullanmanın bir yolunu bulmak olmalıdır. Toplamak.

Çalışma zamanı performansı açısından mikro optimizasyon bugün bile kapalı bir sorundur (daha az yaygın olsa da). Bazen insanlara, her bir istek için fazladan bir nesne tahsis etmenin veya fazladan bir işlev çağrısı eklemenin ek yükünün ihmal edilebilir olduğunu açıklamak zorundayım.

Bunun yanı sıra, programcıların basitlik (kendim dahil) için mikro-optimize ettiğini görüyorum. Basitlik ve basitlik arasındaki farkı açıklamak zorunda olmadığım bir yerde henüz çalışmadım.

Ben gerçekten gerekli olmadığı sürece optimizasyon yapmama prensibindeyim. Ve ben de profilin ilk prensibi içindeyim. Prensip olarak, sadece gerekli bir farkı yaratacak bir şeyi optimize edeceğim.

Prensipte bu. Ancak prensip bir yalancıdır.

İç döngülerde çok kullanılacağını düşündüğüm, sık kullanılan kütüphanelerdeki işlevlere dikkat etme alışkanlığım var. Ve sonra, başka bir işlevdeki bir şeyi tespit ettiğinizde, bu çok sık kullanılmaz ...

Oh - ve sonra "yazıyorum - elbette önemli bir kütüphane" mantığı var.

Oh - ve BTW. Bir optimizasyonu yönlendirmek için henüz bir profil oluşturucu kullanmadım. Ticari olana erişmeyin ve asla gprof'u anlamaya yönelik motivasyonu pek geliştirmediniz.

Temel olarak, ben bir ikiyüzlüyüm. Bu ilkeler diğer insanlar için de geçerlidir, ancak birisinin "neden bu kadar yavaş ve berbat bir şekilde yazdınız?" bu yüzden onları kendime asla düzgün bir şekilde uygulayamam.

Yine de burada yaptığım kadar kötü değilim. Ve ben kendini aldatmaya karşı tamamen bağışıkım, bu yüzden bu konuda haklı olduğumu biliyorsun!

DÜZENLE

Eklemeliyim - en büyük aptal asıltılarımdan biri de genel gider çağrıları. Elbette her yerde değil, ama sanırım bu döngülerin içinde çokça kullanılacağını düşünüyorum (bir sorun hakkında nesnel bir kanıtım olmadığında). Sanal yöntem çağrıları birden fazla yapmaktan kaçınmak için kötü offsetof tabanlı kod yazdım. Sonuç, daha da yavaş olabilir, çünkü muhtemelen optimizerlerin iyi başa çıkmak için tasarlandığı bir kodlama stili değildir - ama daha akıllıdır ;-)

Bilgisayarların saat sürelerinin mikrosaniye cinsinden, hafızanın kilobayt cinsinden ve ilkel derleyicilerin ölçüldüğü eski günlerde, mikro optimizasyon bir anlam ifade ediyordu.

Mevcut nesil bilgisayarların hızı ve boyutu ve mevcut nesil derleyicilerin kalitesi, mikro optimizasyonun genellikle toplam zaman kaybı olduğu anlamına gelir. İstisnalar , bazı hesaplama yoğun kodlarından kesinlikle maksimum performans elde etmeniz gerektiğinde ya da son derece sınırlı kaynaklara sahip gömülü bir sistem için yazarken ortaya çıkma eğilimindedir .

ancak programcıların çalışma zamanı performansını optimize etmek için zaman kaybetmek için ne yaptığını arıyorum.

Twitter ve Facebook akla geliyor :-)