Bu kadar çok geliştirici neden performansın, okunabilirliğin ve bakımın bir arada olamayacağına inanıyor?

Bu soruya cevap verirken neden bu kadar çok geliştiricinin iyi bir tasarımın performansı hesaba katmaması gerektiğine inandığını merak etmeye başladım, çünkü bunu yapmak okunabilirliği ve / veya sürdürülebilirliği etkiler.

İyi bir tasarımın yazıldığı sırada da performansı göz önünde bulundurduğuna ve iyi bir tasarıma sahip iyi bir geliştiricinin okunabilirliği veya bakımı yapılabilirliği olumsuz yönde etkilemeden verimli bir program yazabileceğine inanıyorum.

Aşırı durumlar olduğunu kabul etmeme rağmen, neden birçok geliştirici verimli bir programın / tasarımın zayıf okunabilirlik ve / veya düşük sürdürülebilirlik ile sonuçlanacağına ve sonuç olarak performansın bir tasarım değerlendirmesi olmamasına neden olacağını ısrar ediyor?

Bu tür görüşlerin genellikle halen yaygın olan ve genellikle iyiden çok daha fazla zarar veren erken (mikro) optimizasyon girişimlerine tepkileri olduğunu düşünüyorum . Birisi bu tür görüşlere karşı durmaya çalıştığında, diğer ucuna düşmek - ya da en azından benzemek - kolaydır.

Yine de son yıllarda donanım kaynaklarının muazzam gelişimi ile günümüzde yazılan programların çoğu için performansın sınırlayıcı bir etken olduğu durdu. Tabii ki, performansın önemli bir konu olabileceği durumları tanımlamak için tasarım aşamasında beklenen ve ulaşılabilir performans dikkate alınmalıdır . Ve sonra baştan beri performans için tasarım yapmak gerçekten önemlidir. Ancak, genel basitlik, okunabilirlik ve bakım kolaylığı hala daha önemlidir . Diğerlerinin de belirttiği gibi, performansa göre optimize edilmiş kod, en basit çalışma çözümünden daha karmaşık, okunması ve bakımı zor ve hataya daha açık. Bu nedenle, optimizasyon için harcanan her türlü çabanın kanıtlanması gerekir - sadece inanılmayacak- Programın uzun vadeli bakımını mümkün olduğu kadar az düşürürken, gerçek faydalar sağlamak. Bu nedenle, iyi bir tasarım, karmaşık, performansı yoğun parçaları mümkün olduğunca basit ve temiz tutulan kodun geri kalanından ayırır .

Sorunuza, yüksek performanslı kod üzerinde çalışan bir geliştiricinin tarafından bakıldığında, tasarımda göz önünde bulundurulması gereken birkaç şey vardır.

• Erken karamsar bırakmayın. Karmaşıklıkta eşit olan iki tasarım arasında seçim yaptığınızda, en iyi performans özelliklerine sahip olanı seçin. Ünlü C ++ örneklerinden biri, sayaçların (veya yineleyicilerin) döngülerdeki artış sonrası sıklığıdır. Bu, size hiçbir şeye mal olamayacak, ama MIGHT, bu yüzden yapmayın, tamamen gereksiz bir karamsarlıktır.
• Çoğu durumda henüz mikro-optimizasyonun yakınına gitmek için hiçbir işiniz yoktur. Algoritmik optimizasyonlar daha az asılı meyvelerdir ve neredeyse her zaman gerçekten düşük seviyeli optimizasyonlardan daha kolay anlaşılır.
• Eğer ve SADECE performans kesinlikle kritik ise, düşersiniz ve kirlenirsiniz. Aslında, kodu ilk önce elinizden geldiğince izole edin, sonra da inip kirlenin. Ve önbellekleme şemaları, tembel değerlendirme, önbellekleme için bellek düzeni optimizasyonu, satır içi içindekiler veya derleme blokları, şablon katman katmanları vb. İle gerçekten çok kirlenir. Bu kodda herhangi bir bakım yapmanız gerekiyorsa, ancak performans kesinlikle kritik olduğundan, bunu yapmak zorunda kalmaktan zarar görür. Düzenleme: Bu arada, bu kodun güzel olamayacağını söylemiyorum ve olabildiğince güzel yapılması gerekiyor, ama daha az optimize edilmiş kodla karşılaştırıldığında hala çok karmaşık ve sıkışık hale gelecek.

Doğru, güzel olsun, hızlı olsun. Bu sırayla.

Greengit'in güzel diyagramını "ödünç almayı" varsayabilir ve küçük bir ekleme yapabilirsem:

