C ++ şablonlarını kullanan genel ve meta programlama ne kadar hesaplama bilimlerinde yararlıdır?

C ++ dili, şablonlar aracılığıyla genel programlama ve meta programlama sağlar . Bu teknikler birçok büyük ölçekli bilimsel bilgi işlem paketine (ör. MPQC , LAMMPS , CGAL , Trilinos ) doğru yol almıştır. Ancak, genel geliştirme süresi ve eşit veya yeterli verimlilik için kullanılabilirlik açısından C veya Fortran gibi genel olmayan, meta olmayan dillerin ötesine geçen değerdeki bilimsel hesaplamaya gerçekten ne katkıda bulundular?

Bilimsel bir hesaplama görevi göz önüne alındığında, C ++ şablonları aracılığıyla genel ve meta-programlama, iyi anlaşılmış ölçütlerle (kod satırları, kişi-çaba vb.) Ölçülen verimlilik, ifade edilebilirlik veya kullanılabilirlikte bir gelişme gösterdi mi? Buna bağlı olarak, genel ve meta programlama için C ++ şablonlarının kullanımı ile ilişkili riskler nelerdir?

Genel olarak, şablon meta programlamanın uygulamada kullanılamaz olduğu bulunmuştur - çok yavaş derler ve aldığımız hata mesajlarının deşifre edilmesi imkansızdır. Meta programlamayı kullanırken yeni gelenler için giriş engeli de çok yüksektir.

Tabii ki, jenerik programlama Trilinos, deal.II (kendi kütüphanem), DUNE ve diğer birçok kütüphanenin tanık olduğu gibi tamamen farklı bir konudur - farklı veri türlerinde çalışan aynı kavramı ifade etmek bir tür beyinsizdir, ve topluluk, metaprogramlama sorunlarından kaçınan sınırlar içinde kaldığı sürece bunu büyük ölçüde kabul etti. Genel programlamanın bariz bir başarı olduğunu düşünüyorum.

Tabii ki, bu konuların hiçbiri hemen OOP ile bağlantılı değildir. OOP, yine, bilimsel bilgi işlem topluluğu tarafından evrensel olarak kabul edildiğini söyleyebilirim. Genel programlamadan daha az bile, bu bir tartışma konusu değildir: son 15 yılda yazılan her başarılı kütüphane (C ++, C veya Fortran ile yazılmış olsun) OOP tekniklerini kullanır.

Deneyime dayalı bir örnek vereyim. Günden güne kullandığım çoğu kütüphane OOP'u bir şekilde kullanıyor. OOP birçok alan için gereken karmaşıklığı gizleyebilir, performansa gerçekten yardımcı olan bir mekanizma değildir. Olabilecek olan, bir kütüphanenin nesne hiyerarşisine dayalı belirli optimizasyonları kullanabilmesidir, ancak çoğunlukla karmaşıklığı kullanıcıdan gizlemekle ilgilidir. Tasarım Desenlerine bakın, bu karmaşıklık gizlemesini gerçekleştirmek için sıklıkla kullanılan mekanizmalardır.

Örnek olarak PETSc'yi ele alalım. PETSc, algoritmalarının herhangi birinin belirli bir nesnedeki kullanılabilir rutinlere baktığı ve rutini gerçekleştirmek için yürütülecek bir seçtiği bir OOP denetçisi / yürütücü modeli kullanır. Bu, kullanıcının endişeleri ayırmasına izin verir, örneğin matris eylemi, herhangi bir tür engellenmiş veya optimize edilmiş rutin içerebilir ve çok sayıda yinelemeli çözücü tarafından etkili bir şekilde kullanılabilir. Kullanıcıya kendi veri türlerini ve değerlendirmelerini belirleme yeteneği vererek, birkaç önemli rutin hızlanır ve ayrıca tüm kütüphanenin işlevselliği hala kullanılabilir olur.

Vereceğim diğer bir örnek ise FEniCS ve deal.II. Bu kütüphanelerin her ikisi de çok sayıda Sonlu Eleman Yöntemi üzerinde genelleme yapmak için OOP kullanır. Her iki elemanda da eleman türü, eleman sırası, kareleme gösterimi vb. Birbirinin yerine kullanılabilir. Bu iki kitaplık da bazı özel amaçlı yapılandırılmış FEM kodlarından "daha yavaş" olmakla birlikte, kullanıcı tarafından bilinmeyen FEM karmaşıklığının çoğuyla çok çeşitli sorunları çözebilirler.

Son örneğim Elemental. Elemental, MPI iletişimcilerini ve veri konumunu yönetme zorluğunu çok basit bir dil yapısına kavuşturan yeni yoğun bir lineer cebir kütüphanesidir. Sonuç olarak, bir FLAME seri kodunuz varsa, veri türlerini değiştirerek Elemental aracılığıyla paralel bir kodunuz olabilir. Daha da ilginç olanı, başka birine eşit dağıtımı ayarlayarak veri dağıtımı ile oynayabilirsiniz.

