Sind Intel-Compiler wirklich besser als die von Microsoft? [geschlossen]

Vor Jahren war ich überrascht, als ich entdeckte, dass Intel Visual Studio-kompatible Compiler verkauft. Ich habe es insbesondere für C / C ++ sowie fantastische Diagnosetools ausprobiert. Aber der Code war einfach nicht so rechenintensiv, um den Unterschied zu bemerken. Der einzige Eindruck war: Hat Intel es gerade wirklich für mich getan, wow, erstaunliche Tools mit Nanosekunden-Auflösung, unglaublich. Aber der Prozess endete und das Team hat nie ernsthaft über einen Kauf nachgedacht.

Welcher Anbieter ist Ihrer Erfahrung nach der Gewinner, wenn die Lizenzkosten keine Rolle spielen?

Es ist keine breite oder vage Frage oder Absicht, einen heiligen Krieg auszulösen. Bei dieser Art von Frage handelt es sich um zwei sehr gut sichtbare Werkzeuge. Niemand mag es, wenn Werkzeuge irgendwelche Geheimnisse oder Überraschungen haben. Und die Wahl zwischen den Besten und Besten ist immer der Schmerz. Ich verstehe auch, dass Gras immer ein grüneres Argument ist. Ich möchte alle "Was wäre wenn" -Geschichten hören.

Was ist, wenn Intel es nur lokal für das Chip-Stepping des Monats optimiert und nicht jedes Hardware-Ziel tatsächlich so gut funktioniert, wie Microsoft es kompiliert hat? Was ist, wenn AMD-Hardware das Ziel ist und alles ohne Grund langsamer wird? Oder auf der anderen Seite, wenn Intels Hardware so viele unbemerkt bleibende Möglichkeiten bietet, dass Microsoft-Compiler-Autoren zu langsam sind, um sie zu übernehmen, und sie niemals im Compiler implementieren? Was ist, wenn beide genau gleich sind, tatsächlich eine einzige Codebasis, die nur in zwei verschiedene Boxen eingepackt und von einem Drittanbieter-Shop an beide Anbieter lizenziert wurde?

Und so weiter. Aber jemand kennt einige Antworten.

WARNUNG: Die Antwort basiert auf eigenen Erfahrungen - YMMV

Wenn der Code wirklich rechenintensiv ist , auf jeden Fall . Ich habe mit dem früheren Intel C ++ Compiler (jetzt Intel Studio, wenn ich mich richtig erinnere) eine 20-fache Verbesserung gegenüber dem standardmäßigen Microsoft Visual C ++ Compiler festgestellt. Es ist wahr, der Code war bei weitem nicht perfekt und das könnte eine Rolle gespielt haben (eigentlich haben wir uns darum die Mühe gemacht, den Intel-Compiler zu verwenden, es war einfacher als das Refactoring der riesigen Codebasis), auch die CPU, auf der der Code ausgeführt wurde, war ein Intel Core 2 Quad, das ist die perfekte CPU für so etwas, aber die Ergebnisse waren schockierend. Der Compiler selbst enthält unzählige Möglichkeiten zur Codeoptimierung, einschließlich der Ausrichtung auf eine bestimmte CPU, beispielsweise im Hinblick auf SSE- Funktionen. Es macht wirklich beschämt -O2/ -O3weglaufen. Und das war es auchbevor Sie den Profiler verwenden.

Beachten Sie jedoch, dass das Aktivieren wirklich aggressiver Optimierungen einige Zeit in Anspruch nimmt. Zwei Stunden sind für ein großes Projekt nicht unmöglich. Außerdem besteht bei hohen Optimierungsstufen eine höhere Wahrscheinlichkeit, dass sich ein Fehler im Code manifestiert (dies kann auch mit gcc beobachtet -O3werden). Für ein Projekt, das Sie gut kennen, kann dies ein Plus sein, da Sie alle eventuellen Fehler finden und beheben, die Sie zuvor nicht entdeckt haben. Wenn Sie jedoch ein haariges Durcheinander anrichten, drücken Sie einfach die Daumen und beten zu den x86-Göttern.

Etwas über die Leistung auf AMD-Maschinen: Es ist nicht so gut wie Intel-CPUs, aber es ist immer noch viel besser als der MS C ++ - Compiler (wieder aus meiner Erfahrung). Der Grund ist, dass Sie auch eine generische CPU mit SSE2- Unterstützung als Ziel festlegen können (zum Beispiel). Dann werden AMD-CPUs mit SSE2 nicht viel unterschieden. Intel-Compiler auf Intel-CPU stiehlt die Show jedoch wirklich. Es sind jedoch nicht nur doppelte Regenbogen und glänzende Einhörner. Es gab einige schwere Vorwürfe darüber, dass Binärdateien auf Nicht-GenuineIntel-CPUs überhaupt nicht ausgeführt werden und (dies ist zugegeben) von anderen Anbietern künstlich eine schlechtere Leistung auf CPUs hervorgerufen wurden. Beachten Sie auch, dass dies Informationen aus mindestens 3 Jahren sind und die Gültigkeit zum jetzigen Zeitpunkt nicht bekannt ist. ABER die neuen Produktbeschreibungen geben Binärdateien die Möglichkeit, so langsam zu arbeiten, wie Intel dies für Nicht-Intel-CPUs für richtig hält.

