Występ Fortrana

Question

Występy Fortran na Computer Language Benchmark Game są zaskakująco złe. Dzisiejszy wynik stawia Fortrana na 14. i 11. miejscu na dwóch testach czterordzeniowych, 7 i 10 na pojedynczych rdzeniach.

Wiem, że benchmarki nigdy nie są idealne, ale mimo to Fortran był (jest?) Często uważany za język wysokowydajnych komputerów i wydaje się, że typ problemów zastosowanych w tym benchmarku powinien być korzystny dla Fortran. W ostatnim artykule w fizyce obliczeniowej Landau (2008) wrote:

Jednakże [Java] nie jest tak skuteczne lub jak również obsługiwany przez HPC i równolegle przetwarzania, które są Fortran i C, dwa ostatnie o wysoko rozwinięte kompilatorów i wiele innych dostępnych podprogramów naukowych. FORTRAN z kolei jest nadal dominującym językiem dla HPC z , z FORTRAN 90/95 jest zaskakująco przyjemnym, nowoczesnym i skutecznym językiem; ale, niestety, prawie nie jest nauczany przez żadne działy CS , a kompilatory mogą być kosztowne w stosunku do .

Czy to tylko z powodu kompilatora używanego przez strzelankę językową (darmowy kompilator Intela dla systemu Linux)?

Answer 1

Nie, to nie tylko z powodu kompilatora.

Testy takie jak to, w których program różni się od benchmarku do benchmarku, to w dużej mierze ilość wysiłku (i jakości wysiłku), którą programista włożył w napisanie dowolnego programu.Podejrzewam, że Fortran znajduje się w niekorzystnej sytuacji w tej konkretnej metodzie - w przeciwieństwie do C i C++, grupa programistów, którzy chcieliby spróbować swoich sił w ulepszaniu programu testów porównawczych, jest dość mała i, w przeciwieństwie do większości innych rzeczy, prawdopodobnie nie mają poczucia, że ​​mają coś do udowodnienia. Tak więc nie ma motywacji, aby ktoś spędził kilka dni na przeglądaniu generowanego kodu zespołu i profilowaniu programu, aby działał szybciej.

Jest to dość jasne z wyników, które uzyskano. Ogólnie, przy wystarczającym wysiłku programistycznym i przyzwoitym kompilatorze, ani C, C++, ani Fortran nie będą znacznie wolniejsze niż kod zespołu - z pewnością nie więcej niż 5-10%, w najgorszym wypadku, z wyjątkiem przypadków patologicznych. Fakt, że rzeczywiste wyniki uzyskane tutaj są bardziej odmienne niż wskazuje mi, że "wystarczający wysiłek programistyczny" nie został wydatkowany.

Istnieją wyjątki, gdy zezwalamy zespołowi na używanie instrukcji wektorowych, ale nie zezwalamy C/C++/Fortranowi na stosowanie odpowiednich właściwości kompilatora - wektoryzacja automatyczna nie jest nawet bliskiej aproksymacji idealnej i prawdopodobnie nigdy nie będzie . Nie wiem, ile prawdopodobnie będą tu stosować.

Podobnie wyjątek dotyczy operacji na łańcuchach, polegających głównie na bibliotece środowiska wykonawczego (która może mieć różną jakość, a Fortran rzadko jest przypadkiem, w którym szybka biblioteka ciągów zarabia na dostawcy kompilatora!) , oraz na podstawowej definicji "ciągu" i tego, jak jest to reprezentowane w pamięci.

Answer 2

Biorąc pod uwagę, że nie opublikowali dokładnych opcji kompilatora użytych w kompilatorze Intel Fortran, nie wierzę w ich benchmark.

Chciałbym również zauważyć, że zarówno biblioteka matematyczna Intela, MKL, jak i biblioteka matematyczna AMD, ACML, używają kompilatora Intel Fortran.

Edit:

znalazłem opcje kompilacji po kliknięciu na nazwę benchmarku za. Wynik jest zaskakujący, ponieważ poziom optymalizacji wydaje się rozsądny. Może to sprowadzać się do wydajności algorytmu.

Answer 3

Niektóre losowe myśli:

Fortran czynili dobrze, bo łatwiej było zidentyfikować niezmiennik pętli, która poczyniła pewne optymalizacje łatwiejsze dla kompilatora. Od tego czasu

