Optymalizacja kodu F # czy jest naprawdę tak wolno?

Question

Szukałem sposobu na prawidłowe kodowanie algorytmiczne za pomocą .NET z wszystkimi zaletami nowoczesnych języków (np. Lubię silne sprawdzanie typu, przeciążanie operatorów, lambdy, ogólne algorytmy). Zwykle piszę moje algorytmy (głównie prozessing obrazu) w C++. Ponieważ F # jako język wydaje się dość interesujący, trochę grałem, ale wydaje mi się to bardzo powolne. Jako najbardziej prostego testu Właśnie zrobiłem jakieś manipulacje Array -> Zwiększenie jasności obrazu:

let r1 = rgbPixels |> Array.map (fun x -> x + byte(10)) 

Wydaje się być czynnikiem co najmniej 8 razy wolniej niż w porównaniu C++ realizacji - co gorsza dla bardziej złożonych algorytmów na przykład Splot 2D. Czy jest jakiś szybszy sposób, czy też brakuje mi jakichkolwiek konkretnych ustawień kompilatora (tak, budowanie wersji z optymalizacją na ...)? Jestem skłonny zapłacić za ładną i wysoką abstrację, ale takie obciążenie nie jest miłe (muszę zrównoleglić na 8 rdzeniach, aby to zrekompensować :)) - przynajmniej niszczy motywację do dalszej nauki ... Moje inne opcją byłoby opuścić moje cięższe algos w C++ i interfejs ze sprzężonym C++, ale to nie jest miłe, ponieważ obsługa zarządzanego opakowania byłaby sporym obciążeniem.

Answer 1

Jeśli martwisz się wydajnością, jedną z ważnych rzeczy do zapamiętania jest to, że F # domyślnie niczego nie mutuje. Wymaga to kopiowania w wielu naiwnych implementacjach algorytmów, takich jak ten, który opisałeś.

EDYCJA: Nie mam pojęcia dlaczego, ale proste testy poniższego kodu zapewniają gorsze wyniki dla Array.map. Pamiętaj, aby profilować dowolny algorytm próbowany podczas wykonywania tego rodzaju optymalizacji. Jednak uzyskałem bardzo podobne wyniki między for i map.

Array.map tworzy nową tablicę dla wyniku operacji, zamiast tego chcesz Array.iteri.

rgbPixels |> Array.iteri (fun i x -> rgbPixels.[i] <- x + 10uy) 

Należy pamiętać, że może to być opakowane w swoim własnym modułem poniżej

module ArrayM = 
    let map f a = a |> Array.iteri (fun i x -> a.[i] <- f x) 

Niestety jest to zło konieczne, ponieważ jednym z głównych najemców programowania funkcyjnego jest, aby trzymać się niezmiennych obiektów tyle jak zezwoli na to twój algorytm, a następnie po zakończeniu przejdź do mutacji, w której wydajność jest krytyczna. Jeśli wiesz, że Twoja skuteczność jest krytyczna od początku, musisz zacząć od tego rodzaju pomocy.

Należy również pamiętać, że istnieje prawdopodobnie biblioteka, która zapewnia tę funkcję, po prostu nie wiem o tym ręcznie.

Answer 2

Myślę, że to na pewno powiedzieć, że idiomatyczne F # będą często nie pasują do wydajności optymalnej C++ do manipulacji tablicy, z kilku powodów:

1. Array dostępy są porównywane granice tablicy w .NET, aby zapewnić bezpieczeństwo pamięci. Kompilator JIT CLR jest w stanie wymusić kontrole granic pod kątem jakiegoś stereotypowego kodu, ale zazwyczaj wymaga to użycia pętli for z wyraźnymi ograniczeniami, a nie bardziej idiomatycznymi konstrukcjami F #.
2. Zwykle niewielka ilość kosztów związanych z używaniem abstrakcji, takich jak lambda (na przykład fun i -> ...). W ciasnych pętlach ten mały narzut może okazać się znaczący w porównaniu z pracą wykonywaną w ciele pętli.
3. O ile mi wiadomo, kompilator JIT języka CLR nie korzysta z instrukcji SSE w takim stopniu, w jakim kompilatory C++ są w stanie.

Z drugiej strony księgi,

1. Nigdy nie będzie mieć przepełnienie bufora w kodzie F #.
2. Twój kod będzie łatwiej uzasadnić. Jako konsekwencja, dla danego poziomu całkowitej złożoności kodu, często można zaimplementować bardziej złożony algorytm w języku F # niż w C++.
3. W razie potrzeby można napisać kod niesocjatywny, który będzie działał z szybkością zbliżoną do C++, a także istnieją możliwości współpracy z niebezpiecznym kodem C++, jeśli okaże się, że trzeba napisać C++, aby spełnić wymagania dotyczące wydajności.