|
P
E
R
F
O  *               X <- a program as first written
R   * 
M    *
A      *
N        *
C          *  *   *  *  *
E
|
O -- R E A D A B I L I T Y --

Hepimize tradeoff eğrileri olduğu "öğretildi". Ayrıca, hepimiz böyle optimal bir programcı olduğumuzu varsaydık, yazdığımız herhangi bir programın eğri üzerinde o kadar dar olduğunu varsayalım . Bir program eğri üzerindeyse, bir boyuttaki herhangi bir iyileştirmenin mutlaka diğer boyutta bir maliyeti vardır.

Tecrübelerime göre, programlar sadece ayarlanmış, ince ayarlanmış, dövülmüş, mumlanmış ve genel olarak "kod golf" e dönüştürülerek herhangi bir eğriye yaklaşmaktadır. Çoğu program her boyutta iyileştirme için bol miktarda alana sahiptir. İşte demek istediğim.

Kesin olarak, yüksek performans gösteren yazılım bileşenleri genellikle diğer yazılım bileşenlerinden daha karmaşık büyüklükteki emirlerdir (diğer tüm şeyler eşitdir).

O zaman bile kesin olarak kesin değildir, eğer performans ölçütleri kritik öneme sahip bir gereksinimse, tasarımın bu gereklilikleri karşılamak için karmaşıklığa sahip olması zorunludur. Tehlike, bileşeninden birkaç milisaniyelik sıkmaya çalışan nispeten basit bir özellikte bir sprint harcayan bir geliştiricidir.

Ne olursa olsun, tasarımın karmaşıklığı, bir geliştiricinin böyle bir tasarımı çabucak öğrenme ve tanıma yeteneği ile doğrudan bir korelasyona sahiptir ve karmaşık bir bileşendeki işlevselliğe yönelik daha fazla değişiklik yapılması, birim testlerinde yakalanmayan hatalara neden olabilir. Karmaşık tasarımlarda,% 100 birim test kapsamı hedefini daha da fazla bir boru hayali haline getirmeyi düşünecek daha birçok yön ve olası test durumları bulunmaktadır.

Bununla birlikte, kötü performans gösteren bir yazılım bileşeninin, yalnızca asıl yazarın cehaletine dayanarak, aptalca yazılmış ve gereksiz yere karmaşık olduğu için kötü performans gösterebileceği belirtilmelidir, (sadece bir kişinin yapacağı tek bir varlık oluşturmak için 8 veritabanı çağrısı yapmak , ne olursa olsun, tek bir kod yolu ile sonuçlanan tamamen gereksiz kod ... vb.) Bu durumlar daha çok kodlama ve kodlama işleminin bir sonucu olarak ortaya çıkan performans artışlarını gerektirir ve mutlaka amaçlanan sonucu DEĞİLDİR.

Bununla birlikte, iyi tasarlanmış bir bileşen varsayalım, performans için ayarlanan benzer şekilde iyi tasarlanmış bir bileşenden her zaman daha az karmaşık olacaktır (diğer tüm şeyler eşitdir).

Bu şeylerin bir arada olamayacağı kadar değil. Sorun, herkesin kodunun ilk yinelemede yavaş, okunaksız ve anlaşılmaz olması. Zamanın geri kalanı, en önemli olanı geliştirmek için çalışmakla harcanır. Bu performans ise, o zaman gidin. Son derece korkunç bir kod yazmayın, ancak yalnızca X hızlı olması gerekiyorsa, onu X hızlı yapın. Performans ve temizliğin temelde alakasız olduğuna inanıyorum. Performans kodu çirkin kod oluşturmaz. Ancak, zamanınızı hızlı olması için her bir kod parçasını ayarlayarak geçirirseniz, zamanınızı ne harcadığınızı tahmin edin. Kodunuzu temiz ve bakımlı hale getirmek.

    |
    P
    E
    R,
    F
    O *
    R * 
    M *
    A *
    N *
    C * * * * *
    E
    |
    O - HAZIRLIK -

Gördüğün gibi...

• Okunabilirliği feda etmek performansı artırabilir - ancak bu çok fazla. Belirli bir noktadan sonra, daha iyi algoritmalar ve donanımlar gibi "gerçek" anlamına gelmelisiniz.
• Ayrıca, okunabilirlik maliyetindeki performansı kaybetmek yalnızca bir dereceye kadar olabilir. Bundan sonra, programınızı performansı etkilemeden istediğiniz kadar okunabilir hale getirebilirsiniz. Örneğin, daha yararlı yorumlar eklemek, performansınızı artırmaz.

