LLVM JITC vs. GCC

[Ganon]

Achtung. Alter Thread. Bitte runterscrollen

Hi.

Es ist ja inzwischen Version 2.0 von LLVM erhältlich. http://www.llvm.org

Wer es nicht kennt, LLVM ist eine Low-Level-Virtual-Machine. Diese übersetzt C/C++ Code in eine Zwischensprache, die dann von einem Just-In-Time Compiler für die entsprechende Prozessor-Architektur übersetzt wird. Der Vorteil ist, das dieser Bytecode bisher mit einer Datei auf x86, x64, ppc, ia64, arm, sparc und alpha läuft.

Nun habe ich mal mit SciMark2 getestet:
http://math.nist.gov/scimark2/download_c.html

Um es mal vorweg zu nehmen, ich war erstaunt das auf meinem G4 1,25 Ghz, der JITC-Code gleich schnell, bis deutlich schneller läuft, als der native Code, den der GCC ausspuckt.

Hier die Ergebnisse:

Nativ kompiliert:
cc -o scimark2 -O3 *.c -o scimark_native

LLVM kompiliert:
llvm-gcc -O3 -emit-llvm *.c -c
llvm-link *.o -o scimark.bc

./scimark_native

Composite Score: 215.23
FFT Mflops: 192.95 (N=1024)
SOR Mflops: 215.06 (100 x 100)
MonteCarlo: Mflops: 35.89
Sparse matmult Mflops: 264.26 (N=1000, nz=5000)
LU Mflops: 368.01 (M=100, N=100)


lli scimark.bc

Composite Score: 238.28
FFT Mflops: 227.11 (N=1024)
SOR Mflops: 328.83 (100 x 100)
MonteCarlo: Mflops: 37.81
Sparse matmult Mflops: 251.10 (N=1000, nz=5000)
LU Mflops: 346.53 (M=100, N=100)



Large-Version

./scimark_native -large

Composite Score: 68.70
FFT Mflops: 21.52 (N=1048576)
SOR Mflops: 139.87 (1000 x 1000)
MonteCarlo: Mflops: 35.79
Sparse matmult Mflops: 66.49 (N=100000, nz=1000000)
LU Mflops: 79.84 (M=1000, N=1000)


lli scimark.bc -large

Composite Score: 76.98
FFT Mflops: 19.52 (N=1048576)
SOR Mflops: 179.92 (1000 x 1000)
MonteCarlo: Mflops: 37.91
Sparse matmult Mflops: 65.64 (N=100000, nz=1000000)
LU Mflops: 81.90 (M=1000, N=1000)


Da das nur ein Test ist und meine CPU nun auch schon etwas alt ist, würden mich schon weitere Tests interessieren. :)

Vllt. hat ja jemand Lust dazu. Ich finde dieses Projekt weiterhin sehr interessant. Genutzt wird es schon in OS X Leopard im OpenGL Stack. Dies wird Apple wahrscheinlich noch ausbauen (um ggf. Universal Binary zu ersetzen).

:)

[Stone2001]

Die LLVM ist ein schöner Beweis, dass man mit JIT zumindest die gleiche Performance wie mit native Übersetzungen erreichen kann.
Weißt du, ob die LLVM inzwischen OpenMP oder ähnliches unterstützt?

[Coda]

Naja, ein echter JITC is was anderes, weil der ja während das Programm ausgeführt wird kompiliert. Das Ding übersetzt alles vor dem Start, wenn ich das richtig verstanden habe. Es wird praktisch einfach die Backend-Stage des Compilers verzögert.

[Ganon]

Also soweit ich weiß wird OpenMP (noch) nicht unterstützt.

Es wird aber zur Zeit aktiv an LLVM gewerkelt. 25% aller Mitarbeiter an LLVM stellt Apple ^^ Es ist anzunehmen das man LLVM Systemweit einsetzen will.

Man arbeitet zur Zeit an allen Ecken und Enden und es geht gut voran. Die Performance ist prächtig. Das will man ausbauen. Mehr Sprachen (ObjC, z.B. ;)) und natürlich JITCs für IA64 usw.

Es wird wohl auch schon auf dem iPhone eingesetzt.

[Ganon]

