Czy funkcjonalne języki programowania mają więcej możliwości optymalizacji czasu kompilacji?

Czytałem książkę „Programowanie funkcjonalne w prawdziwym świecie”. Zaczęło się od porównania imperatywnych i funkcjonalnych języków programowania. I stwierdził, w jaki sposób „wartości” i „wyrażenia” w programowaniu funkcjonalnym różnią się od „zmiennych” i „funkcji” programowania imperatywnego. Na podstawie dyskusji opracowałem pomysł, który -

Funkcjonalne języki programowania mają więcej okazji do optymalizacji czasu kompilacji niż ich imperatywne odpowiedniki.

Czy to prawda?

Funkcjonalne języki programowania zapewniają znacznie większą optymalizację czasu kompilacji. Jednym z powodów jest czystość - współbieżność jest trywialna, ponieważ nie ma stanu. Dzięki temu kompilator może pobierać dwa rozgałęzienia i współbieżnie je łatwo bez zmiany zachowania programu.

Jednocześnie wszystko, co można obliczyć bez stanu (tj. Wszystko, co nie jest monadyczne w haskell), może być obliczone z wyprzedzeniem przez kompilator, ale takie obliczenia mogą być drogie i dlatego prawdopodobnie są wykonywane tylko częściowo.

Ponadto wszystko, co nie jest potrzebne obliczeniowo, można całkowicie zoptymalizować z poziomu programu.

To, że w zasadzie istnieje więcej możliwości optymalizacji czasu kompilacji dla języków funkcjonalnych niż dla ich imperatywnych odpowiedników, jest prawdopodobnie prawdą.

Bardziej interesujące jest to, że jeśli są one faktycznie zaimplementowane w bieżących kompilatorach i jak istotne są te optymalizacje w praktyce (tj. Końcowa wydajność idiomatycznego kodu „prawdziwego życia” w środowisku produkcyjnym, z przewidywalnymi ustawieniami kompilatora a priori).

np. zgłoszenia Haskella do niesławnej gry Benchmarki języka komputerowego (może to być złe - ale nie jest tak, że w tej chwili jest coś znacznie lepszego) sprawiają wrażenie, że spędzono znaczną ilość czasu na ręczne optymalizacje, które skonfrontowane z twierdzeniem o „możliwych optymalizacjach kompilatora z powodu insert some property about FP languages here” sprawiają, że optymalizacje są (przynajmniej przynajmniej) bardziej teoretyczną możliwością niż istotną rzeczywistością.

Byłbym zadowolony, gdybym udowodnił, że się mylę w tej kwestii.

W funkcjonalnym stylu przepływ wartości przez program jest bardzo, bardzo widoczny (zarówno dla kompilatora, jak i programisty). Daje to kompilatorowi dużą swobodę w decydowaniu, gdzie przechowywać wartości, jak długo je przechowywać itd.

W imperatywnym języku kompilator obiecuje programiście model, w którym większość zmiennych odpowiada faktycznym lokalizacjom w pamięci, które pozostają przez określony czas. Potencjalnie każda instrukcja może odczytać (lub zapisać do!) Dowolną z tych lokalizacji, więc kompilator może jedynie zastąpić lokalizacje pamięci alokacją rejestru, scalić dwie zmienne w jedną lokalizację pamięci lub wykonać podobne optymalizacje po przeprowadzeniu drobiazgowej analizy tego, gdzie jeszcze w programie do tej zmiennej można się odwoływać.

Teraz są dwa zastrzeżenia:

• Społeczność języka programowania poświęciła (zmarnowała?) Wiele wysiłku w ciągu ostatnich pięćdziesięciu lat na opracowanie sprytnych sposobów przeprowadzania tej analizy. Istnieją dobrze znane sztuczki, takie jak kolorowanie rejestrów itp., Które pozwalają na wykonanie niektórych łatwiejszych przypadków przez większość czasu; ale powoduje to duże, wolne kompilatory i ciągły kompromis złożoności kompilacji pod względem jakości wynikowego kodu
• Jednocześnie większość funkcjonalnych języków programowania również nie jest czysto funkcjonalna; wiele rzeczy, które programy naprawdę muszą zrobić, takie jak reagowanie na operacje wejścia / wyjścia, są z natury niefunkcjonalne, więc żaden kompilator nie może być całkowicie wolny od tych sztuczek, a żaden język całkowicie ich nie omija - nawet Haskell, co jest nieco zbyt pure jak na mój gust (Twój przebieg może się różnić) może jedynie kontrolować i eliminować niefunkcjonalne części twojego kodu, a nie całkowicie ich unikać.

Ale aby odpowiedzieć na ogólne pytanie, tak, funkcjonalny paradygmat daje kompilatorowi dużą swobodę w optymalizacji, której nie ma w bezwzględnie koniecznym otoczeniu.