Dolayısıyla, performans ve okunabilirlik mütevazı bir şekilde ilişkilidir - ve çoğu durumda, birincisini tercih etmekten daha büyük bir teşvik yoktur. Ve burada yüksek seviyeli dillerden bahsediyorum.

Bence performans, gerçek bir problem olduğunda (veya örneğin bir gereklilik) dikkate alınmalıdır . Bunu yapmamak mikrooptimizasyonlara yol açma eğilimindedir; bu, burada ve oradaki birkaç mikrosaniyeyi kurtarmak için daha fazla karışık kodlara neden olabilir; Bunun yerine, eğer gerekirse , sistemin gerçek darboğazlarına odaklanmalı ve orada performansa önem verilmelidir .

Nokta değil okunabilirliği zaman gereken koz verimlilik. Baştan beri algoritmanızın oldukça verimli olması gerektiğini biliyorsanız, o zaman onu geliştirmek için kullandığınız faktörlerden biri olacaktır.

Mesele şu ki, çoğu kullanım durumlarda hızlı kodları kör etmek gerekmez. Çoğu durumda, IO veya kullanıcı etkileşimi, algoritma uygulamanızın neden olacağından daha fazla gecikmeye neden olur. Mesele şu ki, şişenin boynu olduğunu bilmiyorsanız, bir şeyi daha verimli hale getirmek için kendi yolunuzdan çıkmamalısınız.

Performans için kodu optimize etmek çoğu zaman daha karmaşık hale getirir, çünkü genellikle en sezgisel değil, akıllıca bir şey yapmayı gerektirir. Daha karmaşık kodların korunması ve diğer geliştiricilerin kazanması daha zordur (her ikisi de dikkate alınması gereken maliyetlerdir). Aynı zamanda, derleyiciler ortak durumları optimize etmede çok iyidir. Yaygın bir durumu iyileştirme denemenizin, derleyicinin artık deseni tanımadığı ve kodunuzu hızlı bir şekilde yapmanıza yardımcı olamayacağı anlamına gelmesi olasıdır. Bunun, performansla ilgilenmeden istediğinizi yazmak anlamına gelmediği unutulmamalıdır. Açıkça verimsiz olan hiçbir şey yapmamalısınız.

Nokta küçük şeyleri değil endişe etmektir olabilir daha iyi şeyler yapmak. Bir profiler kullanın ve 1) şu an sahip olduğunuzun bir sorun olduğunu ve 2) neyi değiştirdiğinizin bir gelişme olduğunu görün.

Sanırım çoğu programcı, içgüdüsel olarak, çoğu zaman performans kodunun, uygulamalardaki diğer tüm kodlardan çok daha fazla bilgiye (içerik, donanım bilgisi, küresel mimari) dayanan kod olması nedeniyle hissettiğini hissediyor. Çoğu kod, sadece bazı soyutlamalarla modüler bir şekilde (fonksiyonlar gibi) kapsanan belirli sorunlara bazı çözümler ifade eder ve bu, bağlam bilgisini sadece bu kapsülleme girenlere sınırlama anlamına gelir (fonksiyon parametreleri gibi).

Yüksek performans için yazdığınızda, algoritmik optimizasyonları düzelttikten sonra, içerik hakkında daha fazla bilgi gerektiren detaylara girersiniz. Bu, doğal olarak, görev için yeterince odaklanmış hissetmeyen herhangi bir programcının baskın gelmesine neden olabilir.

Küresel ısınmanın maliyeti (yüzlerce milyon PC ve büyük veri merkezi olanakları ile ölçeklendirilen bu ekstra CPU döngülerinden) ve vasat pil ömründen (kullanıcının mobil cihazlarında), en iyi duruma getirilmiş kodlarını çalıştırmak için gerektiğinde nadiren ortaya çıkıyor programcının performansı veya akran değerlendirmeleri.

Bu, göz ardı edilmiş bir kirliliğe benzeyen ekonomik bir dışsallıktır. Dolayısıyla, performans hakkında düşünmenin maliyet / fayda oranı, zihinsel olarak gerçeklikten çarpıktır.

Donanım tasarımcıları, en yeni CPU'lara güç tasarrufu ve saat ölçeklendirme özellikleri ekleyerek çok çalışıyorlar. Kullanılabilir her CPU saat döngüsünü çiğneyerek donanımın bu özelliklerden daha sık yararlanmasına izin vermek programcılara bağlıdır.