Das Ding übersetzt alles vor dem Start, wenn ich das richtig verstanden habe.

Also in nativen Code kann man das Programm mit LLVM auch verwandeln (Programm: llc). Also den Bytecode in nativen Code. Nur ist das auch langsamer als den JiTC zu benutzen (Programm: lli). (ca. 229 Punkte beim ersten Test)

Es wird praktisch einfach die Backend-Stage des Compilers verzögert.

... daher kann ich mir das nicht so ganz vorstellen. Woher kommt die Mehrperformance, wenn nicht durch Laufzeitoptimierung?

edit:
Und so wie sich der Abschnitt
THE JELLO VIRTUAL MACHINE
hier liest (Vorsicht, altes Dokument, inzwischen wurde der auch auf PowerPC ausgeweitet ;)):
http://llvm.org/ProjectsWithLLVM/2002-Spring-CS497CZ-Jello.pdf

Ist es wohl ein JITC, denn Jello ist in lli eingebaut, so wie ich das verstanden habe.

[Stone2001]

... daher kann ich mir das nicht so ganz vorstellen. Woher kommt die Mehrperformance, wenn nicht durch Laufzeitoptimierung?

JIT-Übersetzung oder auch Dynamic Binary Optimization sind in der Lage Programme sträker zu optimieren, als es normale Compiler können (unter gewissen Umständen). Wenn der Code natürlich nur einmal verwendet wird, dann ist der Overhead zu groß.
Häufig wiederholte Codefragmente kann man aber als Binärcode zwischenspeichern und erreicht dadurch schonmal eine fast native Performance.
Zusätzlich kann man diese Codefragmente durch Laufzeitinformationen, die beim normalen Übersetzten nicht zur Verfügung stehen, weiter optimieren und so, trotz anfänglicher Interpretation, eine bessere Performance erreichen.

Bei Digital FX32 (also das Verfahren, das verwendet wurde um WinNT (oder x86-Binaries) auf einem Alpha auszuführen), wird der Code in den Kontextwechseln übersetzt. Beim DynamoRIO (HP und MIT) aber wird z.B. HP-RISC-Binaries dynamisch zur Laufzeit in HP-RISC-Binaries übersetzt (Kombinierter Interpreter und Binäroptimierungsansatz), wobei eine Beschleunigung von ca. 20% erreicht wurde.

[Ganon]

Für die, die es Interessiert, das Ganze statisch mit LLVM kompiliert. Also quasi vorkompiliert und nicht über den JiTC:


FFT Mflops: 225.94 (N=1024)
SOR Mflops: 328.83 (100 x 100)
MonteCarlo: Mflops: 37.81
Sparse matmult Mflops: 197.40 (N=1000, nz=5000)
LU Mflops: 339.64 (M=100, N=100)


Ist langsamer, wie man sieht, aber schneller als der GCC.

@Stone2001

Eben, das meinte ich ja. Da die JiTC-Version schneller ist, muss es ja ein optimierter JiTC und nicht wie Coda annimmt, ein AOTC sein.

[Ganon]

Thread mal auskramen...

So sieht es bei mir unter Linux 64bit LLVM 2.6 auf einem Athlon X2 5200+ aus.


clang 1.0
Using 2.00 seconds min time per kenel.
Composite Score: 690.75
FFT Mflops: 714.85 (N=1024)
SOR Mflops: 653.21 (100 x 100)
MonteCarlo: Mflops: 254.44
Sparse matmult Mflops: 768.75 (N=1000, nz=5000)
LU Mflops: 1062.52 (M=100, N=100)

gcc 4.4.3
Using 2.00 seconds min time per kenel.
Composite Score: 678.65
FFT Mflops: 709.04 (N=1024)
SOR Mflops: 648.81 (100 x 100)
MonteCarlo: Mflops: 204.13
Sparse matmult Mflops: 768.75 (N=1000, nz=5000)
LU Mflops: 1062.52 (M=100, N=100)

lli
Using 2.00 seconds min time per kenel.
Composite Score: 650.37
FFT Mflops: 673.45 (N=1024)
SOR Mflops: 644.47 (100 x 100)
MonteCarlo: Mflops: 289.42
Sparse matmult Mflops: 766.50 (N=1000, nz=5000)
LU Mflops: 878.03 (M=100, N=100)


