C ++ vs Fortran dla HPC

W moim programie doktoranckim z zakresu obliczeń pracujemy prawie wyłącznie w C ++ i Fortran. Wygląda na to, że niektórzy profesorowie wolą jeden od drugiego. Zastanawiam się, który z nich jest „lepszy” lub czy w pewnych okolicznościach jest lepszy od drugiego.

Jak często wybór zależy od (1) problemu, który próbujesz rozwiązać, (2) posiadanych umiejętności i (3) osób, z którymi współpracujesz (chyba że jest to projekt solowy). Na razie zostawię (3) na bok, ponieważ zależy to od indywidualnej sytuacji każdego.

Zależność od problemu: Fortran przoduje w przetwarzaniu tablic. Jeśli Twój problem można opisać w kategoriach prostych struktur danych, aw szczególności tablic, Fortran jest dobrze przystosowany. Programiści Fortran używają tablic nawet w nieoczywistych przypadkach (np. Do reprezentowania wykresów). C ++ lepiej nadaje się do złożonych i wysoce dynamicznych struktur danych.

Zależność od umiejętności: pisanie dobrych programów w C ++ zajmuje dużo więcej doświadczenia niż pisanie dobrych programów w Fortranie. Jeśli zaczynasz z niewielkim doświadczeniem w programowaniu i masz tak dużo czasu, aby nauczyć się tego aspektu swojej pracy, prawdopodobnie uzyskasz lepszy zwrot z inwestycji w Fortran niż w C ++. Zakładając oczywiście, że twój problem pasuje do Fortrana.

Jednak programowanie to coś więcej niż tylko Fortran i C ++. Polecam każdemu, kto zaczyna naukę obliczeń, aby zacząć od dynamicznego języka wysokiego poziomu, takiego jak Python. Zawsze pamiętaj, że Twój czas jest cenniejszy niż czas procesora!

Myślę, że zarówno C ++, jak i Fortran są wystarczająco dobre i działają dobrze.

Myślę jednak, że Fortran jest lepszy do numerycznego obliczenia naukowego, do algorytmów, które można wyrazić za pomocą tablic i nie potrzebują innych wyrafinowanych struktur danych, więc w dziedzinach takich jak różnice skończone / elementy, solwery PDE, obliczenia struktury elektronicznej. Fortran jest językiem specyficznym dla domeny. W szczególności myślę, że łatwiej jest pisać szybko programy w Fortranie niż w C ++ przez naukowca (niekoniecznie eksperta w dziedzinie informatyki).

C ++ jest językiem ogólnego przeznaczenia, więc można w nim wyrazić dowolny algorytm, i jest zdecydowanie lepszy dla algorytmów, których nie można wyrazić za pomocą tablic, z pola HPC prawdopodobnie niektóre wykresy, generatory siatki, manipulacje symboliczne i tak dalej.

Możliwe jest także pisanie algorytmów tablicowych w C ++, ale z mojego doświadczenia wynika, że ​​wymaga to znacznie większej wiedzy informatycznej i ogólnie więcej pracy (tj. Trzeba stworzyć lub ponownie wykorzystać klasy do manipulacji tablicami i ręcznie zarządzać pamięcią biblioteka taka jak Teuchos z Trilinos). Nie-eksperci zwykle piszą całkiem dobre programy Fortran, ale okropne programy C ++ (mówiąc z własnego doświadczenia).

Oświadczenie: Osobiście bardzo lubię Fortran i wolę go od C ++ do obliczeń numerycznych. Spędziłem ponad 2 lata programowania w C ++ codziennie i prawie rok programowania w nowoczesnym dzienniku Fortran (w obszarze elementów skończonych). Często używam Python i Cython.

Rzucam też swoje dwa centy trochę za późno, ale dopiero co widziałem ten wątek i czuję, że dla potomnych jest kilka kwestii, które desperacko trzeba poczynić.

