Jest jakiś ustandaryzowany sposób pomiary szybkości kompilatora c++ ?
Jaki projekt open source polecacie do testowania szybkości budowania ?
Wymagania:
multiplatformowy: Linux , Windows , MacOS
kompilacja około kwadransa
w miarę proste zalezności idealnie jakby samo cmake + standardowe biblioteki
1
4
dobre optymalizacje zwykle wymagają poświęcenia czasu. kompilator zorientowany na wysoką wydajność generowanego kodu może się kiepsko skalować w kierunku szybkiego generowania niskiej jakości (powolnego i zasobożernego) kodu.
0
W sumie to myślałem tylko o g++ i clang++
Ale rzeczywiście mozna potraktowac problem szerzej
tylko nie wiem czy te alternatywne kompilatory poradzą sobie z projektem z github-a
Bo jak jakiś pasjonat zrobi kompilator do jednego projektu to na pewno będzie najszybszy
1
Nie ma standardu. Długość budowania bardzo zależy od twojego projektu: projekty bliżej C będą spędzały więcej czasu na backendzie, gdzie zaawansowany kod w C++ to zdecydowanie frontent. Poziom optymalizacji mozna wydłuża procesowanie na backendzie
Jedyne co zostaje to benchmarki na interesujących dla ciebie repo w poprawnie statystyczny sposób i wyciągnięcie średniej geometrycznej, żeby mieć konkretną liczbę, która powie gcc/clang jest lepszy od clang/gcc
1
kompilacja około kwadransa
A pójść w wielowątkowość/jakoś to zrównoleglić nie można? Sam aż tak bardzo w ekosystemie C nie siedzę, ale na szybko poszukałem i znalazłem m.in. Niektóre kompilatory, takie jak GCC (od wersji 9) i Clang/LLVM, mają ograniczone wsparcie dla wielowątkowości podczas kompilacji pojedynczego pliku (np. optymalizacje, analiza kodu).. Jest też np. parametr -j X przy make, który określa ile jobs będzie odpalane jednocześnie.
Ogólnie o co mi chodzi: nie wiem, czy poszczególne kompromitatory będą miały między sobą aż tak znaczące różnice, żeby ten kwadrans się zmienił na półtorej minuty. Będą to raczej sekundowe odchyłki, dla których nie jest warto tracić czas na kombinowanie. Raczej poszedłbym w kierunku dostrojenia opcji kompilacji (wielowątkowość, optymalizacje kompilatora itp.) i/lub jakąś mocną maszynę, na której kompilacja będzie śmigać. Poza tym (nie wiem, jak często to budujecie) podczas takich kompilacji testowych/rozwojowych można wyłączyć optymalizacje - zgodnie z tym, co napisał powyżej @Wibowit: mamy zależność taką, że lepiej zoptymalizowany kod dłużej powstaje, za to szybko wypluta binarka będzie gorzej dostrojona. A takie "porządne" kompilowanie (które potrzebuje dużo czasu) zrobić przed pchnięciem tematu na produkcję.
4
cerrato napisał(a):
A pójść w wielowątkowość/jakoś to zrównoleglić nie można?
Da się, ale kompilatory C++ (jak i C) osiągają https://en.wikipedia.org/wiki/Embarrassingly_parallel duplikując jakieś 90% pracy dla każdego pliku *.cpp; dlatego też takie rozwiązania jak https://en.wikipedia.org/wiki/Unity_build są tak popularne. Kompilacja wielowątkowa w C++ to praktycznie standard. Warto wiedzieć, że kompilatory C/C++ to straszny śmieć jeśli chodzi o wydajność budowania i standardowa logika wyniesiona z innych języków może zawodzić
Co do optymalizacji kompilacji to trzeba po prostu nad tym pracować. Ogarnianie swojego kodu da dużo większe rezultaty niż jakiekolwiek tunowanie kompilatora. Oczywiście warto ogarnąć podstawy takie jak caching czy precompiled headers
mamy zależność taką, że lepiej zoptymalizowany kod dłużej powstaje,
To zależy. W poprzedniej pracy optymalizowałem czasy budowania przy użyciu https://github.com/aras-p/ClangBuildAnalyzer (@Marius.Maximus polecam bardzo swoją drogą, nawet jak tylko dla clanga to złożoność twojego kodu jest raczej podobna dla gcc jak i clanga). Przy mocnym użyciu templatów i ogromnej drobnicy plików *.cpp (co duplikuje processing headerów i kodu) frontend phase (czyli głównie analiza kodu i konwersja do SSA/IR) to był główny koszt. Czytałem kiedyś blog jakiegoś gościa z community Rusta, który potwierdzał, że generalnie nie ma reguły i różne projekty mają różne ratio pomiędzy czasem spędzonym na frontendzie/backendzie
2
na phoronixie testują kompilację jądra liunksa , i może(?) coś jeszcze
https://www.phoronix-test-suite.com/
1
Ostatnio z ciekawości sprawdziłem kompilacje mojego projektu na 80 wątkowym systemie (
i ku mojemu zaskoczeniu wcale nie był to rekordowo szybki build. Może i wyrwał z kopyta na początku ale po chwili ilość użytego procesora spadała , potem rosła i spadała.
Sądząc po konsoli i zużyciu procesorów to linkowanie jest wąskim gardłem
I finalnie wyszło że 80 watkowy cpu ma czas budowania ułamek sekundy wolniej jak 24 wątkowy i9 (2x Xeon Gold 5218R vs i9-7920X)
3
Marius.Maximus napisał(a):
Sądząc po konsoli i zużyciu procesorów to linkowanie jest wąskim gardłem
Tak bardzo często jest. Polecam nie używać standardowego ld/gold tylko lld lub https://github.com/rui314/mold .
i ku mojemu zaskoczeniu wcale nie był to rekordowo szybki build. Może i wyrwał z kopyta na początku ale po chwili ilość użytego procesora spadała , potem rosła i spadała.
I finalnie wyszło że 80 watkowy cpu ma czas budowania ułamek sekundy wolniej jak 24 wątkowy i9 (2x Xeon Gold 5218R vs i9-7920X)
Jak mam strzelać to po prostu duża część twojego buildu jest odpalana na jednym wątku, po prostu Prawo Amdahla. Jeśli linkowanie zajmuje długo czasu i jest jednordzeniowe (tak pewnie jest jak nie ustawiłeś lepszego linkera) to ma to sens, że szybki rdzeń procesora klasy desktop pokonał wolny rdzeń procesora klasy server.
4
Jeżeli polegamy tylko na zrównoleglaniu to do pierwszych ośmiu wątków możemy dostać fajny boost, ale koniec końców linker główny target będzie linkował w jednym wątku i nie ma możliwości by to obejść, także dodawanie kolejnych wątków już nie daje takich korzyści. Maszyna z 80 rdzeniami powinna być wykorzystywana do uruchamiania kilku buildów jednocześnie inaczej zasoby będą się marnować. Jedyną optymalizacją linkowania jaką znam to linkowanie inkrementacyjne, dostępne jako opcja w VisualStudio, ale to rozwiązanie tylko dla Debug.
Jeśli chcesz dalej przyspieszyć budowanie, to są dwie kolejne popularne opcje - prekompilowane nagłówki i unity builds. Można je stosować razem. Prekompilowane nagłówki to ficzer kompilatorów i można je stosować nawet jak budujesz bashem. Zbudowanie takiego nagłówka trochę trwa, dlatego panuje przekonanie, że są pomocne głównie przy budowaniu inkrementacyjnym, gdy już pierwszy raz zbudowałeś projekt. Z mojego doświadczenia, przy dużym projekcie, przyspieszają one znacznie nawet i pierwsze budowanie bo wtedy dla każdego pliku nie marnujesz czasu na coś, co zostało już przetworzone.
Unity builds, albo amalgamated builds mają na celu zredukowanie I/O w trakcie budowania, czyli zamiast stu plików budujesz np. pięć. Często jest to najszybszy sposób by zbudować projekt "na czysto" bo oprócz wyraźnej redukcji I/O, to praca którą wykonał kompilator np. przy przetwarzaniu STL może być wykorzystywana dla większej ilości kodu więc mamy też wyraźnie mniej marnotrawienia czasu na robieniu czegoś co inny wątek już zrobił.
(edit literówki)
1
Były też zabawy w rozporszenie kompilacji projektów w C++ na wiele maszyn. https://www.distcc.org/
Co do metod robienia benchmarków to zacząłbym od szperania po publikacjach w portalach do przeglądania takowych. Tak, wiem że tak można podsumować każde pytanie, ale co robić skoro w sumie trudno nie polecić tego podejścia jeśli nie padły dotąd jakieś bliższe konkrety w tym wątku.
0
Bazel
0
Z komentarzy.
Wolny kompilator, ale dobra optymalizacja Bazelem da lepsze efekty niz szybki kompilator
Optymalizacje typu prekompilowane nagłówki lub unity builds dają znakomite efekty i nie wymagają do tego zarządzania dodatkowym softwarem.
Minus taki, ze to wymaga pracy, a kompilator nie
Wprowadzenie optymalizacji o których pisałem też wymaga uwagi i nie działa out of the box. Nie będzie to na pewno aż tak czasochłonne jak zarządzanie dodatkowym softwarem na JVM, przez co tym bardziej się dziwie, że ktoś preferuje zignorować to co oferuje kompilator by bawić się w devopsa przez kilka dni/tygodni.