Nativer Code kompiliert mit Clang ist ganz oben. GCC nativ ist im Mittelfeld, "dicht" gefolgt vom JiTC von LLVM. :)

[Gast]

Hast du noch ein Ergebnis mit gcc 4.2.4?

[Ganon]

Ich kann sonst nur noch OS X Snow Leopard 10.6 Werte anbieten.

clang 1.0.1, gcc 4.2.1 und LLVM 2.6 - Core 2 Duo 2Ghz


clang
Using 2.00 seconds min time per kenel.
Composite Score: 606.86
FFT Mflops: 480.05 (N=1024)
SOR Mflops: 604.65 (100 x 100)
MonteCarlo: Mflops: 237.04
Sparse matmult Mflops: 725.90 (N=1000, nz=5000)
LU Mflops: 986.67 (M=100, N=100)

gcc 4.2.1
Using 2.00 seconds min time per kenel.
Composite Score: 606.04
FFT Mflops: 450.42 (N=1024)
SOR Mflops: 601.64 (100 x 100)
MonteCarlo: Mflops: 236.44
Sparse matmult Mflops: 818.63 (N=1000, nz=5000)
LU Mflops: 923.07 (M=100, N=100)

lli
Using 2.00 seconds min time per kenel.
Composite Score: 606.73
FFT Mflops: 484.35 (N=1024)
SOR Mflops: 605.01 (100 x 100)
MonteCarlo: Mflops: 247.30
Sparse matmult Mflops: 743.11 (N=1000, nz=5000)
LU Mflops: 953.87 (M=100, N=100)


Die sehen allgemein schon etwas anders aus. Mit Linux kann man aufgrund von Versions/Bibliotheks-Unterschieden jetzt aber leider nicht vergleichen. Die Unterschiede Nativ vs. JiTC scheinen auf einem Core2Duo unter OS X aber nicht so groß zu sein.

Ansonsten ist alles OpenSource. Kann sich jeder Installieren.

[Coda]

LLVM sieht wirklich gut aus. Würde mich nicht wundern, wenn das langfristig auch der Default-Linux-Compiler wird. Das Design ist einfach viel moderner.

[Ganon]

LLVM sieht wirklich gut aus. Würde mich nicht wundern, wenn das langfristig auch der Default-Linux-Compiler wird. Das Design ist einfach viel moderner.

Clang macht auch immer mehr Fortschritte. Free- und OpenBSD nutzen den Clang-Analyser bereits, um logische Fehler im Quelltext zu suchen und haben auch schon diverse Fehler gefunden und behoben.

Clang macht auch im C++ immer mehr Fortschritte. Seit neustem ist es möglich mit Clang das komplette LLVM+Clang zu übersetzen (550.000 Zeilen C++-Quellcode). Qt baut auch schon teilweise, cmake komplett. Nur boost streikt fast komplett, aber das ist nicht verwunderlich, da es quasi das gesamte C++-Spektrum nutzt, was clang noch nicht kann.

Default-Compiler unter Linux generell bezweifle ich aber noch. LLVM hat zwar eine BSD-Lizenz, aber es ist halt kein "GNU-Kind". Man wird es sehen.

Default-Compiler für FreeBSD Base ist bereits in Arbeit und funktioniert auch schon größtenteils (Code aus Solaris macht noch Stress). OpenBSD favorisiert eher den eigenen pcc.

[Gast]

LLVM bietet auch ein Backend für die Programmiersprache D.

Die werkeln zwar momentan nur an D 1.0,
aber sobald D 2.0 offiziell stable ist, wird auch das in Angriff genommen.

[Ganon]

Es gibt für fast alle Sprachen arbeiten an Frontends...

Java, Mono, Python, Perl, C, C++, D, MSIL (alles von .NET), Fortran, PHP, etc...

Das ist ja auch Sinn von LLVM. Man bietet eine Compiler-Infrastruktur und kann so jede Sprache mit einem Backend compilieren. Wird das LLVM-Backend optimiert, dann profitieren alle Sprachen. Unterstützt LLVM eine neue CPU, unterstützen es alle Sprachen... Native Code, Interpreter, JiTC, alles möglich.