Ich weiß nicht, worum es bei Intel geht und warum sie so gute numerische Berechnungswerkzeuge sind, aber sehen Sie sich das auch an: http://julialang.org/ . Es gibt einen Vergleich, und wenn Sie sich die letzte Zeile ansehen, strahlt MATLAB aus, indem es sowohl C-Code als auch Julia besiegt. Was mir auffällt, ist, dass die Autoren glauben, dass der Grund Intels Math Kernel Library ist .

Mir ist klar, dass dies sehr nach Werbung für das Intel Compiler-Toolkit klingt, aber meiner Erfahrung nach hat es wirklich gute Arbeit geleistet, und selbst die einfache Logik schreibt vor, dass die Hersteller von CPUs am besten wissen sollten, wie sie für sie programmieren sollen. IMO, der Intel C ++ - Compiler schränkt jeden noch so geringen Leistungszuwachs ein.

Intel Compiler hat den Ruf, sehr effizienten numerischen Code zu erzeugen:

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/

Bitte beachten Sie, dass ich behaupte nicht , dass es ist der schnellste Compiler gibt, aber es genießt sicherlich einen sehr guten Ruf für Effizienz. Beachten Sie, dass die Autoren "offizieller" LAPACK-Binärdateien für Windows den Intel Fortran-Compiler verwenden, um sie zu erstellen: http://icl.cs.utk.edu/lapack-for-windows/, und sie sollten ein oder zwei Dinge über Effizienz wissen.

Intel C ++ hat zusätzlich zum Codegenerator einige Vorteile gegenüber gcc. Beide sind (weitgehend) darauf zurückzuführen, dass sie auf dem EDG- Frontend basieren . Egal ob gut oder schlecht, beide schwinden (langsam), sodass die Vorteile bei weitem nicht mehr so ​​groß sind wie früher.

Das erste ist, dass es in der Regel viel bessere Fehlermeldungen ausgibt. Vielleicht möchten Sie sich einen Vergleich der Fehlermeldungen zwischen Clang und gcc ansehen . Intel C ++ (zusammen mit den meisten anderen, die auf dem EDG-Frontend basieren) gibt seit Jahren Diagnosen heraus, die denen von Clang ähneln.

Zweitens ist das EDG-Frontend für seine außergewöhnlich gute Sprachkonformität ebenso bekannt wie der Intel-Codegenerator für die Erzeugung von schnellem Code. Das EDG-Frontend bietet in nahezu allen vernünftigen Fällen eine bessere Konformität mit C ++ 98, 03 oder (in aktuellen Versionen) C ++ 0x als jeder andere verfügbare Compiler.

Wie ich bereits sagte, haben beide Vorteile im Laufe der Zeit in unterschiedlichem Maße nachgelassen. Aktuelle Versionen von gcc haben eine recht gute Sprachkonformität. Clang hat wesentlich bessere Fehlermeldungen und macht gute Fortschritte bei der Implementierung der gesamten C ++ - Sprache. Intel C ++ ist jedoch immer noch besser als jedes andere, und es ist ein einzelnes Paket, das die meisten Dinge richtig macht, anstatt einen Compiler für eine gute Diagnose und einen anderen für eine bessere Konformität und Codegenerierung zu benötigen.

Wir haben das vor einiger Zeit bei der Arbeit versucht. Der Großteil unserer Codebasis befindet sich in Delphi, aber wir haben einige sehr rechenintensive Funktionen, von denen jemand dachte, dass es eine gute Idee wäre, dies in einer C ++ - DLL zu tun, als es noch möglich war. Und einer meiner Kollegen hatte großartige Dinge über den Intel-Compiler gehört, und er beschloss, es auszuprobieren. Wir haben die DLL im Intel-Compiler neu erstellt und einige Geschwindigkeitstests durchgeführt, und die Ergebnisse haben ihn so überrascht, dass er dachte, er müsse etwas falsch machen.

Die DLL muss einige sehr schwierige Probleme mit Kombinatorik- und Topologiekomponenten berechnen, die technisch in der Schwierigkeitsklasse NP-schwer liegen, wenn wir sie "richtig" gemacht haben, aber wir verwenden verschiedene Heuristiken, um NP-Leistung zu vermeiden. Trotzdem gibt es eine Menge Zahlenknirschen. Und für die Tests, die wir durchgeführt haben, lag der Unterschied zwischen dem VS-Compiler und dem Intel-Compiler entweder innerhalb von epsilon oder der Intel-Compiler war merklich langsamer, im Allgemeinen um etwa 20%. Und es blieb so, egal welche Änderungen er an den Kompilierungseinstellungen vorgenommen hatte, um den Intel-Compiler dazu zu bringen, schnelleren Code zu produzieren. Also sind wir nicht dazu gewechselt.

Dies ist natürlich nur ein Beispiel aus der Praxis. Ihr Kilometerstand kann variieren.

