Czy kompilatory Intel są naprawdę lepsze od kompilatorów Microsoft? [Zamknięte]

Wiele lat temu byłem zaskoczony, gdy odkryłem, że Intel sprzedaje kompilatory kompatybilne z Visual Studio. Próbowałem w szczególności dla C / C ++, a także fantastycznych narzędzi diagnostycznych. Ale kod po prostu nie był tak intensywny obliczeniowo, aby zauważyć różnicę. Jedyne wrażenie brzmiało: czy Intel naprawdę zrobił to teraz dla mnie, wow, niesamowite narzędzia z rozdzielczością nanosekund, niewiarygodne. Ale proces się zakończył i zespół nigdy poważnie nie rozważał zakupu.

Z własnego doświadczenia wynika, że ​​jeśli koszt licencji nie ma znaczenia, który sprzedawca jest zwycięzcą?

To nie jest ogólne ani niejasne pytanie ani próba wywołania świętej wojny. Tego rodzaju pytanie dotyczy dwóch bardzo widocznych narzędzi. Nikt nie lubi, gdy narzędzia mają jakieś tajemnice lub niespodzianki. A wybór między najlepszym a najlepszym zawsze jest bólem. Rozumiem również, że trawa to zawsze bardziej zielony argument. Chcę usłyszeć wszystkie historie „co jeśli”.

Co się stanie, jeśli Intel tylko lokalnie zoptymalizuje go pod kątem zwiększenia liczby układów w miesiącu, a nie każdy cel sprzętowy będzie działał tak dobrze, jak skompilowany przez Microsoft? Co jeśli sprzęt AMD jest celem i wszystko spowolni się bez powodu? Albo z drugiej strony, co jeśli sprzęt Intela ma tak wiele niezauważalnych możliwości, że autorzy kompilatora Microsoft są zbyt wolni, aby je adoptować i nigdy nie wdrażają w kompilatorze? Co jeśli oba są dokładnie takie same, właściwie jedna baza kodu jest właśnie zapakowana w dwa różne pudełka i licencjonowana obu sprzedawcom przez sklep innej firmy?

I tak dalej. Ale ktoś zna odpowiedzi.

OSTRZEŻENIE: Odpowiedź na podstawie własnego doświadczenia - YMMV

Jeśli kod jest naprawdę drogi obliczeniowo, tak, zdecydowanie . Widziałem poprawę ponad 20 razy w porównaniu z poprzednim kompilatorem Intel C ++ (teraz Intel Studio, jeśli dobrze pamiętam) w porównaniu ze standardowym kompilatorem Microsoft Visual C ++. To prawda, że ​​kod był bardzo daleki od ideału i to mogło odegrać pewną rolę (właściwie dlatego kłopotaliśmy się użyciem kompilatora Intela, było to łatwiejsze niż refaktoryzacja gigantycznej bazy kodu), również procesor użyty do uruchomienia kodu był Intel Core 2 Quad, który jest idealnym procesorem do takich rzeczy, ale wyniki były szokujące. Sam kompilator zawiera niezliczone sposoby optymalizacji kodu, w tym ukierunkowanie na konkretny procesor pod względem, powiedzmy, możliwości SSE . Naprawdę wstydzi się -O2/ -O3ucieka. I tak byłoprzed użyciem profilera.

Pamiętaj jednak, że włączenie naprawdę agresywnych optymalizacji sprawi, że kompilacja zajmie trochę czasu, dwie godziny dla dużego projektu wcale nie są niemożliwe. Ponadto przy wysokich poziomach optymalizacji istnieje większa szansa, że ​​błąd w kodzie się zamanifestuje (można to również zaobserwować w przypadku gcc -O3). W przypadku projektu, który dobrze znasz, może to być plus, ponieważ znajdziesz i naprawisz ewentualne błędy, których wcześniej nie złapałeś, ale podczas kompilacji włochatego bałaganu po prostu trzymasz kciuki i modlisz się do bogów x86.

Coś na temat wydajności na maszynach AMD: nie jest tak dobra jak procesory Intel, ale wciąż jest znacznie lepsza niż kompilator MS C ++ (znowu, z mojego doświadczenia). Powodem jest to, że możesz również celować w ogólny procesor ze wsparciem SSE2 (na przykład). Wtedy procesory AMD z SSE2 nie będą dyskryminowane. Jednak kompilator Intel na procesorze Intel naprawdę kradnie serial. Jednak nie wszystkie podwójne tęcze i błyszczące jednorożce. Pojawiły się poważne oskarżenia o to, że pliki binarne w ogóle nie działają na nieoryginalnych procesorach Intel i (ten przyznaje) sztucznie wywołane gorszą wydajność procesorów przez innych dostawców. Pamiętaj też, że są to informacje sprzed co najmniej 3 lat, a ich aktualność na razie nie jest znana, ALE nowe opisy produktów dają plikom binarnym blankiet, aby działał tak wolno, jak Intel uważa za odpowiedni na procesorach innych niż Intel.