[Ganon]

Ich habe mal die aktuelle SVN-Version von LLVM/Clang runtergeladen und installiert (Snow Leopard).


clang
Using 2.00 seconds min time per kenel.
Composite Score: 661.63
FFT Mflops: 485.51 (N=1024)
SOR Mflops: 707.93 (100 x 100)
MonteCarlo: Mflops: 234.42
Sparse matmult Mflops: 771.69 (N=1000, nz=5000)
LU Mflops: 1108.60 (M=100, N=100)

lli
Using 2.00 seconds min time per kenel.
Composite Score: 651.84
FFT Mflops: 476.13 (N=1024)
SOR Mflops: 687.17 (100 x 100)
MonteCarlo: Mflops: 241.91
Sparse matmult Mflops: 757.65 (N=1000, nz=5000)
LU Mflops: 1096.35 (M=100, N=100)


Scheint so, als kommt man mit der Performance gut voran ^^ Aber erst mal schauen was der Final-Release sagt.

[Coda]

LLVM bietet auch ein Backend für die Programmiersprache D.
Du meinst Frontend.

[Als DAU getarnt]

Du meinst Frontend.

Wo ist denn da der Unterschied?

[Gnafoo]

Frontend: Programmiersprache --> Zwischensprache (hier LLVM mit SSA-Form)
Midend: Zwischensprache --> Zwischensprache (Optimierungen etc.)
Backend: Zwischensprache --> Maschinencode/Assembler

[Gast]

Die sehen allgemein schon etwas anders aus. Mit Linux kann man aufgrund von Versions/Bibliotheks-Unterschieden jetzt aber leider nicht vergleichen.Mit GCC kann man überhaupt garnichts vergleichen. Selbst mit gleichen flags auf der gleichen CPU ändert sich die Leistung des gleichen Kodes von Version zu Version teils bis zu 10%. Und es ist ja nicht so, daß wenn schon, alles immer schneller wird.

Beispiel:
http://botan.randombit.net/news/benchmarks/1_7_18.html

[Coda]

Unter solchen Problemen leiden aber fast alle Compiler, weil Veränderungen am Code der für die Optimierung zuständig ist leicht unabsichtliche Seiteneffekte produziert.

Lies dir z.B. mal das durch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928

GCC hat bei 4.0 SSA und damit eine komplett neue Infrastruktur eingeführt, deshalb gibt es seither immer noch viele Regressions ggü. älteren Versionen. SSA hat aber prinzipiell deutliche Vorteile. Gut Ding will Weile haben:

http://vmakarov.fedorapeople.org/spec/I2Score64.png

[Gast]

Prinzipeill richtig, nur

GCC hat bei 4.0 SSA und damit eine komplett neue Infrastruktur eingeführt, deshalb gibt es seither immer noch viele Regressions ggü. älteren Versionen.bei Botan wird ja nur 4.x gefahren.

[Gast]

Mit GCC kann man überhaupt garnichts vergleichen. Selbst mit gleichen flags auf der gleichen CPU ändert sich die Leistung des gleichen Kodes von Version zu Version teils bis zu 10%. Und es ist ja nicht so, daß wenn schon, alles immer schneller wird.

Beispiel:
http://botan.randombit.net/news/benchmarks/1_7_18.html


WOW, daß der Intel Compiler im Vergleich zum GCC derart arschlahm ist, hätte ich nicht gedacht.

Ich dachte immer der Intel Compiler wäre so verdammt gut, weil er so verdammt schnell sei und der GCC nicht so gut, weil zu langsam?
Und jetzt das. Daß der GCC ihm völlig davon zieht überrascht mich wirklich.

Woran liegt es also, daß der Intel Compiler bei vielen Leuten noch so ein hohes Ansehen hat?

[Gast]

WOW, daß der Intel Compiler im Vergleich zum GCC derart arschlahm ist, hätte ich nicht gedacht.

Ich dachte immer der Intel Compiler wäre so verdammt gut, weil er so verdammt schnell sei und der GCC nicht so gut, weil zu langsam?
Und jetzt das. Daß der GCC ihm völlig davon zieht überrascht mich wirklich.

