Güzel bir yazılım tasarımı için% 20 performans cezası

Nesneye yönelik programlamayı en iyi şekilde kullanmayı kendime öğretmenin bir yolu olarak seyrek matris hesaplamaları için küçük bir kütüphane yazıyorum. Parçaların (seyrek matrisler ve bağlantı yapılarını tanımlayan grafikler) çok gevşek bir şekilde birleştiği güzel bir nesne modeline sahip olmak için çok çalıştım. Kendi görüşüme göre, kod bunun için çok daha genişletilebilir ve bakım yapılabilir.

Ancak, künt bir yaklaşım kullanmamdan biraz daha yavaş. Bu nesne modeline sahip olmanın geleneklerini test etmek için, bunun ne kadar hızlı çalışacağını görmek için alttaki grafiğin kapsüllenmesini bozan yeni bir seyrek matris türü yazdım.

İlk başta oldukça kasvetli görünüyordu; Bir zamanlar gurur duyduğum kod, zarif bir yazılım tasarımı olmayan bir versiyondan% 60 daha yavaş koştu. Ancak, API'yı hiç değiştirmeden birkaç alt düzey optimizasyon yapabildim - bir işlevi satır içine almak ve bir döngüyü biraz değiştirmek -. Bu değişikliklerle artık rekabetten sadece% 20 daha yavaş.

Bu da beni soruma getiriyor: Güzel bir nesne modelim olduğu anlamına gelirse ne kadar bir performans kaybını kabul etmeliyim?

Çok az bilimsel yazılım geliştiricisi iyi tasarım ilkelerini anlıyor, bu yüzden bu cevabın biraz uzun soluklu olması durumunda özür dilerim. Bir yazılım mühendisliği perspektifinden, bilimsel yazılım geliştiricisinin amacı, genellikle çelişkili bir dizi kısıtlamayı karşılayan bir çözüm tasarlamaktır .

Seyrek matris kitaplığınızın tasarımına uygulanabileceği gibi, bu kısıtlamaların bazı tipik örnekleri şunlardır:

• Bir ay içinde tamamlandı
• Dizüstü bilgisayarınızda ve çeşitli iş istasyonlarında doğru çalışır
• Verimli çalışır

Bilim adamları, yazılım mühendisliğinin diğer bazı ortak gereksinimlerine giderek daha fazla dikkat ediyorlar:

• Belgeler (Kullanıcı kılavuzu, eğitim, kod yorumlama)
• Sürdürülebilirlik (sürüm kontrolü, test, modüler tasarım)
• Yeniden kullanılabilirlik (modüler tasarım, "esneklik")

Bu gereksinimlerden bir veya daha fazlasına ihtiyacınız olabilir. Performans için bir Gordon Bell ödülü kazanmaya çalışıyorsanız, yüzde bir kısmının kesirleri bile geçerlidir ve hakimlerin birkaçı kodunuzun kalitesini değerlendirecektir (doğru olduğuna ikna edebildiğiniz sürece). Bu kodu küme veya süper bilgisayar gibi paylaşılan bir kaynakta çalıştırmayı haklı çıkarmaya çalışıyorsanız, kodunuzun performansı ile ilgili iddiaları sık sık savunmanız gerekir, ancak bunlar nadiren çok katıdır. Bir dergide, yaklaşımınızın performans kazanımlarını açıklayan bir makale yayınlamaya çalışıyorsanız, o zaman rakiplerinizden daha hızlı olmanız gerekir ve% 20 performans daha iyi bakım ve tekrar kullanılabilirlik için memnuniyetle yapacağım bir değiş tokuş.

Sorunuza geri dönersek, yeterli geliştirme süresi tanıyan "iyi tasarım" asla performanstan ödün vermemelidir. Amaç olabildiğince hızlı çalışan kod yapmaksa, kod bu kısıtlamalar etrafında tasarlanmalıdır. Kod oluşturma, satır içi montaj gibi teknikler kullanabilir veya sorununuzu çözmenize yardımcı olması için yüksek düzeyde ayarlanmış kitaplıklardan yararlanabilirsiniz.

Peki ya yeterli geliştirme zamanınız yoksa? Yeterince iyi olan ne? Bu duruma bağlıdır ve kimse bu soruya daha fazla bağlam olmadan iyi bir cevap veremeyecektir.

FWIW: Gerçekten yüksek performanslı seyrek matris çekirdekleri yazmakla ilgileniyorsanız, optimize edilmiş bir PETSc kurulumuyla karşılaştırmalı ve onları yeniyorsanız ekibiyle çalışmalısınız, ayarlanmış çekirdekleri kütüphaneye dahil etmekten mutluluk duyarlar.

Bu, zamanınızı neyle geçirdiğinize dair bir soru. Çoğumuz için zaman programlamasının 3 / 4'ünü ve zamanın 1 / 4'ünü sonuçları beklemekle geçiriyoruz. (Sayılarınız değişebilir, ancak sayının tamamen faydasız olmadığını düşünüyorum.) Dolayısıyla, iki kat daha hızlı programlamanıza izin veren bir tasarımınız varsa (1,5 zaman birimi yerine bir zaman biriminin 3/4'ü), o zaman performansta% 300'lük bir isabet alabilir (1/4 ila 1 zaman birimi) ve yine de sorunu çözmek için harcanan gerçek zaman açısından öne çıkıyorsunuz.

Öte yandan, ağır iş hesaplamaları yapıyorsanız, hesaplamalarınız farklı görünebilir ve kodunuzu optimize etmek için daha fazla zaman harcamak isteyebilirsiniz.

Bana göre,% 20 daha üretken olursanız oldukça iyi bir takas gibi görünüyor.

IMHO% 50'ye varan bir ceza (herhangi bir sebepten dolayı) o kadar da kötü değil.

Aslında sadece derleyici türüne göre performansta% 0-30 fark gördüm. Bu, PETSc'nin düşük dereceli FE takdirlerinden kaynaklanan matrisler üzerindeki seyrek MatMult rutini içindir.

Yazılım tasarımı zaman içinde otomatik olarak gelişmeyecektir. Performans olacak. Bir sonraki CPU'nuzla% 20 geri alacaksınız. Ayrıca, iyi yazılım tasarımı gelecekte kütüphaneyi genişletmeyi veya geliştirmeyi kolaylaştıracaktır.

Genel bir ilke, önce iyi bir tasarıma sahip olmak ve daha sonra yalnızca gerektiğinde performansı optimize etmektir . % 20'lik bir performans kazancının gerçekten gerekli olduğu kullanım durumları, eğer ortaya çıkarsa, oldukça nadirdir.