Archiv verlassen und diese Seite im Standarddesign anzeigen : Was bringt Gentoo bei absolut neuen CPUs?
Jenes Potential von Haswell dürfte sich zudem üblicherweise erst langfristig entwickeln – sprich, den Performance-Gewinn von AVX2 und FMA3 unter Haswell wird man wohl erst dann sehen können, wenn der performancebewusste Anwender längst mit dem Gedanken an eine Neuanschaffung spielt (oder diese schon hinter sich gebracht hat).
http://www.3dcenter.org/news/erste-umfangreiche-haswell-benchmarks-zeigen-ca-5-mehr-pro-mhz-leistung
Und was ist mit Gentoo?
Der gcc wird recht schnell auf AVX2 und FMA3 optimiert sein.
Im Prinzip wird daran ja schon lange entwickelt.
Ganon
2013-04-23, 16:07:25
Da du in normalen Anwendungen selten Sachen hast die wirklich von AVX2 und FMA3 profitieren, wirst du auch bei Gentoo keine Wunder erleben.
Und bis handoptimierter Assembler in die kritischen Bibliotheken (libc, ffmpeg, und Co.) wandert, vergeht eben auch noch etwas Zeit. Und einige davon bringen dir auch nichts, da das hoffentlich schon deine GPU macht (im Fall von ffmpeg bei der Dekodierung).
Und generell ist der Performance-Gewinn von Gentoo eher fragwürdig.
Milchkanne
2013-04-23, 16:39:06
Ich würde sagen, Gentoo bringt dir vielleicht 2-8 Monate, bei Debian natürlich mehr. Allerdings nicht ab heute, sondern ab dem Tag an dem deine Software von sich aus nutzen aus AVX2 usw. zieht. Unterstützung im Compiler heißt nicht, dass automatisch compilierter Code deutlich schneller läuft. Viele Anwendungen können damit ohnehin nicht viel anfangen, die die es können brauchen Handarbeit.
Allgemein bringt Gentoo aktuelle Pakete und evtl. ein schlankeres System das bestenfalls minimal schneller ist (als vergleichbar schlanke Systeme). Und es verheizt natürlich mehr Energie zum aktualisieren der Pakete.
lumines
2013-04-23, 16:53:03
Und es verheizt natürlich mehr Energie zum aktualisieren der Pakete.
Wenn man nicht gerade distcc benutzt, würde ich das sogar als größten Nachteil sehen. Während man kompiliert, hat man schließlich weniger Ressourcen für andere Aufgaben zur Verfügung.
Ganon
2013-04-23, 16:59:07
Und das was man an schlankeren Paketen spart, zieht man sich mit reinen build-Abhängigkeiten wieder rein.
Der Vorteil von Gentoo liegt auch eher darin, dass man sich viel einfacher Updates basteln kann, und man nicht alle Features mitkompilieren muss, die man nicht benötigt. So braucht dann ein Programm eventuell weniger Arbeitsspeicher (obwohl durch die Build-Abhängigkeiten natürlich Festplattenspeicher verloren geht). Entwickler müssen sich aber dadurch nicht immer alle dev-Packages extra zusammenkratzen, weil sie schon installiert sind.
Wenn man nicht gerade distcc benutzt, würde ich das sogar als größten Nachteil sehen. Während man kompiliert, hat man schließlich weniger Ressourcen für andere Aufgaben zur Verfügung.
Das kann man aber durch entsprechende CPU Priorität egalisieren (Arbeitsspeicher natürlich nicht) und stört meist nicht.
Ich würde sagen, Gentoo bringt dir vielleicht 2-8 Monate, bei Debian natürlich mehr.
Debian wird aber nicht seziell auf AVX2 fähige CPUs optimiert, sondern nur auf den Gemeinsamen Nenner, also Pentium irgendwas.
D.h. Debian wird auch viele Jahre nach dem Release von AVX2 CPUs diesbezüglich nichts bringen, weil kein einziges Paket mit AVX2 Support compiliert sein wird.
Unterstützung im Compiler heißt nicht, dass automatisch compilierter Code deutlich schneller läuft. Viele Anwendungen können damit ohnehin nicht viel anfangen, die die es können brauchen Handarbeit.
Wenn dem so wäre, dann wäre es sinnlos Compiler SSE + AVX2 usw. beizubringen.
Wenn der Algorithmus dafür geeignet ist, sich auf AVX2 abbilden zu lassen und der Compiler etwas taugt, dann wird das also immer etwas bringen.
Zwar vielleicht nicht so viel wie bei Handarbeit, aber doch genug.
Allgemein bringt Gentoo aktuelle Pakete und evtl. ein schlankeres System das bestenfalls minimal schneller ist (als vergleichbar schlanke Systeme).
Was bei rechenintensiven libs ja schonmal hilfreich ist, wenn dann alles 5 % schneller fertig ist.
Alt, aber immer noch wahr: http://funroll-loops.info/
Ganon
2013-04-23, 23:07:08
Wenn dem so wäre, dann wäre es sinnlos Compiler SSE + AVX2 usw. beizubringen.
Wenn der Compiler kein SSE, AVX und Co. könnte, könnte er auch mit den Intrinsics nichts anfangen. Da er das aber soll/will, muss er das auch können.
Wenn der Algorithmus dafür geeignet ist, sich auf AVX2 abbilden zu lassen und der Compiler etwas taugt, dann wird das also immer etwas bringen.
Zwar vielleicht nicht so viel wie bei Handarbeit, aber doch genug.
Der Compiler kann aber auch nicht zaubern. Nur weil hier und da mal ein paar Instruktionen über AVX2 laufen, heißt das nicht, dass dann der Performance-Boost kommt. Bei "Auto-SSE" damals war es teilweise sogar so, dass es langsamer wurde, weil ständig die Daten zwischen FPU und SSE Einheit gewandert sind.
Bei ein paar (konstruierten) Benchmarks ist es vllt. spürbar, aber bei den gängigen Wald und Wiesen Anwendungen wirst du selten irgendwas von AVX spüren.
Als Beispiel auch gerne mal die Altivec-Einheit bei den PowerPCs in den Apple-Computern damals. Die konnten auch Dinge, die Intel jetzt erst mit AVX eingeführt hat, trotzdem hat das nicht geholfen, weil kaum Anwendungen einen Nutzen daraus ziehen.
Alt, aber immer noch wahr: http://funroll-loops.info/
Schön, Debian bietet ja auch die Möglichkeit Pakete nochmal von den Source Code Paketen aus zu compilieren.
Frage:
Bietet Debian hierfür auch die Möglichkeit Optimizer Flags usw. anzugeben?
Wenn man einzelne Pakete gezielt optimieren kann, vor allem die, die performancekritisch sind, dann dürfte das für mich reichen.
Wenn der Compiler kein SSE, AVX und Co. könnte, könnte er auch mit den Intrinsics nichts anfangen. Da er das aber soll/will, muss er das auch können.
Wenn du handoptimierst, dann geht auch inline assembler und der Compiler darf dumm bleiben.
Fakt ist nunmal, dass Compiler auf diese Funktionen optimiert werden und sie dann auch nutzen, während der Quellcode der zu compilierenden Programme normales C, C++ etc. bleibt.
Der Compiler kann aber auch nicht zaubern.
habe ich auch nicht behauptet.
Nur weil hier und da mal ein paar Instruktionen über AVX2 laufen, heißt das nicht, dass dann der Performance-Boost kommt. Bei "Auto-SSE" damals war es teilweise sogar so, dass es langsamer wurde, weil ständig die Daten zwischen FPU und SSE Einheit gewandert sind.
"Damals", wie ich schon sagte, der Compiler muss natürlich gut sein.
Wenn der Compiler das nicht gut umsetzen kann, dann taugt der Compiler nichts und nicht das Prinzip "lass den Compiler optimieren."
Bei ein paar (konstruierten) Benchmarks ist es vllt. spürbar, aber bei den gängigen Wald und Wiesen Anwendungen wirst du selten irgendwas von AVX spüren.
Videocodecs, Packer, sonstige Number Cruncher.
Dafür brauche ich das.
Für nen Texteditor der sowieso nur 99,9 % idled würde ich die Features wohl kaum brauchen.
Als Beispiel auch gerne mal die Altivec-Einheit bei den PowerPCs in den Apple-Computern damals. Die konnten auch Dinge, die Intel jetzt erst mit AVX eingeführt hat, trotzdem hat das nicht geholfen, weil kaum Anwendungen einen Nutzen daraus ziehen.
Der PowerPC war so gering verbreitet, dass es auch kaum genug Leute gab, die den GCC darauf optimiert haben.
Es steht und fällt nunmal mit der Qualität des COmpilers.
Ganon
2013-04-24, 07:57:17
Teste es einfach mal (mit und ohne entsprechende Compiler-Optimierungen). Du wirst erstaunt sein, wie wenig es bringt, oder kontraproduktiv ist.
Wenn du handoptimierst, dann geht auch inline assembler und der Compiler darf dumm bleiben.
Intrinsics sind aber kein Assembler.
Teste es einfach mal (mit und ohne entsprechende Compiler-Optimierungen). Du wirst erstaunt sein, wie wenig es bringt.
Du meinst... so ganz allgemein? :|
http://gentooexperimental.org/~patrick/weblog/archives/2012-11.html#e2012-11-14T04_14_44.txt
Videocodecs, Packer, sonstige Number Cruncher.
Dafür brauche ich das.
Und wenn du die nicht per Hand auf AVX2 optimierst wird dir das einfache neucompilieren gar nichts bringen...alleine schon deshalb weil diese Programme meist von Hand auf AVX1 oder drunter (irgendein SSE) optimiert sind und der Compiler sich da hüten wird eigenständige optimierungen nochmal unterzubringen.
Dieses ganze Auto-AVX, -AVX2 oder -SSE Zeug bringt in 50% der Fälle gar nichts, in 49% der Fälle wird das Programm durch diese "optimierung" langsamer und in 1% der Fälle hast du den "gewaltigen" Geschwindigkeitsboost von 1-2%.
Ganon
2013-04-24, 08:40:49
http://gentooexperimental.org/~patrick/weblog/archives/2012-11.html#e2012-11-14T04_14_44.txt
Was hat Speicherverbrauch und IO Performance (ext3 -> ext4, Kernel 2.6 -> 3.2) zwischen einem Gentoo und CentOS5 jetzt mit Compileroptimierungen zu tun?
Was hat Speicherverbrauch und IO Performance (ext3 -> ext4, Kernel 2.6 -> 3.2) zwischen einem Gentoo und CentOS5 jetzt mit Compileroptimierungen zu tun?
Was war nochmal der Unterschied zwischen CentOS und Gentoo? Ähm.. ah ja: andere Compileroptimierungen!
(1/3 weniger Speicherverbrauch bei der gleichen Software fällt wohl deiner Meinung nach einfach so vom Himmel? :| )
Und das
Default-y Gentoo: ~1200 qps peak, ~45-50 seconds walltime to render the same page
Gentoo with -march=native in CFLAGS: ~1800qps peak, ~30 seconds render time (this one was unexpected for me!)
hast du gelesen, ja?
Was ich damit sagen will: Wenn man einzelne Anwendungen isoliert betrachtet sind die Perfomranceunterschiede (bis auf wenige schon erwähnte Ausnahmen) vielleicht im kleinen einstelligen Prozentbereich, aber das bedeutet nicht dass das Gesamtsystem davon nicht deutlich profitieren könnte. Eine isolierte Betrachtung greift eben zu kurz.
Ganon
2013-04-24, 08:57:50
Um mal von meiner Seite aus theoretische (!) Benchmarks anzubringen:
http://math.nist.gov/scimark2/
GCC 4.8, ArchLinux, Intel(R) Core(TM)2 Duo CPU T7300@2.00GHz
Sicherlich eine alte CPU, aber ich kann heute Abend das Ganze auch gerne auch mal auf meinem i7 zu Hause machen.
Durchlauf kleine Größe:
gcc -O2 -lm *.c -o scimark2_n
Composite Score: 656.48
FFT Mflops: 504.12 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 259.36
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1087.92 (M=100, N=100)
gcc -O2 -march=native -lm *.c -o scimark2_o
Composite Score: 658.94
FFT Mflops: 510.01 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 265.78
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1087.92 (M=100, N=100)
gcc -O2 -march=native -ftree-vectorize -lm *.c -o scimark2_v
Composite Score: 688.31
FFT Mflops: 516.05 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 264.47
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1230.03 (M=100, N=100)
Wie wir hier sehen, bringt -march=native so gut wie nix. Die Auto-Vektorisierung bringt nur im LU Teil eine Mehrperformance.
Nun schauen wir uns den Druchlauf mit großen Matritzen an
_n
Composite Score: 424.04
FFT Mflops: 82.91 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 258.11
Sparse matmult Mflops: 480.75 (N=100000, nz=1000000)
LU Mflops: 711.11 (M=1000, N=1000)
_o
Composite Score: 422.53
FFT Mflops: 77.79 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 263.17
Sparse matmult Mflops: 480.75 (N=100000, nz=1000000)
LU Mflops: 703.61 (M=1000, N=1000)
_v
Composite Score: 423.93
FFT Mflops: 77.50 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 264.47
Sparse matmult Mflops: 483.02 (N=100000, nz=1000000)
LU Mflops: 707.34 (M=1000, N=1000)
Lustigerweise ist die unoptimierte Variante hier die _schnellste_ von allen. Und nein, ich werde das nicht mit -O3 machen, da dieser Flag instabilen und ggf. fehlerhaft rechnenden Code erzeugen kann.
Und das ist ein ziemlich theoretischer Benchmark. In realen Anwendungsbenchmarks werden die Unterschiede eher kleiner sein.
Ganon
2013-04-24, 08:59:54
Was war nochmal der Unterschied zwischen CentOS und Gentoo?
Völlig anderer Versionsstand der Software?
Völlig anderer Versionsstand der Software?
Ach so, hab ich vergessen: Neue Versionen sind ja üblicherweise immer schlanker und schneller... :rolleyes:
Es steht ja explizit da dass der Perfomranceunterschied in der neuen Kernelversion und dem Wechsel ext3->ext4 begründet sein könnte. Aber den Unterschied nur darauf zu schieben ist genauso falsch wie zu behaupten er käme nur von den Compileroptimierungen. Wie gesagt, das Gesamtsystem machts, ein einzelner isolierter Anwendungstest wie du ihn oben gemacht hast (schöner Test übrigens!) kann die Komplexität eines Gesamtsystems einfach nicht erfassen, das greift zu kurz.
Ganon
2013-04-24, 09:22:10
Ach so, hab ich vergessen: Neue Versionen sind ja üblicherweise immer schlanker und schneller... :rolleyes:
Öh, Kernel 3.x und Ext4 _SIND_ schneller?
Es steht ja explizit da dass der Performanceunterschied in der neuen Kernelversion und dem Wechsel ext3->ext4 begründet sein könnte. Aber den Unterschied nur darauf zu schieben ist genauso falsch wie zu behaupten er käme nur von den Compileroptimierungen.
Sry, aber die Aussagen auf der Webseite sind total irrelevant. Liegt u.a. auch daran weil er den Buffer/Cache als Maßstab für den Speicherverbauch nimmt.
Wie gesagt, das Gesamtsystem machts, ein einzelner isolierter Anwendungstest wie du ihn oben gemacht hast (schöner Test übrigens!) kann die Komplexität eines Gesamtsystems einfach nicht erfassen, das greift zu kurz.
Ja und wer sagt, dass das Gesamtsystem im Großen und Ganzen nicht langsamer geworden ist? Abgesehen von dem einen (nicht mit Messmethoden erläuterten) Test? ;)
Teste es einfach mal (mit und ohne entsprechende Compiler-Optimierungen). Du wirst erstaunt sein, wie wenig es bringt, oder kontraproduktiv ist.
Mal schauen, wenn ich Zeit habe.
Intrinsics sind aber kein Assembler.
Ich weiß, aber das liest sich so, als hättest du keine Zugriff auf SSE, MMX & Co.
Wenn der Compiler kein SSE, AVX und Co. könnte, könnte er auch mit den Intrinsics nichts anfangen. Da er das aber soll/will, muss er das auch können.
Du meinst... so ganz allgemein? :|
http://gentooexperimental.org/~patrick/weblog/archives/2012-11.html#e2012-11-14T04_14_44.txt
Der Vergleich ist Müll, wenn die Kernelversionen und Dateisysteme völlig verschieden sind.
Schon eine Änderung der Algorithmen im Scheduler können hier Welten bewegen.
Wenn man wissen will, ob der Compiler etwas aus bestehendem Code besser macht, wenn man Optimierungsflags verwendet, dann muss der Code absolut identisch sein.
Und bitte lege dir nächstes mal einen anderen Nick zu.
Und wenn du die nicht per Hand auf AVX2 optimierst wird dir das einfache neucompilieren gar nichts bringen...alleine schon deshalb weil diese Programme meist von Hand auf AVX1 oder drunter (irgendein SSE) optimiert sind und der Compiler sich da hüten wird eigenständige optimierungen nochmal unterzubringen.
Gut, das ist ein Argument.
Allerdings ist stark davon auszugehen, dass der Code Architekturneutrale Anweisungen enthält und man die x86 spezifischen Handoptimierungen mit einer Änderung bei den Define Anweisungen ausklammern kann.
Damit muss man zwar vielleicht in den Quellcode rein und was editieren, aber das ist dann oft nur eine Zeile.
Bei gutem Code hat dafür aber schon eine Möglichkeit via gmake & Co geschaffen, insofern wird das auch wieder gut von automatisch compilierenden Compilern nutzbar.
Ob's via AVX2 dann tatsächlich schneller ist, als eine Handoptimierte SSE Anweisung, kommt dann auf den Einsatzzweck an.
Oft ist es ja auch so, dass diese Handoptimierungen gar nicht so weit sind.
Also z.B. noch SSE2 verwendet wird, während man schon lange bei SSE4 und AVX1 ist.
Dann noch etwas.
Dank AMD64 haben 64 Bit Linuxdistributionen für die x86 CPUs ja inzwischen eine aktualisierte Basis, aber zu 32 Bit Zeiten war der kleinste gemeinsamme Nenner gerademal der Pentium oder noch schlimmer, der i386.
Da war dann gar kein Code automatisch auf SSE & Co optimiert, da mußte wirklich alles von Hand optimiert worden sein und dafür brauchte es dann wieder Routinen im Programmcode, die automatisch den richtigen Zweig je nach vorhandenem Prozessor auswählen.
Dieses ganze Auto-AVX, -AVX2 oder -SSE Zeug bringt in 50% der Fälle gar nichts, in 49% der Fälle wird das Programm durch diese "optimierung" langsamer und in 1% der Fälle hast du den "gewaltigen" Geschwindigkeitsboost von 1-2%.
Gilt das auch für den Intel Compiler?
Um mal von meiner Seite aus theoretische (!) Benchmarks anzubringen:
http://math.nist.gov/scimark2/
GCC 4.8, ArchLinux, Intel(R) Core(TM)2 Duo CPU T7300@2.00GHz
Sicherlich eine alte CPU, aber ich kann heute Abend das Ganze auch gerne auch mal auf meinem i7 zu Hause machen.
Durchlauf kleine Größe:
gcc -O2 -lm *.c -o scimark2_n
Composite Score: 656.48
FFT Mflops: 504.12 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 259.36
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1087.92 (M=100, N=100)
gcc -O2 -march=native -lm *.c -o scimark2_o
Composite Score: 658.94
FFT Mflops: 510.01 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 265.78
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1087.92 (M=100, N=100)
gcc -O2 -march=native -ftree-vectorize -lm *.c -o scimark2_v
Composite Score: 688.31
FFT Mflops: 516.05 (N=1024)
SOR Mflops: 604.06 (100 x 100)
MonteCarlo: Mflops: 264.47
Sparse matmult Mflops: 826.95 (N=1000, nz=5000)
LU Mflops: 1230.03 (M=100, N=100)
Wie wir hier sehen, bringt -march=native so gut wie nix. Die Auto-Vektorisierung bringt nur im LU Teil eine Mehrperformance.
Nun schauen wir uns den Druchlauf mit großen Matritzen an
_n
Composite Score: 424.04
FFT Mflops: 82.91 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 258.11
Sparse matmult Mflops: 480.75 (N=100000, nz=1000000)
LU Mflops: 711.11 (M=1000, N=1000)
_o
Composite Score: 422.53
FFT Mflops: 77.79 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 263.17
Sparse matmult Mflops: 480.75 (N=100000, nz=1000000)
LU Mflops: 703.61 (M=1000, N=1000)
_v
Composite Score: 423.93
FFT Mflops: 77.50 (N=1048576)
SOR Mflops: 587.33 (1000 x 1000)
MonteCarlo: Mflops: 264.47
Sparse matmult Mflops: 483.02 (N=100000, nz=1000000)
LU Mflops: 707.34 (M=1000, N=1000)
Lustigerweise ist die unoptimierte Variante hier die _schnellste_ von allen. Und nein, ich werde das nicht mit -O3 machen, da dieser Flag instabilen und ggf. fehlerhaft rechnenden Code erzeugen kann.
Und das ist ein ziemlich theoretischer Benchmark. In realen Anwendungsbenchmarks werden die Unterschiede eher kleiner sein.
LOL, du bist mir ja ein Spaßvogel.
Du weißt aber schon, dass die ganzen Spezialeinheiten (SSE, AVX usw) für klassische 4x4 Matrizen gedacht sind und das auch am besten können.
Wenn du nun auf i*k Matrizen ausweichst, dann wird es auch der Compiler schwer haben, daraus noch ordentlichen Code für die Spezialeinheiten zu bauen.
Und am LU Ergebnis sieht man das deutlich.
Mit den kleinen 4x4 Matrizen kann er perfekt optimieren, es bringt einen riesen Geschwindigkeitsvorteil, während es bei i*k Matrizen zu einem Nachteil führt, weil die Spezialeinheiten nicht mehr als 4 Werte pro zu berechnendes Element für eine SiMD Anweisung aufnehmen.
Das hier die klassischen CPU Routinen flexibler sind, das dürfte hier einem sofort auffallen.
Glücklicherweise wird aber die ganze Computergrafik in 4x4 Matrizen berechnet und bei MPEG-2 und MPEG-4 sieht das auch nicht anders aus, denn auch bei diesen hat man darauf geachtet, welche Hardware überhaupt realisierbar ist und womit man dann beschleunigen könnte.
Recheneinheiten die in einem Zug i*k Matrizen berechnen baut man nicht, man baut sie für 4*4 Matrizen weil die fast überall benötigt werden.
Und wenn das nicht in ne 4x4 Rechnung reinpaßt, dann muss man zerlegen und sonst wie schauen, dass das zusammenpaßt.
Daraus folgt aber auch, dass eine SSE Einheit bei Matrizen i*k, wobei i und k > 4, nicht so gut optimieren kann.
Bsp. wäre da die Vertauschung von Spalten und Zeilen.
Das kann die SSE Einheit dann nicht mehr, weil bei 4 Schluss ist und das Teil in 4*4 Rechnungen zerlegt wird, während die klassische All Purpose Recheneinheit bei einer z.B: 256x256 Matriz einfach alle 256 Werte miteinander vertauschen könnte und dann natürlich wesentlich schneller mit der Berechnung fertig ist.
Daraus folgt aber auch, dass eine SSE Einheit bei Matrizen i*k, wobei i und k > 4, nicht so gut optimieren kann.
Bsp. wäre da die Vertauschung von Spalten und Zeilen.
Das kann die SSE Einheit dann nicht mehr, weil bei 4 Schluss ist und das Teil in 4*4 Rechnungen zerlegt wird, während die klassische All Purpose Recheneinheit bei einer z.B: 256x256 Matriz einfach alle 256 Werte miteinander vertauschen könnte und dann natürlich wesentlich schneller mit der Berechnung fertig ist.
Nachtrag:
Und daraus folgt natürlich, dass Handoptimieren heißt, dass man die Dateneingabe in die Spezialeinheiten passend zurecht legt, so dass diese eben besonders effizient arbeiten können.
Teste es einfach mal (mit und ohne entsprechende Compiler-Optimierungen). Du wirst erstaunt sein, wie wenig es bringt, oder kontraproduktiv ist.
Ein richtiger Test muss natürlich das komplette System mit anderen Flags kompilieren, nicht nur eine isolierte Anwendung. Das hast du also gemacht, ja?
Öh, Kernel 3.x und Ext4 _SIND_ schneller?
Ich hatte das als Antwort auf
Völlig anderer Versionsstand der Software? geschrieben und auf die Userspace Software bezogen. Das Kernel und Dateisystem da mitspielen ist natürlich klar und habe ich auch nicht abgestritten. Nochmal zum mitmeißeln, bei dem Fileserver Test steht explizit dabei "The IO difference could be attributed to the ext3 -> ext4 upgrade and the kernel 2.6.18 -> 3.2.1 upgrade"
Wobei ich jetzt auf die schnelle keine Evidenz gefunden habe dass neuere Kernel soviel schneller sind...
Sry, aber die Aussagen auf der Webseite sind total irrelevant. Liegt u.a. auch daran weil er den Buffer/Cache als Maßstab für den Speicherverbauch nimmt.
Wie würdest du denn den Speicherverbrauch messen?
Ja und wer sagt, dass das Gesamtsystem im Großen und Ganzen nicht langsamer geworden ist? Abgesehen von dem einen (nicht mit Messmethoden erläuterten) Test?
Ich würde dir empfehlen die verlinkte Seite nochmal zu lesen. Ich fass es dir gern zusammen:
3 unterschiedliche Tests.
1.) Fileserver: 1/3 Speicherverbrauch, doppelte IO Performance ( letztere vermutlich zu einem Teil dem Kernel und Dateisystem Upgrade geschuldet)
2.) mediawiki (php+mysql), CPU bound, Daten passen komplett in den RAM:
Original CentOS install: ~900 qps peak in mysql, ~60 seconds walltime to render a pathological page
Default-y Gentoo: ~1200 qps peak, ~45-50 seconds walltime to render the same page
Gentoo with -march=native in CFLAGS: ~1800qps peak, ~30 seconds render time (this one was unexpected for me!)
3.) komplett IO limitiert "move data test": 4 x throughput. (Ob alleine ext4 dafür verantwortlich ist wage ich zu bezweifeln...)
Gerade das mediawiki Beispiel ist weit davon entfernt eine einzelne isolierte Anwendung zu testen, da spielt alles hinein. Das "Gesamtsystem" ist schneller.
Wenn man wissen will, ob der Compiler etwas aus bestehendem Code besser macht, wenn man Optimierungsflags verwendet, dann muss der Code absolut identisch sein.
Default-y Gentoo: ~1200 qps peak, ~45-50 seconds walltime to render the same page
Gentoo with -march=native in CFLAGS: ~1800qps peak, ~30 seconds render time
"Absolut identischer" Code & Hardware, nur CFLAGS anders. Und nu?
Ich glaube durchaus dass man in einer isolierten Anwendung vielleicht nur 1% gewinnt, aber es gibt nunmal keine Anwendung die nur für sich isoliert exisitiert. Es kommt immer auf die komplette Softwareumgebung an, und wenn man da an 10 Stellen 1% gewinnt sinds halt insgesamt schonmal 10%.
Und nein, ich werde das nicht mit -O3 machen, da dieser Flag instabilen und ggf. fehlerhaft rechnenden Code erzeugen kann.
Diese Flag. Und nein, GCC erzeugt keinen "fehlerhaft rechnenden Code", das Programm ist höchstens falsch weil es undefinierte Konstrukte verwendet.
Ganon
2013-04-24, 15:14:35
Ein richtiger Test muss natürlich das komplette System mit anderen Flags kompilieren, nicht nur eine isolierte Anwendung. Das hast du also gemacht, ja?
Das Programm nutzt nur die glibc und die optimiert zu kompilieren bei sqrt und sin ist reichlich sinnlos.
Wie würdest du denn den Speicherverbrauch messen?
In tatsächlich belegten Speicher und nicht wie viel Buffer sich das Dateisystem im RAM abgelegt hat. Die Angabe ist nicht umsonst getrennt.
Ich würde dir empfehlen die verlinkte Seite nochmal zu lesen. Ich fass es dir gern zusammen:
...
"Absolut identischer" Code & Hardware, nur CFLAGS anders. Und nu?
Da nicht gesagt wurde, wie getestet wurde, ist das hinfällig. Der beobachtete Performance-Anstieg könnte auch andere Ursachen gehabt haben. Da aber nicht gezeigt wurde, wie getestet wurde, kann man schlecht sagen was da nun passiert ist. march=native sorgt selten für Performance-Wunder. Warum sollte hier plötzlich sich die IO-Performance verbessern? Zumal IO-Performance eher Plattenlimitiert ist und dank DMA auch an der CPU vorbeigeht.
Diese Flag. Und nein, GCC erzeugt keinen "fehlerhaft rechnenden Code", das Programm ist höchstens falsch weil es undefinierte Konstrukte verwendet.
Habe ja auch nicht geschrieben dass GCC falschen Code erzeugt, sondern das etwas falsches bei rauskommen kann. Woher das nun kommt ist etwas anderes. O3 triggert auch gerne mal Bugs im GCC.
Und am LU Ergebnis sieht man das deutlich.
Mit den kleinen 4x4 Matrizen kann er perfekt optimieren, es bringt einen riesen Geschwindigkeitsvorteil, während es bei i*k Matrizen zu einem Nachteil führt, weil die Spezialeinheiten nicht mehr als 4 Werte pro zu berechnendes Element für eine SiMD Anweisung aufnehmen.
Problem ist nur, dass die Anwendung für den Large-Test nicht nochmal neu kompiliert wurde, sondern nur den -large Parameter bekommen hat.
Glücklicherweise wird aber die ganze Computergrafik in 4x4 Matrizen berechnet und bei MPEG-2 und MPEG-4 sieht das auch nicht anders aus, denn auch bei diesen hat man darauf geachtet, welche Hardware überhaupt realisierbar ist und womit man dann beschleunigen könnte.
Nur das hier im Idealfall die GPU greifen sollte mit Spezialhardware. Von daher ist es unnötig hier extra das System zu "Spezialkompilieren".
Habe ja auch nicht geschrieben dass GCC falschen Code erzeugt, sondern das etwas falsches bei rauskommen kann. Woher das nun kommt ist etwas anderes. O3 triggert auch gerne mal Bugs im GCC.
Nö. Die Leute behaupten es seien Bugs, zu 99,99% ist es aber einfach ihr kaputtes Programm.
Es gibt unendlich viel Schrottcode.
Nur das hier im Idealfall die GPU greifen sollte mit Spezialhardware. Von daher ist es unnötig hier extra das System zu "Spezialkompilieren".
Beim Raytracing setzt man besser auf die CPU, denn Raytracer lassen sich nicht besonders gut parallelisieren und dann ist aber trotzdem gut, wenn die CPU 4x4 Matrizen schnell berechnen kann.
Das Programm nutzt nur die glibc und die optimiert zu kompilieren bei sqrt und sin ist reichlich sinnlos.
Und du meinst, eine Anwendung welche nur die glibc nutzt ist in irgendeiner Weise repräsentativ für die Gesamtperformance eines Systems? Sehr putzig :|
Außerdem, hast du es mal ausprobiert? Wenn du es wirklich gemacht hättest dann könntest du was dazu sagen, so bleibt das alles Spekulation deinerseits.
Ich habe den Link gepostet eben weil es dort einfach mal ausprobiert wurde anstatt sich die ganze Zeit nur theoretisch darüber zu unterhalten.
In tatsächlich belegten Speicher und nicht wie viel Buffer sich das Dateisystem im RAM abgelegt hat. Die Angabe ist nicht umsonst getrennt.
man free
Da nicht gesagt wurde, wie getestet wurde, ist das hinfällig. Der beobachtete Performance-Anstieg könnte auch andere Ursachen gehabt haben. Da aber nicht gezeigt wurde, wie getestet wurde, kann man schlecht sagen was da nun passiert ist. march=native sorgt selten für Performance-Wunder. Warum sollte hier plötzlich sich die IO-Performance verbessern? Zumal IO-Performance eher Plattenlimitiert ist und dank DMA auch an der CPU vorbeigeht.
Auch wenn du dich weiterhin drauf festbeißt geh nicht mehr auf den IO Quatsch ein, das hab ich schon zur Genüge in den letzten Posts getan.
march=native wird nur im Zusammenhang mit dem mediawiki test erwähnt, bei diesem spielt IO keine Rolle (lies doch mal nach). Wieso du das jetzt mit IO in Zusammenhang bringst ist mir schleierhaft.
Ganon
2013-04-24, 16:58:53
Außerdem, hast du es mal ausprobiert? Wenn du es wirklich gemacht hättest dann könntest du was dazu sagen, so bleibt das alles Spekulation deinerseits.
Ich habe mehrere Jahre Gentoo genutzt, bis ich mich mal mit dem ganzen Compiler-Kram wirklich beschäftigt habe, um dann festzustellen, dass ich mit dem ganzen Kram maximal meinen Stromzähler beschleunige.
Siehe auch: http://www.linux-mag.com/id/7574/ (etwas älter und nicht ganz passend zum Thema)
Und gerade Projekte wie ffmpeg haben schon lange CPU-Erkennung zur Laufzeit und verwenden eh Handoptimierung, wenn es nicht eh schon über die GPU läuft.
Aber ich denke mit Gentoo-Nutzern über die Sinnhaftigkeit von CFLAGS zu diskutieren ist genauso sinnvoll wie mit Audiophilen über Luftreiniger zu reden...
Ich habe mehrere Jahre Gentoo genutzt, bis ich mich mal mit dem ganzen Compiler-Kram wirklich beschäftigt habe, um dann festzustellen, dass ich mit dem ganzen Kram maximal meinen Stromzähler beschleunige.
Na das Argument musste ja kommen. Eine durchschnittliche i7 CPU (37xx, 2xxx) hat eine TDP von unter 100W, eine durchschnittliche Graka mal locker das doppelte. Wenn du jetzt sagen wir mal einmal in der Woche dein Gentoo updatest (in einer Woche gibt es nicht sehr viele neue Pakete), dann ist das in max. 2h erledigt. Wieviele Stunden pro Woche zockst du am PC? Da geht jedenfalls vermutlich deutlich mehr Energie drauf, das Strom-Argument fand ich schon immer lächerlich.
Siehe auch: http://www.linux-mag.com/id/7574/ (etwas älter und nicht ganz passend zum Thema)
Ergebnis von diesem Artikel: Mit Compiler Optimierung durch die Bank schneller, manchmal weniger manchmal mehr, aber immer deutlich messbar.
Und gerade Projekte wie ffmpeg haben schon lange CPU-Erkennung zur Laufzeit und verwenden eh Handoptimierung, wenn es nicht eh schon über die GPU läuft.
Das stellt jetzt die in dem Artikel festgestellte Performancesteigerung durch Compileroptimierung (so ganz allgemein, für fast jede beliebige Anwendung) inwiefern infrage? Bzw. was willst du mir damit sagen? Dass Compileroptimierung nicht sinnvoll ist weil einige Pakete aufwändige Handoptimierung haben? Was ist mit den 10000 anderen Paketen die das nicht haben? Ich bitte dich...
LordDeath
2013-04-25, 01:53:23
Wie sieht es bei Gentoo eigentlich mit clang aus?
Gibt es dort überhaupt Bestreben, den GCC durch clang zu ersetzen? Gerade das regelmäßige Kompilieren von neuen Paketen sollte mit clang doch wesentlich schneller gehen.
So ein Wechsel ist aber natürlich nicht im Handumdrehen zu machen: http://clang.debian.net/
drdope
2013-04-25, 02:05:33
Gentoo "lohnt" sich imho nur Systeme die man sehr fein granuliert an die eigenen Bedürfnisse anpassen will.
Dank rolling Updates minimiert sich der Adminaufwand.
Die "Arch-Anpassung" kann man imho in die Tonne kloppen, da profitieren ggf. einige Pakete von, aber imho ist das (abgesehen von sehr speziellen Szenarien) vernachlässigbar.
Von den aktuellen Stable-Packages nutzen kaum 2-3% überhaupt einen 2/3/4. CPU-Kern zum kompilieren, geschweige den seinen vollen Funktionsumfang.
Es gibt viele Argumente pro Gentoo, aber hochoptimierten Code dank "pseudo-manuellen" Einfluß auf den GCC und dessen Options fielen mir vermutlich zuletzt ein... davon profitieren - wenn überhaupt - nur sehr sehr wenige Pakete.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.