Woran liegt es also, daß der Intel Compiler bei vielen Leuten noch so ein hohes Ansehen hat?

1.Weil er in SPEC auf Intel CPUs hohe Ergebnisse produziert.
2.Weil er teuert ist und ihn fast niemand ihn einsetzt.

[Coda]

Botan ist auch ein Sonderfall. Das ist ja ein reiner Krypto-Benchmark, da kann der Intel-Compiler seine Stärken gar nicht ausspielen.

[(del)]

Botan ist auch ein Sonderfall. Das ist ja ein reiner Krypto-Benchmark, da kann der Intel-Compiler seine Stärken gar nicht ausspielen.Hä? Für was bräuchte man ICC sonstnoch, außer für so einen "number crunching"? Wie vorher jemand sagte, kann der ICC seine "Stärken" meist nur bei der SPEC ausspielen...

Pavlov (7-zip) hat ne Weile damit experimentiert und es schnell wieder sein gelassen. Die Unterschiede damals zum 2005er MSVC lagen (auf Intels) nah der Meßungenauigkeit der Meßwerkzeuge (interne Bench- und Zeitroutinen).

[Coda]

Hä? Für was bräuchte man ICC sonstnoch, außer für so einen "number crunching".
Crypto ist kein Number Crunching, sondern Bitgeshifte, XORs, Lookups und Umsortiererei.

[Nevermore4ever]

Da hier viele unterwegs sind, die die nötige Kompetenz besitzen könnten, mag ja vielleicht jemand die entsprechenden Wikipedia-Artikel ergänzen. Im englischen Artikel zu gcc steht beispielsweise im letzten Abschnitt noch ein unkommentierter Vorwurf über die Langsamkeit und Fehleranfälligkeit der gcc.

[(del)]

Stimmt auch wieder. Als Allgemeiner halte ich alles was mit einem größeren Datensatz meine CPU auf 100% bringt allgemein für number crunching... Ok. Egal.

@Nevermore4ever
Was Theo sagt kann auf vieles gemünzt sein. Oder allgemein :) sein eben. Gerade OpenBSD ist mehr als nur x86. GCC ist das XP. Das tut noch vor allem auf x86 sehr gut, wenn man es kennt, aber so langsam läßt sich da nicht mehr viel großartig anflicken. Es ist auch zu groß und zu alt, um jede Falte auszubügeln. LLVM kommt, auch wenn nicht von heute auf morgen.

[Ganon]

Ich kann hier auch nur vom "Hörensagen" sprechen, aber ein Bekannter von mir hat mal Handbrake (x264) mit dem ICC unter OS X kompiliert. Der Geschwindigkeitsanstieg war enorm, laut ihm.

Wie gesagt, gesehen habe ich es nicht, sondern er hatte es mir nur gesagt.

[Gast]

Habe mal vor einiger Zeit gesehen, dass es unter Linux auch einiges gibt, das _alternativ_ mit dem dem ICC kompiliert ist wie Postresql.

[Gast]

Habe mal vor einiger Zeit gesehen, dass es unter Linux auch einiges gibt, das _alternativ_ mit dem dem ICC kompiliert ist wie Postresql.Und sowas hat noch nie jemand außer Botans seinem Crypto vergliechen? =)

[Ganon]

Und sowas hat noch nie jemand außer Botans seinem Crypto vergliechen? =)

Wie z.B.:
http://multimedia.cx/eggs/intel-beats-up-gcc/
http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/
http://groups.google.com/group/linuxdna/browse_thread/thread/36a354f9351d2baf/9ec23ef7b8b12008?lnk=raot

Oder liegt's einfach nur daran, dass Botan eines der wenigen Beispiele ist, wo GCC mal punkten kann und deshalb andauernd hervorgekramt wird? ;)

Das Problem ist meinst einfach, dass der ICC den Code nicht kompiliert, oder falsch, was daran liegt, dass die meist halt nur mit GCC entwickelt/getestet werden. Es ist teils schon schwer genug mit llvm-gcc (LLVM mit GCC-Frontend) entsprechende Anwendungen/Bibliotheken zu kompilieren, da ist ein KOMPLETT anderer Compiler noch schwieriger.

[Gast]