EKLENEN: Eski zamanlarda, bir bilgisayarın maliyeti milyonlarca idi, bu nedenle CPU süresini optimize etmek çok önemliydi. Ardından, kodu geliştirme ve sürdürme maliyeti, bilgisayarların maliyetinden daha büyük hale geldi, bu nedenle optimizasyon, programcı üretkenliği ile karşılaştırıldığında lehine düştü. Ancak şimdi, bir başka maliyet bilgisayarların maliyetinden daha büyük, tüm bu veri merkezlerini güçlendirme ve soğutmanın maliyeti şimdi içindeki tüm işlemcilerin maliyetinden daha büyük hale geliyor.

Bence üçünü de elde etmek zor. İki bence uygulanabilir olabilir. Örneğin, bazı durumlarda verimlilik ve okunabilirlik elde etmenin mümkün olduğunu düşünüyorum ancak mikro ayarlı kod için de bakımın zor olabileceğini düşünüyorum. Gezegendeki en verimli kod genellikle, hem inline edilmiş bir montajla yazdığı SoA-vectorized, çok iş parçacıklı SIMD kodunu, ya da en kesicili yazmayı anlatan bir tür olmadıkça, muhtemelen çoğu kişi için açık olduğu gibi hem sürdürülebilirlik hem de okunabilirlikten yoksundur. Sadece 2 ay önce yayınlanan 40 sayfalık matematiksel makaleleri ve bir inanılmaz karmaşık veri yapısı için 12 değerinde kütüphaneyi içeren sektörde kullanılan kenar algoritmaları.

Mikro Verimlilik

Popüler fikre aykırı olabileceğini öne sürdüğüm bir şey, en akıllı algoritmik kodun, çoğu mikro ayarlı basit algoritmadan daha sürdürülmesi daha zor olduğudur. Ölçeklenebilirlik geliştirmelerinin bu mikro ayarlı kodun karşılığını daha da arttırması fikri (ör: önbellek dostu erişim kalıpları, çoklu okuma, SIMD, vb.), En azından son derece karmaşık bir sektörde çalışmış olan, zorlu bir iş. özellikle ağ işleme gibi alanlarda veri yapıları ve algoritmaları (görsel FX endüstrisi), çünkü patlama büyük olabilir, ancak marka olduklarından daha önce hiç kimsenin duymadığı yeni algoritmaları ve veri yapılarını tanıttığınızda bu fiyat oldukça pahalıdır. yeni. Dahası, ben

Bu yüzden algoritmik optimizasyonların daima hafızaya giriş kalıplarıyla ilgili optimizasyonlara her zaman attığını düşünen fikir her zaman tam olarak aynı fikirdeyim. Elbette bir kabarcık türünü kullanıyorsanız, hiçbir mikro mikro optimizasyon orada size yardımcı olamaz ... ama nedense, her zaman bu kadar net olduğunu sanmıyorum. Ve tartışmalı bir şekilde algoritmik optimizasyonların bakımı mikro optimizasyonlardan daha zordur. Klasik ve basit bir BVH algoritması alan Intel'in Embree'sini korumayı çok daha kolay bulurdum, ve algoritmik olarak hızlandırıcı akışkan simülasyonunun en ileri yollarını elde etmek için Dreamwork'ün OpenVDB kodundan çok daha fazla şey ayarlamaz. Bu yüzden, en azından benim endüstrimde, Intel'in sahneye girdiğinde olduğu gibi, bilgisayar mimarisine aşina olan daha fazla insanı daha fazla mikro optimizasyona sokmak istiyorum. Binlerce ve binlerce yeni algoritma ve veri yapısını bulmak yerine. Etkili mikro optimizasyonlarla, insanlar yeni algoritmalar oluşturmak için potansiyel olarak daha az ve daha az neden bulabilirler.

Neredeyse her kullanıcı işleminin kendine özgü bir veri yapısına ve algoritmasına sahip olduğu eski bir kod tabanında çalıştım (yüzlerce egzotik veri yapısını ekleyerek). Ve birçoğu, çok dar performans gösteren, çok eğri performans özelliklerine sahipti. Sistem birkaç düzine daha uygulanabilir veri yapısının etrafında dönebilseydi daha kolay olurdu, ve eğer daha iyi bir şekilde mikro-optimize edilmişlerse durum böyle olacağını düşünüyorum. Bu durumdan bahsediyorum çünkü mikro-optimizasyon, bu durumda, önbellek kayıplarını içeren katı salt okunur amaçlar için bile güvenle kullanılamayan yüzlerce mikro karartılmış veri yapıları arasındaki fark anlamına gelirse, bu durumda büyük olasılıkla korunabilirliği potansiyel olarak artırabilir. doğru vs.

İşlevsel diller

Bu arada, şimdiye kadar karşılaştığım en korunabilir kodlardan bazıları oldukça etkiliydi ancak fonksiyonel dillerde yazılmışlardı. Genel olarak okunabilirlik ve uber sürdürülebilirlik bence çelişkili fikirler.