Nie wiem, o co chodzi z Intelem i dlaczego tworzą tak dobre narzędzia do obliczeń numerycznych, ale spójrz też na to: http://julialang.org/ . Istnieje porównanie i jeśli spojrzysz na ostatni wiersz, MATLAB świeci, pokonując zarówno kod C, jak i Julię , uderza mnie to, że autorzy uważają, że powodem jest biblioteka jądra Math Intela .

Zdaję sobie sprawę, że brzmi to jak reklama zestawu narzędzi Intel Compiler, ale z mojego doświadczenia naprawdę dobrze sobie poradziła, a nawet prosta logika nakazuje, że faceci, którzy produkują procesory, powinni najlepiej wiedzieć, jak je zaprogramować. IMO, kompilator Intel C ++ ściska każdy możliwy możliwy wzrost wydajności.

Intel Compiler ma reputację producenta bardzo wydajnego kodu numerycznego:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Pamiętaj, że nie twierdzę, że jest to najszybszy kompilator na rynku, ale z pewnością cieszy się bardzo dobrą opinią pod względem wydajności. Zauważ, że autorzy „oficjalnych” plików binarnych LAPACK dla Windows używają kompilatora Intel Fortran do ich budowy: http://icl.cs.utk.edu/lapack-for-windows/ i powinni wiedzieć coś o wydajności.

Oprócz generatora kodu Intel C ++ ma kilka zalet w porównaniu z gcc. Oba wynikają (w dużej mierze) z faktu, że są oparte na interfejsie EDG . Na lepsze lub gorsze, oba z nich (powoli) ulegają erozji, więc zalety nie są tak duże, jak kiedyś.

Po pierwsze, z reguły generuje znacznie lepsze komunikaty o błędach. Możesz spojrzeć na porównanie komunikatów o błędach między Clangiem a gcc. Intel C ++ (wraz z większością innych opartych na interfejsie EDG) od lat wydaje diagnostykę podobną do Clanga.

Po drugie, fronton EDG jest tak dobrze znany z wyjątkowo dobrej zgodności językowej, jak generator kodów Intel do generowania szybkiego kodu. Prawie każdy rozsądny środek nakładki EDG zapewnia lepszą zgodność z C ++ 98, 03 lub (w aktualnych wersjach) C ++ 0x niż jakikolwiek inny dostępny kompilator.

Jak powiedziałem, obie te zalety z czasem uległy erozji w różnym stopniu. Najnowsze wersje gcc mają całkiem przyzwoitą zgodność językową. Clang ma znacznie lepsze komunikaty o błędach i robi również duże postępy w implementacji całego języka C ++. Jednak od samego początku Intel C ++ jest wciąż lepszy od obu pod jednym względem i jest to pojedynczy pakiet, który robi większość rzeczy właściwie, zamiast wymagać jednego kompilatora do dobrej diagnostyki, a drugiego do lepszej zgodności i generowania kodu.

Próbowaliśmy tego w pracy jakiś czas temu. Większość naszej bazy kodu znajduje się w Delphi, ale mamy bardzo intensywną obliczeniowo funkcjonalność, o której ktoś pomyślałby, że dobrym pomysłem byłoby zrobienie tego w bibliotece DLL C ++. Jeden z moich współpracowników słyszał wspaniałe rzeczy o kompilatorze Intela, więc postanowił go wypróbować. Przebudowaliśmy bibliotekę DLL w kompilatorze Intela i przeprowadziliśmy kilka testów prędkości, a wyniki zaskoczyły go tak bardzo, że doszedł do wniosku, że musi robić coś złego.

DLL musi obliczyć niektóre bardzo trudne problemy z kombinatorami i komponentami topologii, które technicznie znajdują się w klasie trudności NP-trudnej, jeśli zrobiliśmy je „dobrze”, ale używamy różnych heurystyk, aby uniknąć wydajności NP. Mimo to dzieje się dużo chrupania liczb. W przeprowadzonych testach różnica między kompilatorem VS a kompilatorem Intela była albo w epsilon, albo kompilator Intela był zauważalnie wolniejszy, zwykle o około 20%. I tak pozostało bez względu na to, jakie zmiany wprowadził w ustawieniach kompilacji, aby zmusić kompilator Intela do szybszego tworzenia kodu. Skończyło się na tym, że nie przeszliśmy na to.

To oczywiście tylko jeden przykład z prawdziwego świata. Twój przebieg może się różnić.

