Tamamen işlevsel programlamanın verimliliği

Herkes zorunluluk yerine tamamen işlevsel olarak programlama yaparken (yani yan etkilere izin verirken) olabilecek en kötü asimtotik yavaşlamanın ne olduğunu biliyor mu?

İtowlson tarafından yapılan açıklama : En iyi bilinen tahribatsız algoritmanın asimptotik olarak en iyi bilinen tahrip edici algoritmadan daha kötü olduğu herhangi bir sorun var mı?

Göre Pippenger [1996] veri mutasyona olabilir biri saf olmayan Lisp için yazılmış bir algoritmaya (yavaş olmayan ve katı bir değerlendirme semantik vardır) tamamen işlevsel olan bir Lisp sistemi karşılaştırırken, O (çalışacak şekilde n ) tercüme edilebilir saf Lisp'de O ( n log n ) zamanında çalışan bir algoritmaya ( Ben-Amram ve Galil [1992] tarafından sadece işaretçiler kullanılarak rasgele erişim belleğini simüle etme konusundaki çalışmalarına dayanarak ). Pippenger, yapabileceğiniz en iyi algoritmalar olduğunu da belirler; saf olmayan sistemde saf sistemde are ( n log n ) olan O ( n ) problemleri vardır .

Bu yazı hakkında yapılması gereken birkaç uyarı var. En önemlisi Haskell gibi tembel fonksiyonel dilleri ele almamasıdır. Bird, Jones ve De Moor [1997] , Pippenger tarafından oluşturulan sorunun O ( n ) zamanda tembel bir işlevsel dilde çözülebildiğini , ancak bunların (veya bildiğim kadarıyla hiç kimsenin olmadığını veya Tembel bir işlevsel dil, mutasyonlu bir dil ile aynı asimtotik çalışma süresindeki tüm sorunları çözemez.

Pippenger'ın gerektirdiği sorun Ω ( n log n ) bu sonucu elde etmek için özel olarak inşa edilmiştir ve pratik, gerçek dünya problemlerini temsil etmek zorunda değildir. Sorun üzerinde biraz beklenmedik, ancak ispatın çalışması için gerekli olan birkaç kısıtlama vardır; özellikle sorun, gelecekteki girdilere erişemeden sonuçların çevrimiçi olarak hesaplanmasını ve girdinin sabit bir boyut kümesi yerine sınırsız olası atom kümesinden oluşmasını gerektirir. Ve kağıt, doğrusal çalışma süresinin saf olmayan bir algoritması için sadece (alt sınır) sonuçlar oluşturur; daha uzun çalışma süresi gerektiren sorunlar için, ekstra O (log n) doğrusal problemde görülen faktör, daha uzun çalışma sürelerine sahip algoritmalar için gerekli olan ilave işlemler sürecinde "emilebilir". Bu açıklamalar ve açık sorular Ben-Amram [1996] tarafından kısaca araştırılmıştır .

Uygulamada, birçok algoritma, değişebilir veri yapılarına sahip bir dilde olduğu gibi aynı işlevsellikte saf işlevsel bir dilde uygulanabilir. Tamamen işlevsel veri yapılarını verimli bir şekilde uygulamak için kullanılacak teknikler hakkında iyi bir referans için bkz. Chris Okasaki'nin "Tamamen Fonksiyonel Veri Yapıları" [Okasaki 1998] (tezinin genişletilmiş bir versiyonudur [Okasaki 1996] ).

Tamamen işlevsel veri yapıları üzerinde algoritmalar uygulamak isteyen herkes Okasaki'yi okumalıdır. Dengeli bir ikili ağaçla değişken belleği simüle ederek işlem başına her zaman en kötü O (log n ) yavaşlamasını sağlayabilirsiniz, ancak çoğu durumda bundan daha iyi yapabilirsiniz ve Okasaki, itfa edilmiş tekniklerden gerçeğe itfa edilen işi aşamalı olarak yapan zamanlardır. Tamamen işlevsel veri yapıları ile çalışmak ve analiz etmek biraz zor olabilir, ancak derleyici optimizasyonunda, paralel ve dağıtılmış hesaplamada ve sürüm oluşturma, geri alma ve geri alma gibi özelliklerin uygulanmasında yardımcı olan referans saydamlığı gibi birçok avantaj sağlar.

Tüm bunların sadece asimptotik çalışma sürelerini tartıştığını da unutmayın. Tamamen işlevsel veri yapılarını uygulamak için birçok teknik, çalışması için gerekli ekstra defter tutma ve söz konusu dilin uygulama detayları nedeniyle size belirli miktarda sabit faktör yavaşlaması sağlar. Tamamen işlevsel veri yapılarının faydaları bu sabit faktör yavaşlamalarından daha ağır basabilir, bu nedenle genellikle söz konusu soruna dayanarak ödünleşmeler yapmanız gerekecektir.

Referanslar

• Ben-Amram, Amir ve Galil, Zvi 1992. "Adreslere Karşı Göstericiler Üzerine" ACM Dergisi, 39 (3), s. 617-648, Temmuz 1992
• Ben-Amram, Amir 1996. "Pippenger'ın Saf ve Saf Lisp Karşılaştırması Üzerine Notlar" Yayımlanmamış el yazması, DIKU, Kopenhag Üniversitesi, Danimarka
• Bird, Richard, Jones, Geraint ve De Moor, Oege 1997. "Daha fazla acele, daha az hız: tembel ve istekli değerlendirme" Fonksiyonel Programlama Dergisi 7, 5 s. 541-547, Eylül 1997
• Okasaki, Chris 1996. "Tamamen Fonksiyonel Veri Yapıları" Doktora Tezi, Carnegie Mellon Üniversitesi
• Okasaki, Chris 1998. "Tamamen Fonksiyonel Veri Yapıları" Cambridge Üniversitesi Yayınları, Cambridge, İngiltere
• Pippenger, Nicholas 1996. "Saf Karşı Safsız Lisp" ACM Programlama Dilleri Prensipleri Sempozyumu, sayfa 104-109, Ocak 1996

Aslında, tembellikle bile, asimptotik olarak etkili, tamamen işlevsel bir çözümün (saf lambda hesabında uygulanabilir bir çözüm) bilinmediği birkaç algoritma ve veri yapısı vardır.

• Sözü edilen sendika bul
• Karma tablolar
• Diziler
• Bazı grafik algoritmaları
• ...

Bununla birlikte, "zorunlu" dillerde belleğe erişim O (1) iken teoride asimptotik olarak (yani sınırsız problem boyutları için) ve büyük bir veri kümesi içinde belleğe erişim her zaman O (log n) olarak kabul edilir. işlevsel bir dilde taklit edilebilir.

Ayrıca, aslında tüm modern fonksiyonel dillerin değiştirilebilir veriler sunduğunu ve Haskell'in bile saflıktan (ST monad) ödün vermeden sağladığını unutmamalıyız.

Bu makale , birleşme-bulma algoritmasının bilinen tamamen işlevsel uygulamalarının, tamamen işlevsel bir arayüze sahip olan ancak dahili olarak değiştirilebilir verileri kullanan yayınladıklarından daha kötü asimptotik karmaşıklığa sahip olduğunu iddia etmektedir.

Diğer cevapların hiçbir zaman bir fark olmayabileceğini iddia etmesi ve örneğin, tamamen işlevsel kodun tek "dezavantajı", bunun paralelleştirilebilmesidir, size bu konularda fonksiyonel programlama topluluğunun bilinçliliği / tarafsızlığı hakkında bir fikir verir. .

DÜZENLE:

Aşağıdaki yorumlar, saf işlevsel programlamanın artıları ve eksileri hakkındaki önyargılı bir tartışmanın “işlevsel programlama topluluğundan” gelemeyebileceğine işaret etmektedir. İyi bir nokta. Belki de gördüğüm savunucular sadece bir yorum yapmak için “okuma yazma bilmiyor”.

Örneğin, bu blog gönderisinin fonksiyonel programlama topluluğunu temsil ettiği söylenebilecek biri tarafından yazıldığını düşünüyorum ve “tembel değerlendirme noktaları” nın bir listesi olduğundan, herhangi bir dezavantajdan bahsetmek için iyi bir yer olurdu. tembel ve tamamen işlevsel programlama olabilir. Aşağıdakilerin yerine iyi bir yer olurdu (teknik olarak doğru, ama komik olmama noktasına eğilimli):

Katı bir fonksiyonun katı bir dilde O (f (n)) karmaşıklığı varsa, tembel bir dilde de O (f (n)) karmaşıklığına sahiptir. Neden endişe? :)

Bellek kullanımında sabit bir üst sınır ile fark olmamalıdır.

İspat taslağı: Bellek kullanımında sabit bir üst sınır verildiğinde, o makinede gerçekte yürüttüğünüz gibi aynı asimptotik karmaşıklığa sahip bir zorunlu talimat kümesi yürüten bir sanal makine yazılabilmelidir. Bunun nedeni, değiştirilebilir belleği kalıcı bir veri yapısı olarak yönetebileceğiniz ve O (log (n)) okuma ve yazma olanağı sunabilmenizdir, ancak bellek kullanımında sabit bir üst sınır ile sabit bir belleğe sahip olabilirsiniz. O (1) 'e bozunur. Bu nedenle, fonksiyonel uygulama, VM'nin fonksiyonel uygulamasında çalışan zorunlu sürüm olabilir ve bu nedenle her ikisinin de aynı asimtotik karmaşıklığa sahip olması gerekir.

Haskell'in performansıyla ilgili okumaları ve daha sonra, prosedürel / OO'lara karşı fonksiyonel diller için karşılaştırmalı oyun performanslarına göz atmanızı öneririm .