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

56

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.

Peter Mortensen
źródło
17
Kompilatory Intel mają reputację bardzo wydajnego kodu numerycznego.
quant_dev
2
@honk: Jeśli quant_dev może dostarczyć linki do kopii zapasowej, to tak, powinno być!
FrustratedWithFormsDesigner
2
@RocketSurgeon: Nie wszyscy zgodzą się z tym stwierdzeniem. W rzeczywistości Eric Raymond jest dość silnym argumentem za tym, że Microsoft wstrzymał postęp obliczeń o kilka dziesięcioleci swoimi praktykami biznesowymi.
Mason Wheeler
2
@RocketSurgeon open source nie ma nic wspólnego z pieniędzmi.
kaoD
1
Kompilator Microsoft generuje bardzo dobry kod. Ręczna inspekcja zestawu rzadko znajduje idiotyczne sekwencje instrukcji. W rzeczywistości byłem pod wrażeniem, jak głęboko idą optymalizacje, nawet zapobiega przekroczeniu granic instrukcji w pamięci podręcznej.
doug65536

Odpowiedzi:

57

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.

K.Steff
źródło
@ K.Steff Czy porównałeś ten kompilator vs ms z opcją wyboru programu i optymalizacją profilową?
powtórnie
2
Intel został zmuszony do ujawnienia, że ich kompilator celowo używa niezoptymalizowanych ścieżek kodu w czasie wykonywania, jeśli procesor nie jest produkowany przez Intel. Intel wpadł w kłopoty z FTC . Nie mogłeś mi zapłacić za korzystanie z ICC. Nie dotknąłbym tego antykonkurencyjnego badziewia z 10-metrowym kijem.
doug65536
@ doug65536 Pytanie brzmi: „Czy kompilatory Intela są naprawdę lepsze”, a nie „Czy Intel jest monopolistą na rynku sprzętu komputerowego, który nadużywa tego monopolu w celu dalszego zdobywania podstaw w oprogramowaniu”. Nie twierdzę, że twój komentarz jest nie na temat, ale dla mnie ideologii nie ma miejsca w tej dyskusji. Użyj lub nie - twoje połączenie, ale to nie zmieni faktu, że ICC jest cholernie dobry w tworzeniu plików binarnych dla procesorów Intel.
K.Steff
Język C, który stał się popularny w latach 90., rozszerzył język C na wiele sposobów, które pozwoliły programistom pisać bardziej wydajny kod, ale których niektóre kompilatory optymalizujące nie obsługują. Z tego, co mogę powiedzieć, Microsoft jest mniej chętny niż inni dostawcy do przeprowadzania optymalizacji, które byłyby niezgodne z takimi rozszerzeniami. To sprawia, że ​​ich kompilatory są mniej wydajne niż te, które nie dbają o taką kompatybilność podczas przetwarzania kodu, który ich nie wymaga, ale pozwala na prawidłowe przetwarzanie kodu, który ich wymaga.
supercat
35

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.

quant_dev
źródło
2
Ma nie tylko tę reputację, ale zasługuje na nią. Nie jest konieczne, jeśli używasz go do pisania aplikacji CRUD, ale produkty C, C ++ i FORTRAN są absolutnie surowe, jeśli chodzi o łamanie liczb.
Blrfl,
27

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.

Jerry Coffin
źródło
14

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ć.

Mason Wheeler
źródło
Czy mógłbyś podzielić się szczegółami dotyczącymi procesora, na którym uruchomiono testy?
Oak
22
Kiedy przeczytałem twój pierwszy akapit, pomyślałem, że mówisz, że wyniki testu prędkości zaskoczyły go w dobry sposób. Najwyraźniej to źle, po przeczytaniu drugiego akapitu. Nie jestem pewien, co mnie wprowadziło w błąd podczas pierwszego czytania; po bliższym przyjrzeniu się, tak naprawdę nie używasz żadnych pozytywnych słów, które mogłyby mnie opuścić. Pomyślałem, że skomentuję na wypadek, gdyby ktokolwiek popełnił ten sam błąd i nie rozumie, co tu właściwie mówisz.
Cody Gray
2
Czy korzystałeś z procesora AMD do testowania? Myślę, że to istotna informacja (czy kompilator źle działał celowo, czy też nie mógł nic zrobić, nawet jeśli robił wszystko, co mógł).
Przywróć Monikę
3
Jest to procesor Intel Core i7.
Mason Wheeler
Krótka wersja: Intel był wolniejszy niż VS2010. Próbowałem tego równie dobrze niedawno w bazie danych dość zwięzłych danych C ++. Próbowałem wielu różnych ustawień. Niektóre indywidualne algorytmy z już istniejącymi testami wydajności stały się zauważalnie szybsze, ale najbardziej zauważalnie wolniejsze. Ogólnie rzecz biorąc, każda operacja na wysokim poziomie, którą wykonałem z oprogramowaniem, była konsekwentnie i wymiernie wolniejsza. Próbowałem tego również w wersjach kompilatora Intela z 2013 i 2010 r., 2010 wydaje się lepiej kodować, a także być bardziej stabilny. Większość moich testów była na AVX i7, ale niektóre na starszym Core2.
Bogaty
9

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.

mattnz
źródło
5

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ę.

David Schwartz
źródło
3

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.

martiert
źródło
+1. Intel ma kompilator ARM? Niewiarygodne!
1
Nie, Intel nie ma kompilatora ARM. ARM ma jednak kompilator ARM, który wykonuje fantastyczną robotę.
martiert
2
„EDYCJA: uzbrojenie nie ma kompilatora uzbrojenia.” czy to naprawdę miałeś na myśli?
luiscubal
0

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?

jdv-Jan de Vaan
źródło
Link URL wydaje się być martwy.
Contango,
0

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.

LOG_TAG
źródło