W aplikacji wbudowanej, nad którą kiedyś pracowałem, wersja próbna kompilatora Intela wykazała, że ​​zaoszczędziłoby nam to konieczności uruchamiania nowego sprzętu o wyższej wydajności. Koszt nowego sprzętu wyniósł około 10 USD / sztukę, prognozowano sprzedaż 1 miliona sztuk, Dodaj koszty rozwoju i opóźnienia projektu. Opcja 2 polegała na optymalizacji profilu / mikro i już dość dobrze profilowanej / zoptymalizowanej bazie kodu - nieznane wyniki, nieznany czas.

Jak myślisz, co powiedział szef, kiedy poprosiliśmy o fundusze na zakup kompilatora .......

Jednak - to był bardzo szczęśliwy i rzadszy przypadek - 10% szybsze wyjście kodu z kompilatora Intela zepchnęło nas z powrotem na właściwą stronę wydajności. Gdybyśmy byli już po prawej stronie lub przekroczyli 10%, nie zrobiłoby to różnicy. Gdybyśmy mieli inżynierów, prawdopodobnie moglibyśmy zoptymalizować kod i zaoszczędzić spin sprzętu i nie potrzebowaliśmy kompilatora Intela, ale ryzyko było wysokie, a kompilator Intela działał taniej niż czas inżynierii.

Podsumowując, powiedziałbym, że jest to forma mikrooptymalizacji - nie rób tego, dopóki nie będziesz wiedział, że musisz, a dopiero potem, gdy profilujesz i znajdziesz właściwą przyczynę problemów. Jest to szczególnie dobry wybór profilu, który pokazuje, że jesteś powolny „wszędzie” i nie masz żadnych zidentyfikowanych szyjek butelek.

Spotkałem tylko trzy zalety:

1. Obsługuje funkcje nowszych procesorów Intel znacznie wcześniej niż inne kompilatory.

2. Jest to świetny dodatkowy kompilator do wydawania ostrzeżeń i wychwytywania problemów, których brakuje innym kompilatorom. GCC łapie pewne rzeczy, których ICC nie ma i odwrotnie. Studio wizualne wyłapuje niektóre rzeczy, których ICC nie ma i na odwrót.

3. Znacznie lepiej wykonuje automatyczne równoległe pętle (automatycznie rozdzielając je na wiele wątków) niż jakikolwiek inny kompilator. Z tego nie korzysta zbyt wiele kodu, ale jeśli masz kod, który robi, może to zrobić różnicę.

Używamy kompilatora Intel do każdego krytycznego pod względem wydajności projektu naszej bazy kodu. Wspaniałą rzeczą jest to, że sprawia, że ​​optymalizacja kodu jest naprawdę łatwa w utrzymaniu. Zamiast ręcznie dodawać wszędzie __mm wywołania i polecać kompilatorowi, aby pobierał dane, które w następnym wydaniu będą ponownie nieoptymalne, po prostu zmieniasz kod i zyskujesz szalone przyspieszenie.

Często zoptymalizowany kod jest łatwiejszy do naśladowania niż zoptymalizowany ręcznie, jest szybszy niż zoptymalizowany ręcznie, a kiedy nowy zestaw instrukcji zostanie wydany, kompilator użyje tego zestawu instrukcji. To jest fantastyczne.

To samo dotyczy kompilatora ramienia (z ramienia, a nie z wywiadu), jeśli wypuszczenie na ramieniu świetnie się sprawdza w wektoryzacji.

Sprawdź tę stronę testu. Krótko mówiąc, Intel wygrywa.

Ale margines może nie być tak duży: jeśli skompilujesz do wersji 32-bitowej, a Twój system kompilacji nie może poprowadzić optymalizacji profilu, zysk jest rzędu 10%. Czy takie ulepszenie jest warte kłopotów i dłuższych czasów kompilacji?

Mówi się, że Intel wydał kompilator Intel C ++ v13.0 dla systemu operacyjnego Android, pierwszą próbę dostarczenia optymalizującego kompilatora C / C ++ zaprojektowanego specjalnie dla platformy mobilnej Google.

Programiści mogą używać kompilatora w systemach opartych na systemie Linux * do tworzenia aplikacji dla urządzeń z systemem Android opartych na procesorach Intel, w tym procesorze Intel® Atom ™. Kompilator Intel jest kompatybilny z GNU C ++ i narzędziami programistycznymi w Android Native Development Kit (NDK). Kompilatora nie można również używać na żadnym komputerze do programowania. Ani Windows, ani OS X nie są obsługiwane; narzędzia są certyfikowane tylko do użytku z Ubuntu 10.04 lub 11.04

Obecna wersja systemu Android NDK domyślnie korzysta z wersji 4.6 zestawu narzędzi Gnu Compiler Collection (GCC). Ale kompilatory Intela zawierają wiele zastrzeżonych optymalizacji dla własnych układów i często mogą generować kod wykonywalny, który działa lepiej niż ten generowany przez kompilatory innych firm, takie jak GCC.