In einer Embedded-Anwendung, an der ich einmal gearbeitet habe, hat ein Test eines Intel-Compilers gezeigt, dass wir keine neue Hardware mit höherer Leistung drehen müssen. Die Kosten für die neue Hardware beliefen sich auf rund 10 US-Dollar pro Einheit, prognostizierten Umsatz von 1 Million Einheiten, zusätzlichen Entwicklungskosten und Projektverzögerungen. Option 2 war eine Profil- / Mikrooptimierung und eine bereits einigermaßen gut profilierte / optimierte Codebasis - unbekannte Ergebnisse, unbekannte Zeit.

Was glaubst du, sagte der Chef, als wir nach dem Geld fragten, um den Compiler zu kaufen?

Allerdings - dies war ein sehr glücklicher und seltener Fall - brachte uns die 10% schnellere Code-Ausgabe des Intel-Compilers wieder auf die richtige Seite der Leistung. Wenn wir schon auf der rechten Seite wären oder 10% darüber wären, hätte das keinen Unterschied gemacht. Hätten wir die Ingenieure gehabt, hätten wir wahrscheinlich den Code optimieren und den Hardware-Spin speichern können und brauchten den Intel-Compiler nicht. Aber das Risiko war hoch und der Intel-Compiler arbeitete billiger als die Entwicklungszeit.

Alles in allem würde ich sagen, es ist eine Form der Mikrooptimierung. Tun Sie dies erst, wenn Sie wissen, dass Sie es tun müssen, und erst dann, wenn Sie die eigentliche Ursache für die Probleme ermittelt haben. Es ist eine besonders gute Wahl für Sie, wenn Ihr Profil zeigt, dass Sie "überall" langsam sind und keine identifizierten Engpässe haben.

Ich habe nur drei Vorteile festgestellt:

1. Es unterstützt Funktionen neuerer Intel-CPUs viel früher als andere Compiler.

2. Es ist ein großartiger zusätzlicher Compiler, um Warnungen auszugeben und Probleme zu erkennen, die andere Compiler vermissen. GCC fängt einige Dinge ab, die ICC nicht hat, und umgekehrt. Visual Studio erkennt einige Dinge, die ICC nicht kennt, und umgekehrt.

3. Die automatische Parallelisierung von Schleifen (automatische Verteilung auf mehrere Threads) ist wesentlich besser als bei jedem anderen Compiler. Nicht sehr viel Code profitiert davon, aber wenn Sie Code haben, der dies tut, kann dies einen verdammten Unterschied bewirken.

Wir verwenden den Intel-Compiler für jedes leistungskritische Projekt unserer Codebasis. Das Tolle daran ist, dass das Optimieren von Code wirklich wartbar ist. Anstatt __mm-Aufrufe überall manuell hinzuzufügen und dem Compiler anzuweisen, Daten vorab abzurufen, die in der nächsten Version alle nicht optimal sind, ordnen Sie einfach Ihren Code neu und beschleunigen die Verarbeitung.

Häufig ist der optimierte Code einfacher zu befolgen als der handoptimierte. Er ist schneller als der handoptimierte. Wenn ein neuer Befehlssatz veröffentlicht wird, verwendet der Compiler diesen Befehlssatz. Es ist fantastisch.

Dasselbe gilt auch für den Arm-Compiler (von Arm, nicht Intel), wenn Ihre Freigabe auf Arm eine großartige Arbeit bei der Vektorisierung für Sie leistet.

Überprüfen Sie diese Benchmark-Seite. Kurz gesagt, Intel gewinnt.

Die Marge ist jedoch möglicherweise nicht so groß: Wenn Sie auf 32-Bit kompilieren und Ihr Build-System die profilgesteuerte Optimierung nicht unterstützt, liegt der Gewinn in der Größenordnung von 10%. Lohnt sich eine solche Verbesserung für Sie und die längeren Kompilierzeiten?

Es wurde berichtet, dass Intel den Intel C ++ Compiler v13.0 für Android OS herausgebracht hat, den ersten Versuch, einen optimierten C / C ++ - Compiler bereitzustellen, der speziell für die mobile Plattform von Google entwickelt wurde.

Entwickler können den Compiler auf Linux * -basierten Systemen verwenden, um Apps für Android-Geräte zu erstellen, die auf Intel-Prozessoren basieren, einschließlich des Intel® Atom ™ -Prozessors. Der Intel-Compiler ist kompatibel mit GNU C ++ und Entwicklertools im Android Native Development Kit (NDK). Sie können den Compiler auch nicht auf jedem anderen Entwicklungscomputer verwenden. Weder Windows noch OS X werden unterstützt. Die Tools sind nur für die Verwendung mit Ubuntu 10.04 oder 11.04 zertifiziert

Die aktuelle Version des Android NDK verwendet standardmäßig Version 4.6 der Open-Source-Toolchain Gnu Compiler Collection (GCC). Die Compiler von Intel enthalten jedoch zahlreiche proprietäre Optimierungen für ihre eigenen Chips und können häufig ausführbaren Code ausgeben, der eine bessere Leistung als der von Compilern von Drittanbietern wie GCC aufweist.