Haskell (GHC) neden bu kadar hızlı?

Haskell ( GHCderleyici ile) beklediğinizden çok daha hızlı . Doğru kullanıldığında, düşük seviyeli dillere yakın olabilir. (Haskellers'ın en sevdiği şey, C'nin% 5'ine girmeyi denemek ve (veya onu yenmek), ancak GHC Haskell'i C'yi derlediğinden, verimsiz bir C programı kullandığınız anlamına gelir.) Sorum şu, neden?

Haskell açıklayıcı ve lambda analizine dayanmaktadır. Makine mimarileri kabaca turing makinelerine dayanarak açıkça zorunludur. Gerçekten de, Haskell'in belirli bir değerlendirme sırası bile yok. Ayrıca, makine veri türleriyle uğraşmak yerine, her zaman cebirsel veri türlerini yaparsınız.

En garip, daha üst düzey fonksiyonlardır. Fonksiyonları anında oluşturmanın ve onları atmanın bir programı yavaşlatacağını düşünürdünüz. Ancak daha üst düzey işlevlerin kullanılması Haskell'i daha hızlı hale getirir. Gerçekten de, Haskell kodunu optimize etmek için, daha makine benzeri değil, daha zarif ve soyut hale getirmeniz gerekiyor gibi görünüyor. Haskell'in daha gelişmiş özelliklerinin hiçbiri, geliştirmezlerse performansını bile etkilemez .

Bu kulağa sağlam geliyorsa üzgünüm, ama işte benim sorum: Haskell (GHC ile derlenmiş) neden soyut doğası ve fiziksel makinelerden farklılıkları göz önüne alındığında bu kadar hızlı?

Not: C ve diğer zorunlu dillerin Turing Makineleri'ne biraz benzemesinin sebebi (ancak Haskell'in Lambda Calculus'a benzediği ölçüde değil), zorunlu bir dilde, sınırlı sayıda duruma (akarak hattı numarası) sahip olmanızdır. , bir Bant (koç) ile birlikte, durum ve mevcut bant banda ne yapılacağını belirler. Turing Makinelerinden bilgisayarlara geçiş için Wikipedia girişine, Turing makinesi eşdeğerlerine bakın .

Dietrich Epp ile aynı fikirdeyim: GHC'yi hızlı yapan birkaç şeyin birleşimi .

Her şeyden önce Haskell çok üst düzey. Bu, derleyicinin kodunuzu bozmadan agresif optimizasyonlar yapmasını sağlar .

SQL'i düşünün. Şimdi, bir SELECTifade yazdığımda , zorunlu bir döngü gibi görünebilir , ama değil . Bu olabilir gibi bakmak belirtilen koşullara uygun olan birini bulmaya çalışırken o tablodaki tüm satırların üzerine döngüler, ancak aslında tamamen farklı performans özelliklerine sahip - "derleyici" (DB motoru) araması yerine bir dizin yapıyor olabilir. Ancak SQL çok yüksek düzeyde olduğundan, "derleyici" tamamen farklı algoritmaların yerine geçebilir, birden çok işlemci veya G / Ç kanalı veya tüm sunucuları şeffaf bir şekilde uygulayabilir .

Haskell'i aynı olarak düşünüyorum. Sen belki düşünmek sadece, ikinci listeye girdi Harita listesine üçüncü listeye ikinci listeye filtre ve sonra sonuçlandı kaç öğe saymak Haskell istedi. Ancak GHC'nin perde arkasındaki akış-füzyon yeniden yazma kurallarını uyguladığını görmediniz, her şeyi tek bir dar makine kod döngüsüne dönüştürerek tüm işi, tahsis olmaksızın verilerin üzerinden tek bir geçişte gerçekleştirecek - bu tür bir şey el ile yazmak için sıkıcı, hataya yatkın ve bakım gerektirmeyen olmak. Bu sadece koddaki düşük düzeyli ayrıntıların olmaması nedeniyle gerçekten mümkündür.

Buna bakmanın bir başka yolu da olabilir… Haskell neden hızlı olmasın ? Onu yavaşlatan ne yapar?

Perl veya JavaScript gibi yorumlanmış bir dil değil. Java veya C # gibi bir sanal makine sistemi bile değil. Tamamen yerel makine koduna kadar derler, böylece orada ek yük yoktur.

OO dillerinin aksine [Java, C #, JavaScript…], Haskell tam tip silme özelliğine sahiptir [C, C ++, Pascal…]. Tüm tür denetimi yalnızca derleme zamanında gerçekleşir. Yani sizi yavaşlatmak için çalışma zamanı türü denetimi yok. (Bu konuda boş-işaretçi kontrolü yoktur. Örneğin Java'da JVM, boş işaretçiler olup olmadığını kontrol etmeli ve birini iptal ederseniz bir istisna atmalıdır. Haskell bu denetimle uğraşmak zorunda değildir.)

"Çalışma anında anında fonksiyonlar yaratmanın" yavaş geldiğini söylüyorsunuz, ancak çok dikkatli bakarsanız, aslında bunu yapmazsınız. Göründüğün gibi görünebilir , ama yapmazsın. Eğer derseniz (+5)kaynak kodunuzda kodlanmıştır. Çalışma zamanında değişemez. Yani bu gerçekten dinamik bir işlev değil. Kavisli fonksiyonlar bile parametreleri sadece bir veri bloğuna kaydediyor. Yürütülebilir kodun tamamı derleme zamanında mevcuttur; çalışma zamanı yorumu yoktur. ("Eval işlevi" olan diğer dillerden farklı olarak.)

Pascal'ı düşün. Eski ve kimse artık bunu gerçekten kullanmıyor, ancak kimse Pascal'ın yavaş olduğundan şikayet etmiyordu . Bu konuda hoşlanmayacak çok şey var, ama yavaşlık aslında onlardan biri değil. Haskell, elle bellek yönetimi yerine çöp toplama dışında, Pascal'dan farklı bir şey yapmıyor. Ve değişmez veriler, GC motorunda [tembel değerlendirme biraz karmaşıklaşır] birkaç optimizasyona izin verir.

Sanırım Haskell gelişmiş ve sofistike ve üst düzey görünüyor ve herkes "oh vay, bu gerçekten güçlü, inanılmaz derecede yavaş olmalı! " Diye düşünüyor. Ama öyle değil. Ya da en azından beklediğiniz gibi değil. Evet, inanılmaz bir tip sistemi var. Ama biliyor musun? Bütün bunlar derleme zamanında gerçekleşir. Çalışma zamanı geldiğinde gitti. Evet, bir kod satırı ile karmaşık ADT'ler oluşturmanıza izin verir. Ama biliyor musun? Bir ADT sadece düz sıradan C unionarasında structs. Başka bir şey yok.

Gerçek katil tembel bir değerlendirmedir. Kodunuzun kesinliğini / tembelliğini doğru bulduğunuzda, hala zarif ve güzel olan aptalca hızlı kod yazabilirsiniz. Ancak bu şeyleri yanlış anlarsanız, programınız binlerce kez daha yavaş gider ve bunun neden olduğu açık değildir.

Örneğin, her baytın bir dosyada kaç kez göründüğünü saymak için önemsiz küçük bir program yazdım. 25KB giriş dosyası için, programın çalışması 20 dakika sürdü ve yutuldu 6 gigabayt RAM'i ! Bu çok saçma !! Ama sonra sorunun ne olduğunu anladım, tek bir patlama deseni ekledim ve çalışma süresi 0,02 saniyeye düştü .

İşte Haskell beklenmedik bir şekilde yavaş ilerliyor. Ve buna alışmak biraz zaman alır. Ancak zamanla, gerçekten hızlı kod yazmak daha kolay hale gelir.

Haskell'i bu kadar hızlı yapan nedir? Saflık. Statik tipler. Tembellik. Ancak her şeyden önce, derleyicinin kodunuzun beklentilerini bozmadan uygulamayı kökten değiştirebileceği kadar yüksek düzeyde olmak.

Ama sanırım bu sadece benim fikrim ...

Uzun zamandır işlevsel dillerin hızlı, özellikle de tembel fonksiyonel dillerin hızlı olamayacağı düşünülüyordu. Ancak bunun nedeni, ilk uygulamalarının özünde yorumlanmış olması ve gerçekten derlenmemiş olmasıdır.

İkinci bir tasarım dalgası, grafik azaltmaya dayalı olarak ortaya çıktı ve çok daha verimli bir derleme olasılığını açtı. Simon Peyton Jones bu araştırmayı , Fonksiyonel Programlama Dillerinin Uygulanması ve fonksiyonel dillerin uygulanması adlı iki kitabında yazdı : (Wadler ve Hancock'un bölümleri olan birincisi ve David Lester ile yazılmış). (Lennart Augustsson ayrıca eski kitap için önemli bir motivasyonun, kapsamlı bir şekilde yorumlanmayan LML derleyicisinin derlemesini nasıl gerçekleştirdiğini anlattığını da bildirdi.

Bu çalışmalarda anlatıldığı gibi grafik azaltma yaklaşımlarının ardındaki temel düşünce, bir programı bir talimatlar dizisi olarak değil, bir dizi yerel azaltma ile değerlendirilen bir bağımlılık grafiği olarak düşünmemizdir . İkinci temel görüş, böyle bir grafiğin değerlendirilmesinin yorumlanması gerekmediği, bunun yerine grafiğin kendisinin koddan oluşturulabileceğidir . Özellikle, bir grafiğin bir düğümünü "bir değer ya da" opcode "ve üzerinde çalışacak değerler" olarak değil, çağrıldığında istenen değeri döndüren bir işlev olarak gösterebiliriz. İlk çağrıldığında, alt düğümlerden değerlerini sorar ve daha sonra bunları çalıştırır ve daha sonra "sonucu döndür " yazan yeni bir talimatla kendi üzerine yazar.

Bu, GHC'nin bugün hala nasıl çalıştığına dair temelleri ortaya koyan daha sonraki bir makalede açıklanmaktadır (modulo birçok çeşitli ince ayar olsa da): "Stok Donanımına Tembel Fonksiyonel Dillerin Uygulanması: Spineless Tagless G-Machine." . GHC için mevcut yürütme modeli GHC Wiki'de daha ayrıntılı olarak belgelenmiştir .

Yani içgörü, makinelerin nasıl çalıştığının "temel" olduğunu düşündüğümüz "veri" ve "kod" un kesin ayrımının nasıl olması gerektiği değil, derleyicilerimiz tarafından dayatıldığıdır. Böylece bunu atabiliriz ve kendi kendini değiştiren kod (yürütülebilir) üreten bir kod (derleyici) alabiliriz ve hepsi oldukça iyi çalışabilir.

Böylece, makine mimarileri belirli bir anlamda zorunlu olsa da, diller geleneksel C tarzı akış kontrolü gibi görünmeyen çok şaşırtıcı şekillerde haritalanabilir ve yeterince düşük seviyeli olduğunu düşünürsek, bu da verimli.

Bunun da ötesinde, özellikle saflık ile açılan daha birçok "optimizasyon" vardır, çünkü daha geniş bir aralıkta "güvenli" dönüşümlere izin verir. Bu dönüşümleri, işleri daha iyi hale getirecek ve kötüleşmeyecek şekilde ne zaman ve nasıl uygulayacağımız elbette ampirik bir sorudur ve bu ve diğer birçok küçük seçenek üzerinde, yıllar süren çalışma hem teorik çalışmaya hem de pratik kıyaslamaya dahil edilmiştir. Bu tabii ki de bir rol oynuyor. Bu tür araştırmalara iyi bir örnek sağlayan bir makale " Hızlı Köri Yapmak: Yüksek Dereceli Diller için Bas / Gir ve Değerlendir / Uygula " dır .

Son olarak, bu modelin dolaylı indirimler nedeniyle hala ek yük getirdiğini belirtmek gerekir. İşleri katı bir şekilde yapmanın "güvenli" olduğunu bildiğimiz ve bu nedenle grafik indirimlerini elide ettiğimiz durumlarda bu önlenebilir. Sıkılığı / talebi çıkaran mekanizmalar GHC Wiki'de tekrar ayrıntılı olarak belgelenmiştir .

Burada yorum yapacak çok şey var. Elimden geldiğince cevap vermeye çalışacağım.

Doğru kullanıldığında, düşük seviyeli dillere yakın olabilir.

Deneyimlerime göre, çoğu durumda Rust'un 2 katına çıkmak genellikle mümkündür. Ancak, düşük seviyeli dillere kıyasla performansın kötü olduğu bazı (geniş) kullanım durumları da vardır.

hatta yenebilir, ancak GHC Haskell'i C'yi derlediğinden, verimsiz bir C programı kullandığınız anlamına gelir)

Bu tamamen doğru değil. Haskell, daha sonra yerel kod üreteci aracılığıyla birleştirilmek üzere derlenen C-- (bir C alt kümesi) derler. Yerel kod üreticisi genellikle C derleyicisinden daha hızlı kod üretir, çünkü sıradan bir C derleyicisinin yapamayacağı bazı optimizasyonları uygulayabilir.

Makine mimarileri kabaca turing makinelerine dayanarak açıkça zorunludur.

Bunu düşünmenin iyi bir yolu değil, özellikle modern işlemciler talimatları düzenli olarak ve muhtemelen aynı zamanda değerlendirecek.

Gerçekten de, Haskell'in belirli bir değerlendirme sırası bile yok.

Aslında Haskell , dolaylı olarak bir değerlendirme sırası tanımlar.

Ayrıca, makine veri türleriyle uğraşmak yerine, her zaman cebirsel veri türlerini yaparsınız.

Yeterince gelişmiş bir derleyiciniz varsa, birçok durumda karşılık gelirler.

Fonksiyonları anında oluşturmanın ve onları atmanın bir programı yavaşlatacağını düşünürdünüz.

Haskell derlenir ve böylece daha üst düzey işlevler aslında anında yaratılmaz.

Haskell kodunu optimize ediyor gibi görünüyor, daha fazla makine yerine daha zarif ve soyut hale getirmeniz gerekiyor.

Genel olarak, kodu daha "makine gibi" yapmak Haskell'de daha iyi performans elde etmenin verimsiz bir yoludur. Ama daha soyut yapmak da her zaman iyi bir fikir değildir. Ne olduğunu iyi bir fikir ortak veri yapıları ve (bağlı listeler gibi) ağır optimize edilmiş fonksiyonlar kullanıyor.

f x = [x]ve f = pureHaskell'de de aynı şey. İyi bir derleyici önceki durumda daha iyi performans vermez.

Haskell (GHC ile derlenmiş), soyut doğası ve fiziksel makinelerden farklılıkları göz önüne alındığında neden bu kadar hızlı?

Kısa cevap "tam olarak bunu yapmak için tasarlandığı için" dir. GHC, spineless etiketsiz g-makinesini (STG) kullanır. Bu konuda bir makale okuyabilirsiniz burada (Bu oldukça karışık). GHC, katılık analizi ve iyimser değerlendirme gibi birçok başka şey de yapar .

C ve diğer zorunlu dillerin Turing Makineleri'ne biraz benzemesinin sebebi (ancak Haskell'in Lambda Calculus'a benzediği ölçüde değil), zorunlu bir dilde, sınırlı sayıda duruma (akarak hattı numarası) sahip olmanızdır. bir Bantla (koç), böylece durum ve mevcut bant banda ne yapılacağını belirler.

O zaman bu karışıklık değişebilirliğin daha yavaş koda yol açması mıdır? Haskell'in tembellik aslında değişebilirliğin düşündüğünüz kadar önemli olmadığı anlamına gelir, ayrıca yüksek seviyedir, böylece derleyicinin uygulayabileceği birçok optimizasyon vardır. Dolayısıyla, bir kaydı yerinde değiştirmek nadiren C gibi bir dilde olduğundan daha yavaş olacaktır.

Haskell (GHC) neden bu kadar hızlı?

Haskell'in performansını en son ölçtüğümden beri bir şey önemli ölçüde değişmiş olmalı . Örneğin:

• Yazarın Haskell'in geliştirmenin Go (130s) ve OCaml (67s) 'den daha yavaş (1.020s) daha uzun sürdüğünü ve çalıştığını, yani OCaml'den 15x daha yavaş olduğunu tespit ettiği bir RRD dosya işleme karşılaştırması.
• Bir basit sözlük kriter Haskell ~ 10x daha yavaş F # daha çalışıyor gösterdi.
• Ray Tracer Dil Karşılaştırma Haskell C daha yavaş başka bir örnektir ++, OCaml ve hatta Java ve Lisp.
• Bir paralel genel quicksort Haskell% 55 daha yavaş F # fazla oldu ve önemli ölçüde daha fazla kod gerektirir.

Peki ne değişti? Ne bir soru ne de mevcut cevaplarından herhangi birinin doğrulanabilir herhangi bir kıyaslama ölçütüne ve hatta koduna atıfta bulunmadığını fark ettim.

Haskellers'ın en sevdiği şey, C'nin% 5'ine girmeyi denemek ve almaktır

Herkesin yakınlarda herhangi bir yere ulaştığı doğrulanabilir sonuçlara ilişkin referanslarınız var mı?