1. Kompilatory zyskały dużo bardziej wyrafinowane niż. Ogromny wysiłek został włożony w szczególności w kompilatory c i C++. Czy kompilatory fortranów utrzymały się? Przypuszczam, że gfortran używa tego samego końca gcc i g ++, ale co z kompilatorem intel? Kiedyś było dobrze, ale czy nadal jest?
2. Niektóre języki mają wiele wyspecjalizowanych słów kluczowych i składni, które pomagają kompilatorowi (restricted i const int const *p w c, i inline w C++). Nie wiedząc, fortran 90 lub 95 nie mogę powiedzieć, czy te dotrzymują kroku.

Answer 4

Sprawdziłem te testy. To nie jest tak, że kompilator jest zły, czy coś. W większości testów Fortran jest porównywalny z C++, z wyjątkiem niektórych, gdzie jest on bity 10 razy. Testy te odzwierciedlają tylko to, co należy wiedzieć od samego początku - że Fortran po prostu NIE jest wszechstronnym, interoperacyjnym językiem programowania - jest odpowiedni dla wydajnego obliczenia, ma dobrą listę operacji & rzeczy, ale na przykład IO jest do bani chyba że robisz to z konkretnymi metodami podobnymi do Fortranu - jak np. "niesformatowane" IO.

Pozwól mi podać przykład - program "reverse-complement", który ma odczytać duży (rzędu 10^8 B) plik z linii stdin-line, robi coś z nim & drukuje wynikowy duży plik na stdout. Niezły program Fortran jest około 10 razy wolniejszy na pojedynczym rdzeniu (~ 10s) niż HEAVILY zoptymalizowany C++ (~ 1s). Gdy spróbujesz grać z programem, zobaczysz, że tylko proste sformatowane odczytanie & zapisu zajmuje więcej niż 8 sekund. W Fortran sposób, jeśli zależy Ci na wydajności, wystarczy napisać niesformatowaną strukturę do pliku & odczytać go w mgnieniu oka (co jest całkowicie nieprzenośne), ale kogo to obchodzi - wydajny kod ma być szybki & zoptymalizowany dla konkretnej maszyny, nie jest w stanie działać wszędzie).

Krótka odpowiedź brzmi - nie przejmuj się, po prostu wykonuj swoją pracę - a jeśli chcesz napisać super wydajny system operacyjny, przepraszam - Fortran nie jest po prostu sposobem na takie wykonanie.

Answer 5

Ten benchmark jest w ogóle głupi.

Na przykład mierzą czas procesora dla the whole program to run. Jako mcmint stated (i może to być rzeczywiście prawda) Fortran I/O zasysa *. Ale kogo to obchodzi? W rzeczywistych zadaniach jeden odczytuje dane wejściowe przez kilka sekund, zamiast wykonywać obliczenia dla godzin/dni/miesięcy, a na koniec zapisuje dane wyjściowe dla sekund. To dlatego w większości benchmarków operacje we/wy są wykluczone z pomiarów czasu (jeśli oczywiście nie testujesz we/wy samodzielnie).

Norber Wiener w swojej książce God & Golem, Inc.napisał:

Oddajcie człowiekowi to, co ludzkie, a co komputerowe, to, co jest komputerem.

Moim zdaniem wykorzystanie tej zasady podczas realizacji algorytmu w dowolnym języku programowania oznacza:

Zapis jako czytelny i prosty kod, jak można pozwolić kompilator zrobić optymalizacje.

Jest to szczególnie ważne w rzeczywistych (ogromnych) zastosowaniach. Brudne sztuczki (tak mocno wykorzystywane w wielu testach porównawczych), nawet jeśli mogą w pewnym stopniu poprawić wydajność (5%, może 10%) nie są przeznaczone na projekty w świecie rzeczywistym.

/* C/C++ używa strumienia I/O, ale Fortran tradycyjnie używa rekordowych operacji we/wy. Further reading. Tak czy inaczej, I/O w tych benchmarkach jest tak zaskakujące. Używanie przekierowania stdin/stdout może być również źródłem problemu. Dlaczego po prostu nie skorzystać z możliwości odczytu/zapisu plików dostarczonych przez język lub standardową bibliotekę? Po raz kolejny ta sytuacja będzie bardziej realna.

Answer 6

Chciałbym powiedzieć, że nawet jeśli benchmark nie przyniesie najlepszych rezultatów dla FORTRAN, ten język będzie nadal używany przez długi czas. Powody używania to nie tylko wydajność, ale także coś, co nazywa się łatwą programowalnością. Mnóstwo ludzi, którzy nauczyli się go używać w latach 60. i 70. są teraz zbyt starzy, aby zdobyć nowe rzeczy i wiedzą, jak używać FORTRAN całkiem dobrze. Mam na myśli, że istnieje wiele czynników ludzkich, które mogą być używane w danym języku. Ważny jest również programista.