Oder liegt's einfach nur daran, dass Botan eines der wenigen Beispiele ist, wo GCC mal punkten kann und deshalb andauernd hervorgekramt wird? ;)Neine es liegt nicht daran.

Hol nicht etwas aus der Urzeit, wo ICC das meiste auch noch mit SSE raushaut.

Schau dir wenigstens die Zahlen hinter den Diagrammen an.

[Ganon]

Hol nicht etwas aus der Urzeit, wo ICC das meiste auch noch mit SSE raushaut.

Urzeit? 2008/2009? Der verlinkte Botan Test ist nicht gerade jünger. Und was ist schlimm daran, dass der ICC viel mit SSE rausholen kann? Zumal z.B. im ersten Test gar keine CPU angegeben wurde ;)

Schau dir wenigstens die Zahlen hinter den Diagrammen an.

Ja, hab ich, und?

[Gast]

Ja, hab ich, und?2008 ist für dich was?

Bei alphagemini sind die Balken von ICC halb so lang. In Zahlen bedeutet das aber zb. 436s zu 430s. Solche Leute sind für mich nicht vertrauenswürdig, denn so dämlich wird ein Softwareentwickler nicht sein.

[Ganon]

2008 ist für dich was?

Und der Botan-Test ist von wann? Na? 2008 vllt.? ;)

Bei alphagemini sind die Balken von ICC halb so lang. In Zahlen bedeutet das aber zb. 436s zu 430s.

Und? ICC immer noch 6s schneller, oder habe ich irgendwo gesagt, dass der icc doppelt so schnell ist?

[Ganon]

Hier noch mal ein Vergleich von GCC und ICC unter Linux auf einem Core 2 2Ghz. Da in einer VM, steht nur ein Kern zur Verfügung.


gcc 4.4.3
Using 2.00 seconds min time per kenel.
Composite Score: 620.76
FFT Mflops: 523.80 (N=1024)
SOR Mflops: 598.43 (100 x 100)
MonteCarlo: Mflops: 113.74
Sparse matmult Mflops: 753.29 (N=1000, nz=5000)
LU Mflops: 1114.56 (M=100, N=100)

icc 11.1 20091130
Using 2.00 seconds min time per kenel.
Composite Score: 756.79
FFT Mflops: 498.35 (N=1024)
SOR Mflops: 738.30 (100 x 100)
MonteCarlo: Mflops: 248.55
Sparse matmult Mflops: 697.19 (N=1000, nz=5000)
LU Mflops: 1601.56 (M=100, N=100)

[Gast]

In other words, it's no coincidence that Apple is now instructing developers to switch to Clang-supported languages and their Clang-wrapping IDE (Xcode). There may not be an architecture switch coming soon, but Apple will have much more freedom in doing their own CPUs for iPad/iPhone, and more ammunition in negotations with Intel and other top-end chip companies.

http://www.brockerhoff.net/bb/viewtopic.php?p=2796#2796

[Gast]

Hier noch mal ein Vergleich von GCC und ICC unter Linux auf einem Core 2 2Ghz.Ist das dein eigener System? Könntest du den 4.5.0 so durchtesten?

[Rechner-Tester]

http://chaosradio.ccc.de/cre114.html

Rechner-Tester

[Gast]

Schön für die baldige Generationen an Programmierern oder Sachen wie Apples OpenGL-Stack. Falls man aber eine bestehende Entwicklungsumgebung längst hat und das auf GGC 4.5 upgraded, würde ich gerne erfahren welches x86 Projekt mit LLVM leistungsfähiger wird, wenn man es gegen "-O3 -funroll-loops -fpeel-loops -ffast-math -march=i686 -fexcess-precision=fast -flto -fwhole-program" fährt.

[Gast]

Das also zb. gegen DragonEgg und LLVM 2.7.

2.7 soll heute raus :D

[Ganon]

Wie gewünscht:

GCC 4.5.0 (Linux in einer VM, 64bit) Wie oben eben

Using 2.00 seconds min time per kenel.
Composite Score: 644.11
FFT Mflops: 543.38 (N=1024)
SOR Mflops: 600.30 (100 x 100)
MonteCarlo: Mflops: 261.89
Sparse matmult Mflops: 768.75 (N=1000, nz=5000)
LU Mflops: 1046.23 (M=100, N=100)