Zauważ, że będę mówić o C, a nie C ++. Dlaczego? Cóż, inaczej jabłka i pomarańcze porównują pełnoprawny, dynamicznie typowany obiektowy język z czymś tak statycznym jak Fortran. Tak, niektóre współczesne implementacje najnowszych standardów Fortran mogą zrobić coś więcej, ale bardzo niewiele osób z nich korzysta, więc kiedy mówimy o Fortranie, myślimy o języku prostym, statycznym i imperatywnym. Tam też jest C, więc zamienię C na C ++ dla następujących.

Przede wszystkim dyskusja na temat Fortran / C z lepszymi kompilatorami jest dyskusyjna. Dedykowane kompilatory C / Fortran należą już do przeszłości. Zarówno gcc / gfortran, jak i icc / ifc to po prostu różne interfejsy do tego samego zaplecza, tzn. Twój program zostanie przekształcony w abstrakcyjny opis przez interfejs, a następnie zoptymalizowany i złożony przez back-end. Jeśli napiszesz semantycznie ten sam kod w Fortran lub w C, kompilator w obu przypadkach utworzy ten sam zestaw, który będzie działał równie szybko.

To prowadzi teraz do mojej drugiej kwestii: dlaczego wciąż widzimy różnice? Problem polega na tym, że większość porównań przeprowadzają programiści Fortrana próbujący czegoś w C lub odwrotnie. Czy zauważyłeś kiedyś, jak większość autorów lub poetów woli pisać w swoich językach ojczystych? Czy chciałbyś pisać wiersze w języku, w którym nie czujesz się całkowicie pewny siebie lub w domu? Oczywiście, że nie ... Sam uważam C za mój „rodzimy” język programowania. Spędziłem jednak również trzy lata pracując w grupie, która korzystała wyłącznie z Fortranu, w której osiągnąłem pewien poziom biegłości. Jednak nigdy nie napisałbym niczego samodzielnie w Fortranie, ponieważ czuję się bardziej komfortowo z językiem C, w wyniku czego powstały kod będzie lepszy , bez względu na to, jak go zdefiniujesz.

Główną różnicą jest programista, a nie język. Więc nie ma różnic? Cóż, niezupełnie. Oto kilka przykładów:

• SIMD: Bez względu na to, czy chodzi o SSE, SSE3 czy AltiVec, jeśli chcesz ich używać w Fortranie, lepiej miej nadzieję i módl się, aby kompilator zgadł dokładnie, co chcesz i tak robi. Powodzenia. W C na ogół masz funkcje wewnętrzne dla każdej architektury lub, ostatnio, ogólne typy wektorów SIMD w gcc . Większość kompilatorów Fortran będzie używać tylko instrukcji SIMD do rozwijania pętli, ale jeśli masz jądro, które działa na krótkich wektorach danych w nieoczywisty sposób, kompilator najprawdopodobniej go nie zobaczy.

• Różne architektury sprzętowe: cała architektura CUDA jest zbudowana wokół jąder w C. Tak, grupa Portland ma teraz także kompilator fortran kompatybilny z CUDA , ale jest komercyjny, a co najważniejsze, nie pochodzi od NVIDIA. To samo dotyczy OpenCL, dla którego najlepsze, co mogłem znaleźć, to najnowszy projekt, który obsługuje tylko kilka podstawowych wywołań.

• Programowanie równoległe: Tak, zarówno MPI, jak i OpenMP działają dobrze zarówno z C, jak i Fortranem. Jeśli jednak chcesz mieć rzeczywistą kontrolę nad swoimi wątkami, tj. Jeśli masz w pełni dynamiczne obliczenia z pamięcią współużytkowaną, Fortran nie będzie ci zimno. W C masz standardowe wątki, które, choć nie są ciepłe i rozmyte, nadal prowadzą cię przez burzę. Ogólnie rzecz biorąc, większość obliczeń opartych na dostępie do systemu operacyjnego, np. Wątki, procesy, system plików itp., Lepiej jest obsługiwać w języku C. Och, i nie próbuj tworzyć sieci z Fortranem.