OOP, elle haddelenmiş montajla rekabet etmek için bir paradigma değil, karmaşıklığı yönetmenin bir yolu olarak düşünülmelidir. Ayrıca kötü bir şekilde yapılması çok fazla ek yüke neden olacaktır, bu nedenle zamanlamayı ve kullandıkları mekanizmaları güncellemeyi sürdürmelidir.

OOPBilimsel hesaplama için ne gibi dil özellikleri yapmak, kodu daha iyi anlamaya ve kullanmaya yardımcı olan daha kompakt kod ifadeleri sağlar. Örneğin, FFTrutinlerin her bir işlev çağrısı için kodu hantal hale getiren çok sayıda argüman taşıması gerekir.

Kullanarak moduleveya classçağrı sırasında sadece gerekeni ifadeleri argümanlar geri kalanı gibi, geçirilebilir sorun kurulumu (yani dizilerinin boyutları ve katsayılar) ilgilendirmeyen.

Deneyimlerime göre, SUBROUTINE55 argümanla (içeri ve dışarı) çağrı yaptım ve kodu daha iyi hale getirmek için 5'e düşürdüm.

Bu değer.

Bilimsel bilgi işlem için genel programlama ve meta programlamanın güçlü bir savunucusuyum. Aslında sürekli olarak ivme kazanıyor Feel ++ (http://www.feelpp.org) adlı bu tekniklere dayanan Galerkin yöntemleri için ücretsiz bir yazılım C ++ kütüphanesi geliştiriyorum. Yavaş derleme süreleri gibi hala zorluklar olduğu ve kişinin sahne arkasında neler olduğunu anlamak isterse öğrenme eğrisinin dik olabileceği doğru. Ancak bu son derece ilginç ve akıl almaz. Kütüphane düzeyinde yapılırsa ve alana özgü bir dilin arkasındaki karmaşıklığı gizlerseniz, son derece güçlü bir araç elde edersiniz. Kullanabileceğimiz ve karşılaştırabileceğimiz çok geniş bir yelpazeye sahibiz. Bilimsel hesaplamayı öğretmek amacıyla bu, büyük ölçekli uygulamalar için araştırma ve yeni sayısal yöntemler için harika, iyi çalışıyoruz ama şimdiye kadar çok iyi, zaten güzel şeyler yapabiliriz. Bunu kullanan mühendisler, fizikçiler ve matematikçiler var: birçoğu dili varyasyonel formülasyon için kullanıyor ve ondan memnunlar. Fizikçi meslektaşlarımızın manipüle ettiği bazı formülasyonlara baktığımda, varyasyonel formülasyonu tanımlamak için üst düzey bir dil olmadan "elle" yapıldığını görmek istemem. Şahsen ben bu "tekniklerin" veya "paradigmaların" artık kod büyüklüğünü büyük bir faktörle çarpmak zorunda olan bilimsel bilgi işlem kodundaki karmaşıklıkla başa çıkmak için gerekli olduğunu düşünüyorum. Muhtemelen C ++ meta-programlama desteğini geliştirmek için bir ihtiyaç var, ama özellikle C ++ 11 beri zaten iyi durumda.

Sorunuzla ilgili http://arxiv.org/abs/1104.1729 makalesini bulabilirsiniz . İfade şablonlarını (bilimsel kodda kullanılan şablon meta-programlamanın özel bir uygulaması) performans açısından tartışır.

Şablonlar, çalışma zamanında tür / etki alanı denetimlerini kaldırma konusunda çok iyidir. Bunlar derleme zamanında halledilebilir. Bu teorik olarak, tip kontrolünün sadece çalışma zamanında yapılabildiği C veya Fortran'daki aynı uygulama türüne göre performansı artırabilir - kontroller kaynak kodda uygulanır. Ancak, ön derleyici seçeneklerini kullanarak C'de aynı sonuçları elde edebilirsiniz, ancak bunların şablonların aksine elle yapılması gerekir.

Ancak, şablonlar da önemli ölçüde ek yük oluşturabilir. Genellikle komut önbelleğinin kullanımını etkileyebilecek kod bloatları oluşturabilirler. Ayrıca jenerik yaklaşımlar genellikle optimizasyon sırasında derleyiciyi zincirleyebilir - jenerik yaklaşımlar kullanıldığında kod analizi için her zaman kolay değildir. Derleyici optimizasyonu da dahil olmak üzere otomasyonla ilgili her zaman bir sorundur, çoğu zaman çıkış kodu önbellek dostu değildir.

Tip / alan adı kontrolünün faydaları, kesinlikle daha güvenli olmasına rağmen, performans açısından görebildiğim tek gerçek faydadır ve bunlar genellikle algılanamaz. Ama dediğim gibi, yaptığınız işe bağlı olarak genel etki negatif olabilir. Bu nedenle, önemli darboğazlarınızın olduğu yerlerde kodunuzu elle optimize etmek genellikle daha iyidir.