[(del)]

Das mit LU schonmal liegt daran, daß -O3 nicht ausreicht um hier auf ICC aufzuschliessen. Ich finde die Flags des Gastes garnicht so verkehrt. Was ICC wirklich alles macht weiß man doch garnicht.

Zum Standardset fehlt mir da noch -fomit-frame-pointer :smile:

[Ganon]

Hält dich keiner davon ab, selbst Ergebnisse zu posten ;)

Ich werd das hier jetzt nicht mit allen möglichen komischen Flags durchtesten, dafür ist mir die Zeit zu schade ^^ Und wenn man die optimalen Flags für die entsprechende CPU beim GCC gefunden hat, müsste sich dann auch noch jemand mit dem ICC auskennen, um die passenden Flags zu finden ;)

Aber die mathematische Genauigkeit runterzusetzen, nur um die Punkte in einem Benchmark zu erhöhen halte ich auch nicht für sinnvoll. Ist dann auch überhaupt nicht vergleichbar, da nicht das Gleiche berechnet wurde.

[(del)]

Ah ja. Natürlich danke für die Ergebnisse.

Viele Flags macht der ICC ohne Optionen schon von alleine. Ist auch nicht kompliziert, wenn man nur eine CPU-Familie bedient und den schnellsten Kode raushauen soll.

Du stellst das mit den Flags auch falsch dar. Es geht drum die Flags passend zum Source zu finden. Wenn man sie überhaupt sucht. Die meisten wollen, daß ihre Soft auf einem Phenom eine genausogute Figur macht wie auf einem Penryn.
Mehr macht eh kaum jemand, weil solche CPU-spezifischen Analysen Schweinezeit brauchen und wenige Prozente raushauen. Und man muß auch paar Systeme am Schreibtsich haben.
Was ich bisher aus der GCC-Ecke CPU-spezifisch kenne ist einfach nur dazugestelltes March.

Davon ab scheint mit das Flagset des Gastes "geklaut". Ich meine vor paar Wochen gesehen zu haben, daß genau das eins der Flagsets von den Leuten von Suse ist, wenn sie die GCCs durchtesten.
(bis auf -fexcess-precision, weil es das erst jetzt gibt und das Set war vom 4.4)

[...]
Aber 4.4 vs. ICC zu benchen ist gerecht? :D -fexcess-precision=fast ist doch das was 4.4.x und alle davor bisher rechneten :confused: Oder hab ich beim Lesen was vergeigt?

[Gast]

Bei Phoronix (http://www.phoronix.com/vr.php?view=14820) hat man vor kurzem mal wieder einige Balkendiagramme rausgehauen, die aus einem Vergleich von verschiedenen GCC-Versionen und LLVM (sowohl mit GCC-Frontend als auch mit Clang) entstanden sind. Die Aussagekraft der nur oberflächlich beschriebenen Ergebnisse sollte jeder für sich selbst bewerten.

[Ganon]

@BessereHälfte

Wie dem auch sei, der ICC interessiert mich auch weniger. Und um native Kompilierungen geht's mir zumindest in dem Thread auch nicht wirklich. ;)

LLVM-Trunk von heute

clang 1.5
Using 2.00 seconds min time per kenel.
Composite Score: 653.63
FFT Mflops: 477.32 (N=1024)
SOR Mflops: 691.88 (100 x 100)
MonteCarlo: Mflops: 235.53
Sparse matmult Mflops: 764.95 (N=1000, nz=5000)
LU Mflops: 1098.50 (M=100, N=100)

lli mit O3 Flag
Using 2.00 seconds min time per kenel.
Composite Score: 640.27
FFT Mflops: 479.64 (N=1024)
SOR Mflops: 688.60 (100 x 100)
MonteCarlo: Mflops: 172.94
Sparse matmult Mflops: 762.50 (N=1000, nz=5000)
LU Mflops: 1097.64 (M=100, N=100)

lli ohne Parameter
Using 2.00 seconds min time per kenel.
Composite Score: 629.99
FFT Mflops: 480.67 (N=1024)
SOR Mflops: 688.61 (100 x 100)
MonteCarlo: Mflops: 121.14
Sparse matmult Mflops: 761.84 (N=1000, nz=5000)
LU Mflops: 1097.70 (M=100, N=100)


Bis auf MonteCarlo erreicht der JiTC fast native Performance :)