• Łatwość użycia: Fortran jest bliższy Matlabowi niż C. Po zapoznaniu się z wszystkimi różnymi słowami kluczowymi i sposobem deklarowania zmiennych, reszta kodu wygląda jak Matlab, dzięki czemu jest bardziej dostępny dla użytkowników o ograniczonym doświadczeniu programistycznym.

• Interoperacyjność: kiedy tworzysz strukturę w C, układ rzeczywistych danych jest prosty i deterministyczny. W Fortran, jeśli używasz tablic wskaźników lub danych strukturalnych, faktyczny układ danych jest silnie zależny od kompilatora, nie jest prosty i zwykle całkowicie nieudokumentowany. Możesz zadzwonić do C z Fortran i odwrotnie, ale nie zaczynaj myśleć, że może być tak łatwo przekazać coś więcej niż statyczną tablicę z jednej strony na drugą iz powrotem.

To wszystko jest trochę dziwaczne, na niskim poziomie, ale mówimy o obliczeniach o wysokiej wydajności, prawda? Jeśli nie jesteś zainteresowany tym, jak najlepiej wykorzystać podstawowe paradygmaty sprzętowe, tj. Wdrażanie i / lub opracowywanie algorytmów, które są najlepsze dla pamięci współużytkowanej / rozproszonej, wątków, wektoryzacji SIMD, GPU korzystających z SIMT i tak dalej, to jesteś po prostu wykonuję matematykę na komputerze.

Stało się to znacznie dłużej niż cokolwiek, w co uczestniczyłem, więc oto podsumowanie - zestaw pewnego rodzaju wiadomości:

• Będziesz pisać najlepszą kod Państwo może w języku, który cię znasz najlepiej.
• Nie ma różnicy w jakości kodu wytwarzanego przez dwa kompilatory, które używają tego samego zaplecza - to my piszemy zły kod w tym czy innym języku.
• Pomimo poczucia niskiego poziomu, Fortran jest dość wysokim poziomem abstrakcji i nie pozwala na bezpośredni dostęp do niektórych funkcji sprzętu / systemu operacyjnego, np. SIMD, wątków, sieci itp.

Z moich 15 lat myślenia o oprogramowaniu naukowym: jeśli Twój kod działa o 25% szybciej, ponieważ piszesz go w Fortran, ale napisanie go zajmuje 4 razy dłużej (bez STL, trudności z implementacją złożonych struktur danych itp.), To Fortran wygrywa tylko wtedy, gdy spędzasz znaczną część swojego dnia kręcąc kciukami i czekając na zakończenie obliczeń. Biorąc pod uwagę, że dla prawie każdego z nas najcenniejszą rzeczą jest nasz własny czas, wniosek jest następujący: użyj języka, który pozwala ci najszybciej opracowywać, debugować i testować swój kod, w granicach rozsądku ignorując, że może być wolniejszy niż być może możliwe, jeśli napisałeś to w Fortranie.

Moje podejście polegało na użyciu C ++ do wszystkiego oprócz jąder obliczeniowych, które zwykle najlepiej pisać w asemblerze; kupuje to całą wydajność tradycyjnego podejścia HPC, ale pozwala uprościć interfejs, np. przez przeciążenie jąder obliczeniowych, takich jak SGEMM / DGEMM / CGEMM / ZGEMM, w jedną procedurę, powiedzmy Gemm. Oczywiście poziom abstrakcji można podnieść znacznie wyżej, unikając surowych wskaźników i przechodząc do nieprzejrzystych klas, ale jest to dobry pierwszy krok.

Uważam, że największym minusem C ++ jest w przeważającej mierze wzrost czasu kompilacji, ale z mojego doświadczenia wynika, że ​​oszczędności czasu na programowanie nadrabiają. Inną wadą jest to, że kompilatory C ++ dostawcy mają zwykle więcej błędów niż kompilatory C i Fortran. Wydaje mi się, że w ubiegłym roku napotkałem prawie dziesięć błędów w kompilatorach C ++.