Bir kerede kodu okunaklı, bakımlı ve verimli hale getirmek gerçekten zor. Tipik olarak, eğer bu üçü değil, ikisi olmasa da, bakım için okunabilirliği tehlikeye atma veya verimlilik için bakımdan taviz verme gibi bir taviz vermeniz gerekir. Diğer ikisinin çoğunu ararken sıkıntı çeken sürdürülebilirliktir.

Okunabilirlik vs. Bakım Kolaylığı

Söylediğim gibi, okunabilirlik ve sürdürülebilirliğin uyumlu kavramlar olmadığına inanıyorum . Sonuçta, çoğumuz için en okunaklı kod, insan düşünce kalıplarına çok sezgisel olarak eşleşir ve insan düşünce kalıpları içsel olarak hataya açıktır: " Eğer bu olursa, bunu yapın. Bu olursa, bunu yapın. Aksi halde bunu yapın. Oops , Bir şeyi unuttum! Bu sistemler birbirleriyle etkileşime girerse, bu sistemin bunu yapabilmesi için böyle bir şey olmalı ... oh bekleyin, bu olay tetiklendiğinde o sistem ne olacak?“Kesin teklifi unuttum, ancak bir keresinde Roma yazılım gibi inşa edildiyse, duvarları yıkmak için sadece bir duvar inişini alacağını söyledi. Çoğu yazılımda durum böyle. Sıklıkla umduğumuzdan daha kırılgan. Burada görünüşte zararsız olan birkaç kod satırı var ve onu tüm tasarımı yeniden gözden geçirmemize kadar durdurabilir ve mümkün olduğunca okunaklı olmayı hedefleyen üst düzey diller bu tür insan tasarım hatalarının istisnaları değildir .

Saf işlevsel diller, fizibil bir şekilde elde edilebileceği kadar buna dayanılmaz olanlara yakındır (yenilmez olanlara bile yakın değil, ama çoğu kişiden nispeten daha yakın). Ve bu kısmen çünkü sezgisel olarak insan düşüncesiyle eşleşmiyorlar. Okunamazlar. Mümkün olan en az miktarda bilgiyi kullanarak ve herhangi bir yan etkiye neden olmadan, mümkün olan en az özel durumla ilgili sorunları çözmemizi sağlayan düşünme kalıplarını üzerimize zorlarlar. Son derece ortogonaldirler, kodların süpriz olmadan sık sık değiştirilip değiştirilmesine izin verirler, böylece epik bir destansı olur, böylece bir çizim tahtasında bile tasarımı yeniden düşünmemiz gerekir, hatta her şeyi yeniden yazmadan genel tasarım hakkındaki düşüncelerimizi değiştirmemiz gerekir. Bundan daha kolay hale gelmiyor gibi görünüyor ... ama kodun okunması hala çok zor.

Bir problem, sonlu geliştirici zamanının, optimize etmek istediğiniz şeyin, diğer konularda zaman harcamaktan uzaklaştığı anlamına gelir.

Meyer Kod Tamamında bu başvuruda bulunmuş oldukça iyi bir deney var. Farklı geliştiriciler gruplarından hız, bellek kullanımı, okunabilirlik, sağlamlık vb. İçin optimizasyon yapmaları istendi. Projelerinin optimize edilmesinin istendiği yerde yüksek puan aldığı, ancak diğer tüm niteliklerde daha düşük olduğu tespit edildi.

Çünkü deneyimli programcılar bunun doğru olduğunu öğrendi.

Yalın ve kaba olan ve performans sorunları olmayan kodla çalıştık.

Performans sorunlarını çözmek için ÇOK karmaşık olan birçok kod üzerinde çalıştık.

Akla gelen hızlı bir örnek, son projemin 8,192 el ile keskinleştirilmiş SQL tabloları içerdiğidir. Performans sorunları nedeniyle buna ihtiyaç vardı. 1 masadan seçilecek ayar, 8,192 parça arasından seçim yapmak ve sürdürmek yapmaktan daha basittir.

Ayrıca, en iyi duruma getirilmiş kodun okunması ve anlaşılması zor olan durumu destekleyen çoğu insan beynini bükecek bazı yüksek derecede iyileştirilmiş kod parçaları da vardır.

İşte en meşhurı düşünüyorum. Quake III Arena'dan alınmış ve John Carmak'a atfedilmiş olsa da, bu işlevin birkaç yinelemesi olduğunu ve aslında onun tarafından yaratılmadığını düşünüyorum ( Wikipedia harika değil mi? ).

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the fuck?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
    //      y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;
}