[Coda]

Was auch nicht verwundert. Ich habe nochmal nachgeschaut und der JITC interpretiert tatsächlich nicht. Das was gebraucht wird wird sofort kompiliert.

[Ganon]

Ja. Aber es wird dann ja immer gerne behauptet, dass ein JiTC gar keine Zeit hätte gut zu optimieren und es deswegen "nicht hinnehmbar" langsam werden würde.

Vllt. sind hier die Time-Werte noch interessant:


time ./scimark_native
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 654.22
FFT Mflops: 478.84 (N=1024)
SOR Mflops: 692.20 (100 x 100)
MonteCarlo: Mflops: 236.99
Sparse matmult Mflops: 764.87 (N=1000, nz=5000)
LU Mflops: 1098.18 (M=100, N=100)

real 0m29.284s
user 0m29.195s
sys 0m0.020s

time lli scimark.bc
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 630.14
FFT Mflops: 480.69 (N=1024)
SOR Mflops: 688.18 (100 x 100)
MonteCarlo: Mflops: 121.13
Sparse matmult Mflops: 762.15 (N=1000, nz=5000)
LU Mflops: 1098.57 (M=100, N=100)

real 0m29.279s
user 0m29.243s
sys 0m0.023s

time lli -O3 scimark.bc
** **
** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark **
** for details. (Results can be submitted to pozo@nist.gov) **
** **
Using 2.00 seconds min time per kenel.
Composite Score: 640.13
FFT Mflops: 479.86 (N=1024)
SOR Mflops: 688.36 (100 x 100)
MonteCarlo: Mflops: 172.94
Sparse matmult Mflops: 762.05 (N=1000, nz=5000)
LU Mflops: 1097.44 (M=100, N=100)

real 0m31.070s
user 0m31.033s
sys 0m0.021s


d.h. bei -O3 beim JiTC läuft das Programm wirklich 1-2s länger. Bei normalem JiTC kein Unterschied. Vllt. bräuchte man hierfür aber ein anderes Programm.

[(del)]

Bei Phoronix (http://www.phoronix.com/vr.php?view=14820) hat manSEHR schönes Ergebnis beim Apache. (nur unter OSX-Server?)

Rein aus der Sicht der Leistung die man an den Benutzer übergibt ist LLVM erstmal kein Thema. Mehr hat mich diesbezüglich vorerst auch nicht interessiert. Es stehen bereits einige Märchen dazu im Netz :)

[Ganon]

Interessantes Ergebnis von LLVM 2.7 unter FreeBSD8 auf einem Athlon II X2:


gcc 4.2.1
Composite Score: 831.71
FFT Mflops: 744.21 (N=1024)
SOR Mflops: 652.51 (100 x 100)
MonteCarlo: Mflops: 348.83
Sparse matmult Mflops: 1118.48 (N=1000, nz=5000)
LU Mflops: 1294.54 (M=100, N=100)

clang
Composite Score: 832.03
FFT Mflops: 756.82 (N=1024)
SOR Mflops: 806.05 (100 x 100)
MonteCarlo: Mflops: 294.93
Sparse matmult Mflops: 1058.50 (N=1000, nz=5000)
LU Mflops: 1243.86 (M=100, N=100)

lli
Composite Score: 865.14
FFT Mflops: 749.20 (N=1024)
SOR Mflops: 806.05 (100 x 100)
MonteCarlo: Mflops: 261.29
Sparse matmult Mflops: 1149.12 (N=1000, nz=5000)
LU Mflops: 1360.02 (M=100, N=100)


Stellenweise schnellster Code mit dem JiT-C :)

[Coda]

Ja. Aber es wird dann ja immer gerne behauptet, dass ein JiTC gar keine Zeit hätte gut zu optimieren
Das meiste an Optimierungen wird schon im Offline-Step an der SSA-Form gemacht.

Der JITC muss nur noch Register Allocation und Code Generation machen im wesentlichen. Das geht wohl vertretbar schnell.