Biorąc to wszystko pod uwagę, myślę, że cofanie pakietów naukowych napisanych w językach niskiego poziomu (i Fortran) jest niechęcią do ujawniania wygodnych interfejsów dla skomplikowanych struktur danych: większość ludzi jest zadowolona z interfejsu Fortran BLAS, ponieważ wymaga on tylko wskaźników i wiodących wymiarów do opisania macierzy, ale niewiele osób twierdziło, że zwykły 40-całkowity interfejs Fortran Sparse-Direct Solver jest zbliżony do dogodnego (por. UHM, SuperLU, PETSc i Trilinos).

Podsumowując, opowiadam się za użyciem asemblera do niskopoziomowych jąder obliczeniowych, ale języków wyższego poziomu do wszystkiego innego, szczególnie podczas pracy na nietrywialnych strukturach danych.

$y := \alpha x + y$

Ponieważ jestem tu nowy, przeglądałem stare pytania i znalazłem to. Mam nadzieję, że odpowiedź na stare nie jest tabu!

Ponieważ nikt o tym nie wspominał, pomyślałem. Fortran 2003 jest prawie w pełni obsługiwany przez większość głównych kompilatorów (intel, ibm, cray, NAG, PCG), nawet gcc z (wkrótce) najnowszą wersją 4.7. Fortran 2003 (i 2008) to język obiektowy, choć nieco bardziej szczegółowy niż C ++. Jedną z rzeczy, które moim zdaniem są miłe w Fortranie, jest fakt, że komitet standardowy postrzega naukę komputerową jako swoją główną publiczność (dziękuję Damianowi Rousonowi za wskazanie mi tego dnia).

Mówię o tym nie po to, aby programiści C ++ stali się programistami Fortran, ale aby ludzie Fortranu wiedzieli, że mają teraz więcej opcji niż przejście na C ++ lub emulowanie obiektowych koncepcji w Fortran 90/95.

Dodam jedno zastrzeżenie, że bycie na krawędzi tego, co jest zaimplementowane w kompilatorach, kosztuje. Jeśli podejmiesz się teraz dużego projektu w Fortran 2003, natkniesz się na błędy i będziesz musiał ciągle aktualizować swój kompilator (szczególnie jeśli używasz gcc), chociaż w ostatnich miesiącach sytuacja uległa znacznej poprawie!

Problem z C ++ polega na tym, że masz wiele szans na pogorszenie wydajności, na przykład ślepe używanie STL, wyjątki, klasy (narzut wirtualny plus problemy z wyrównaniem), przeciążenie operatora (nadmiarowe nowe / usuwanie) lub szablony (niekończąca się kompilacja i tajemnicze błędy wydają się łagodne, ale możesz w ten sposób marnować godziny).

Jednak im bardziej zyskujesz lepszy dostęp do bibliotek ogólnych i być może większą widoczność swojego kodu (chociaż to silnie zależy od pola i nadal masz czyste C). Nadal możesz zrekompensować brak elastyczności Fortrana, zawijając jego kod w języku skryptowym, takim jak R, Lush, Matlab / Scilab, a nawet Python, Ruby lub Lua.

Trzy fakty:

• Tablice n-wymiarowe w stylu F77 w C: Nie ma problemu z użyciem CnD ( oczywiście bezwstydna wtyczka)

• System modułów F90 jest źle zaprojektowany i nieprzyjazny do budowania środowisk. (Nazwa modułu nie musi odpowiadać nazwie pliku, np.)

• Fortran nie obsługuje dobrze refaktoryzacji. Wyciągnięcie odrobiny funkcjonalności z funkcji wymaga dotknięcia czterech miejsc: rzeczywistego kodu, deklaracji zmiennych, deklaracji argumentów i listy argumentów. C ma dwa miejsca do dotknięcia. To pogarsza efekt braku dobrego zarządzania danymi (opisany poniżej): Ponieważ modułowość na małą skalę jest tak bolesna, prawie wszyscy piszą gigantyczne podprogramy.

Jedno osobiste wrażenie:

• Fortran nie działa dobrze do zarządzania danymi. Spróbuj zwrócić wskaźnik do nieprzezroczystej dla użytkownika struktury danych w F77 lub F90. ( transfer()tutaj nadchodzimy)

Fortran jest zoptymalizowany do obliczeń macierzowych / macierzowych i jest bardzo trudny w pracy z każdym typem parsowania tekstu. C i C ++ mogą nie pasować do Fortrana w obliczeniach numerycznych (jest blisko), ale znacznie łatwiej jest mi przetwarzać tekst i organizować dane (tj. Niestandardowe struktury danych) za pomocą C / C ++.

Jak wspomnieli inni, nie licz na dynamicznie interpretowane języki (Python i in.). Mogą nie oferować szybkości topnienia twarzy Fortan z góry, ale pozwalają skupić się bardziej na rozwiązaniu problemu obliczeniowego niż na wszystkich szczegółach implementacji. Często możesz zaimplementować rozwiązanie w Pythonie, a jeśli wydajność jest niedopuszczalna, wykonaj profilowanie, zidentyfikuj obszary problemowe i zoptymalizuj ten kod za pomocą Cython lub ponownie zaimplementuj cały program w skompilowanym języku. Kiedy już rozwiążemy logikę rozwiązywania problemów, reszta to tylko implementacja i, przy dobrym zrozumieniu podstaw obliczeniowych, powinna być prosta do reprezentowania w różnych językach programowania.

Obecnie pracuję w jednym z krajowych laboratoriów. Większość ludzi wokół mnie to inżynierowie mechanicy. Rozmawiając z niektórymi ludźmi w grupach HPC, robią głównie Linux i głównie C ++. Grupa, w której aktualnie pracuję, zajmuje się głównie aplikacjami komputerowymi i używamy systemu Windows w malejącej kolejności: C #, FORTRAN, Python, VBA i VB (6, nie .NET). Niektóre z używanych przez nas silników symulacyjnych zostały napisane w innych krajowych laboratoriach w FORTRAN.

Przepraszamy za wykopanie starego wątku, ale wydaje się, że nawet w 2015 r. Fortran jest często używany.

Właśnie natknąłem się na tę (alternatywny link ) listę, która w zasadzie jest listą 13 kodów zatwierdzonych przez obiekt OCLF firmy DOE do uruchomienia na maszynie Summit 300-petaFLOPS, która zostanie udostępniona badaczom w 2018 roku. Próbowałem znaleźć główny używany język dla kodu (na podstawie szybkiego wyszukiwania w Google) i oto, co znalazłem:

XGC Fortran

SPECFEM Fortran

ACME Fortran (Bunch of climate codes)

DIRAC Fortran (Mostly)

FLASH Fortran

GTC Fortran

HACC C/C++

LS-DALTON Fortran (some C)

NAMD C/C++

NUCCOR Fortran

NWCHEM Fortran

QMCPACK C++

RAPTOR Fortran

Tak więc spośród 13 kodów przynajmniej 10 (w oparciu o moje szybkie wyszukiwanie) wydaje się być napisanych w Fortranie. Nieźle jak na 50-letni język.

UWAGA: Zdaję sobie sprawę z tego, że porównania językowe są bezużyteczne, ale biorąc pod uwagę liczbę osób (szczególnie użytkowników C ++), którzy mają nieprzyzwoite Fortran, pomyślałem, że warto o tym wspomnieć.

Myślę, że Jack P. próbuje powiedzieć, że powinieneś mieszać i dopasowywać. Dobry program jest starannie ułożony warstwowo. Różne warstwy mogą być mapowane bardziej naturalnie lub wydajniej na różne języki. Powinieneś wybrać najbardziej odpowiedni język dla każdej warstwy. Należy również zrozumieć, w jaki sposób języki mogą ze sobą współdziałać, co może wpłynąć na wybrany język dla danej warstwy.

Lepszym pytaniem jest, jakie są przykłady doskonale zaprojektowanego oprogramowania, które warto zbadać, aby dowiedzieć się, jak zaprojektować oprogramowanie warstwowe.