Alles rund um Compiler und Softwareentwicklung

Kannst du die LAME-MinGW-Builds im Startpost erneut hochladen? Es scheint nichts mehr verfügbar zu sein. Ich hätte gern die bdver2-Variante.
 
Unbekannter Krieger schrieb:
y33H@
Angesichts dessen, dass der GCC nicht AMD-exklusiv oder ausschließlich AMD-optimiert ist und nach wie vor nicht vollkommen solide (andererseits: wann ist ein Produkt das schon?), sind 11 Prozent gar nicht mal so wenig.
Zum Vergrößern anklicken....
Was verstehst du unter solide?

--- Update ---

gruffi schrieb:
Vor allem, wenn man es von beiden Seiten betrachtet. Wenn der FX mit den richtigen Compilerflags 11% schneller wird, so kann ein i7 mit unpassenden Compilerflags auch mal >10% Performance verlieren.
Zum Vergrößern anklicken....
Warhscheinlich sogar noch mehr. Nach den letzten Tests, dich ich gesehen habe, profitiert der i7 unheimlich von der AVX(2) Unterstützung. Lässt man die weg, lässt man einiges an Geschwindigkeit liegen.
Auf der anderen Seite bringt es aber gar nicht so viel mehr, wenn man alle unterstützten Erweiterungen aktiviert, aber nicht auf eine direkte Architektur optimiert.
 
Unbekannter Krieger schrieb:
Kannst du die LAME-MinGW-Builds im Startpost erneut hochladen? Es scheint nichts mehr verfügbar zu sein. Ich hätte gern die bdver2-Variante.
Zum Vergrößern anklicken....
Hmm, seltsam. Gelöscht hatte ich die eigentlich nicht. Ich lade nochmal Builds mit GCC 4.9.2 hoch.

--- Update ---

Neue LAME Builds stehen zur Verfügung. Startbeitrag aktualisiert.
 
gehört Kaveri auch noch zu BDver2, oder gibt es noch keine neueren Optimierungsstufen?
 
Wie mein Vorredner schon sagt, Steamroller (Kaveri) ist bdver3. Die LAME Executables für bdver2 und bdver3 waren aber identisch gross. Daher habe ich bdver3 erst mal weggelassen. Vermutlich gibt's da keine nennenswerten Unterschiede. Die gibt es dann erst wieder mit bdver4 (Excavator). Den Build könnte ich auch bereitstellen. Wird vermutlich nur noch niemand testen können. :)
 
Ich habe jetzt nochmal nachgesehen. Bdver3 nutzt ein signifikant anderes scheduling als bdver1/2. Es gibt nur noch drei statt vorher vier FP Units, decode/fetching ist auch geändert. Insofern wären mögliche Laufzeitunterschiede mit den verschiedenen march-Optionen doch interessant.
 
Decode und Scheduling hat sich doch vor allem geändert, was das gesamte Modul betrifft, also wenn man zwei Threads auf einem Modul laufen lässt. Weiss nicht, ob das hier wirklich viel ausmacht, da LAME singlethreaded ist. Und bei der FPU ist im Wesentlichen eine Integer SIMD Einheit weggefallen, deren Funktionalität in eine FP SIMD Einheit (FMAC) integriert wurde. Auch das dürfte bei lediglich einem Thread nicht viel ausmachen.

Ich lade den den bdver3 Build trotzdem hoch. Also wer einen Kaveri hat, kann es ja mal testen.
 
gruffi schrieb:
Decode und Scheduling hat sich doch vor allem geändert, was das gesamte Modul betrifft, also wenn man zwei Threads auf einem Modul laufen lässt. Weiss nicht, ob das hier wirklich viel ausmacht, da LAME singlethreaded ist. Und bei der FPU ist im Wesentlichen eine Integer SIMD Einheit weggefallen, deren Funktionalität in eine FP SIMD Einheit (FMAC) integriert wurde. Auch das dürfte bei lediglich einem Thread nicht viel ausmachen.
Zum Vergrößern anklicken....
Das hat jetzt nichts mit thread level parallelism zu tun. Es geht darum, wie viele x86-Befehle pro Zyklus dekodiert werden können und auf wie viele Units diese dann verteilt werden können.
 
Das hat aber vor allem Auswirkung bei zwei Threads, weniger bei einem wie mit LAME. Für einen Integer Cluster können nach wie vor nur 4 Instruktionen pro Takt dekodiert werden. Einzig relevante Optimierung für Steamroller wäre, dass MOVs nun auch über die AGLUs ausgeführt werden können. Den Loop Optimizer gibt's zwar auch noch. Aber das kommt hauptsächlich von der Hardware. Der Compiler muss eigentlich nur auf die Grösse der Schleifen achten. Notfalls kann er hier und da ein Byte sparen, um die Grösse passend zu machen. Viel Spielraum bleibt da oft aber nicht. Und bei der FPU haben sich wie gesagt die Pipes nicht gross geändert. Es ist lediglich eine für dieses Szenario eher nebensächliche Integer SIMD Pipe weggefallen. Bzw ist Pipe 2 (FPMAL) in Pipe 0 gewandert. Und die Shuffle Einheit aus der zweiten FP SIMD Pipe ist in die übrig gebliebene Integer SIMD Pipe gewandert. So wie mit bdver2 die Instruktionen verteilt wurden, so ähnlich sollten also auch die Instruktionen mit bdver3 verteilt werden, solange man FP nutzt.

Bdver3 gewinnt seine Performance ja hauptsächlich durch schnelleren L1/L2 Cache, bessere Sprungvorhersage, geringere Latenzen und mehr Ressourcen für zwei Threads. Da kann der Compiler relativ wenig machen. Daher denke ich wird es auch keine allzu grossen Unterschiede zwischen bdver2 und bdver3 Builds geben.
 
aus dem gcc:

;; AMD bdver1 Scheduling
;;
;; The bdver1 contains four pipelined FP units, two integer units and
;; two address generation units.
;;
;; The predecode logic is determining boundaries of instructions in the 64
;; byte cache line. So the cache line straddling problem of K6 might be issue
;; here as well, but it is not noted in the documentation.
;;
;; Three DirectPath instructions decoders and only one VectorPath decoder
;; is available. They can decode three DirectPath instructions or one
;; VectorPath instruction per cycle.
;;
;; The load/store queue unit is not attached to the schedulers but
;; communicates with all the execution units separately instead.
(define_cpu_unit "bdver1-decode0" "bdver1")
(define_cpu_unit "bdver1-decode1" "bdver1")
(define_cpu_unit "bdver1-decode2" "bdver1")
(define_cpu_unit "bdver1-decodev" "bdver1")

;; AMD bdver3 Scheduling
;;
;; The bdver3 contains three pipelined FP units and two integer units.
;; Fetching and decoding logic is different from previous fam15 processors.
;; Fetching is done every two cycles rather than every cycle and
;; two decode units are available. The decode units therefore decode
;; four instructions in two cycles.
;;
;; The load/store queue unit is not attached to the schedulers but
;; communicates with all the execution units separately instead.
(define_cpu_unit "bdver3-decode0" "bdver3")
(define_cpu_unit "bdver3-decode1" "bdver3")
(define_cpu_unit "bdver3-decodev" "bdver3")

PS: Multithreaded interessiert den gcc hier überhaupt nicht. Für den ist wichtig, welche x86-Befehle von der CPU wie dekodiert werden, um einen möglichst optimalen Mix zu erstellen. Ziel ist, alle Units komplett auszulasten dabei.
 
Zuletzt bearbeitet:
gruffi schrieb:
Wie mein Vorredner schon sagt, Steamroller (Kaveri) ist bdver3. Die LAME Executables für bdver2 und bdver3 waren aber identisch gross. Daher habe ich bdver3 erst mal weggelassen. Vermutlich gibt's da keine nennenswerten Unterschiede. Die gibt es dann erst wieder mit bdver4 (Excavator). Den Build könnte ich auch bereitstellen. Wird vermutlich nur noch niemand testen können. :)
Zum Vergrößern anklicken....

Kann ich nach ersten Tests bestätigen.
Beide Encodes werden gleich gross und dauern gleich lang.
Getestet mit einer *.wav von 01h:03m:08s länge, welche in beiden Fällen (bdver2/bdver3) auf Kaveri A8-7600@45W 01m:03s zum Umwandeln brauchte.
Nicht das was man signifikant nennen würde ...
Tritt wenn überhaupt dann mit multithreaded Software zutage, welche dann aber auch länger braucht.
Lame ist da wohl auch der Falsche Use Case für so einen Vergleich.

Wobei ...
Grad noch die K10 Version getestet, die läuft immerhin länger 01m:08s bei gleicher Grösse, also +5s

Ok, Haswell schmiert ab ... *chatt**baeh*

... und, puhhh *schwitz* -> Sandy ist eine Sekunde langsamer als bdver2/3. ;D 8) *buck**baeh*

Das hätt mich sonst angekotzt ...*lol*
 
Zuletzt bearbeitet:
??
Ich meinte das in diesem Fall (singlethreaded lame) einfach keine grösseren Laufzeitdifferenzen zu Tage treten werden.
Erst wenn man eine multithreaded Soft nimmt und die dann in den entsprechenden Optimisierungen vergleicht, wird man da evtl.
etwas entdecken können über längere Laufzeit gemessen. Bei so simplen und kleinen Sachen ist der vermeintliche Unterschied einfach zu klein.

Nebenbei grad noch auf meinem Vichy getestet: bdver2/3/sandy gleich schnell nur k10 ist 2 sek langsamer.
Das finde ich schon eher interessant. Kaveri sollte sich doch eher wieder ein wenig weg von der Modulbauweise
mit shared Frontend und somit wieder ein wenig dem k10 zuwenden und trotzdem ist die Differenz auf dem Vichy kleiner als auf dem Kaveri.
Lame ist wahrscheinlich auch einfach ein Stück zu alt für die neuesten Entwicklungen.
Oder wird da auch an AVX/AVX2 gebastelt?
Keine Ahnung, benutz das nie.
 
Zuletzt bearbeitet:
Atombossler schrieb:
??
Ich meinte das in diesem Fall (singlethreaded lame) einfach keine grösseren Laufzeitdifferenzen zu Tage treten werden.
Erst wenn man eine multithreaded Soft nimmt und die dann in den entsprechenden Optimisierungen vergleicht, wird man da evtl.
etwas entdecken können über längere Laufzeit gemessen. Bei so simplen und kleinen Sachen ist der vermeintliche Unterschied einfach zu klein.
Zum Vergrößern anklicken....
Okay, so ergibt das für mich jetzt auch langsam Sinn. Lame nutzt anscheinend auch einiges an handoptimierten Code (kurz den Code überflogen), sprich der Compiler hat wenig Chance sich da zu entfalten. Das ist dann für Compiler-Benchmarks eher suboptimal. Da braucht es eher Programme, die die Optimierungen komplett dem Compiler überlassen.

Nebenbei grad noch auf meinem Vichy getestet: bdver2/3/sandy gleich schnell nur k10 ist 2 sek langsamer.
Das finde ich schon eher interessant. Kaveri sollte sich doch eher wieder ein wenig weg von der Modulbauweise
mit shared Frontend und somit wieder ein wenig dem k10 zuwenden und trotzdem ist die Differenz auf dem Vichy kleiner als auf dem Kaveri.
Lame ist wahrscheinlich auch einfach ein Stück zu alt für die neuesten Entwicklungen.
Oder wird da auch an AVX/AVX2 gebastelt?
Keine Ahnung, benutz das nie.
Zum Vergrößern anklicken....
Wie in dem Thread schon erwähnt, die Compiler können das selbstständig nutzen. Bei lame dürfte das aber nicht viel bringen, wenn der rechen-intensive Code von Hand optimiert wurde. Und um den Vorteil von AVX(2) komplett auszuspielen, muss der Code auch vektorisiert werden. Leider ist der auto-vectorizer vom gcc da nicht so überragend.
 
PuckPoltergeist schrieb:
PS: Multithreaded interessiert den gcc hier überhaupt nicht. Für den ist wichtig, welche x86-Befehle von der CPU wie dekodiert werden, um einen möglichst optimalen Mix zu erstellen. Ziel ist, alle Units komplett auszulasten dabei.
Zum Vergrößern anklicken....
Sicherlich interessiert GCC erst mal nicht, was multithreaded passiert. Dennoch, wie bereits gesagt, die Optimierungen, die der Compiler vornehmen kann, haben nur wenig Einfluss auf die Performance. Die Änderungen, die bei den Decodern und Schedulern vorgenommen wurden, zeigen mehr Auswirkungen, wenn zwei Threads auf einem Modul laufen. Ansonsten kommen Performanceverbesserungen bei einem Thread hauptsächlich von der Hardware selbst.

PuckPoltergeist schrieb:
Lame nutzt anscheinend auch einiges an handoptimierten Code (kurz den Code überflogen), sprich der Compiler hat wenig Chance sich da zu entfalten.
Zum Vergrößern anklicken....
Falls du Assembler meinst, der wird nur bei 32-bit Builds genutzt. Für 64-bit fehlen nach wie vor entsprechend optimierte Assembler Routinen.
 
gruffi schrieb:
Falls du Assembler meinst, der wird nur bei 32-bit Builds genutzt. Für 64-bit fehlen nach wie vor entsprechend optimierte Assembler Routinen.
Zum Vergrößern anklicken....
Ich gezog mich auf die intrinsics. Die sehe erstmal architekturunabhängig aus, sofern SSE vorhanden ist. Aber wie gesagt, ich hab es nur überflogen.
 
Hier mal der Link zu der neuen Version 1.3 von Bolt:
http://developer.amd.com/community/blog/2015/01/19/bolt-1-3-whats-new/

boltfallbackimage.png


bolt_sortintperf_graph_boltwhatsnewblog-300x238.jpg

bolt_scanfloatperf_graph_boltwhatsnewblog-300x229.jpg
 
Zuletzt bearbeitet:
Im AT Forum gibt's einen interessanten Thread zu HSA und wie der aktuelle Stand ist, wenn man es selbst schon mal testen möchte. Zu viel erwarten sollte man aber nicht. Noch steht der HSA Softwarestack am Beginn der Entwicklung.
 
Bestünde eigentlich die Möglichkeit, die aktuelle HandBrake-Version auf Piledriver zu optimieren?
 
Da der Quellcode verfügbar ist, natürlich. Es stellt sich eigentlich nur die Frage, wie aufwändig das ganze ist.
 
Ich bin da ahnungslos. Wenn du mal schauen möchtest: Meinen Segen hast du.
 
GCC (MinGW) bietet momentan vielleicht die ausführlichsten Optimierungsoptionen. Eine Kompilierung scheint mit MinGW kein Problem zu sein.

https://trac.handbrake.fr/wiki/CompileOnWindows

Theoretisch sollte es also reichen, dem Compiler einfach nur die entsprechenden Optimierungsflags mitzugeben, ohne am Code was machen zu müssen. Für Piledriver wäre das "-march=bdver2".

Problem könnte sein, dass man zusätzliche Bibliotheken ebenfalls neu übersetzen müsste und ggf auch die CLI Executable. Das wiederum könnte dann schon aufwändiger werden.
 
Unbekannter Krieger schrieb:
Bestünde eigentlich die Möglichkeit, die aktuelle HandBrake-Version auf Piledriver zu optimieren?
Zum Vergrößern anklicken....

Was versprichst Du Dir davon?
Allzuviel bringen wird es nicht.

Das GUI wird nicht "schneller" werden ... ;D
... und bei den encoding libs (also x264/x265) liegt der Unterschied im Nachkommabereich.

Hier mal ein Vergleich, den ich mit VC/ICC/GCC und x265 gemacht habe.
Results for x265.exe build 1.4+5 [vcru]
x265 Benchmark: 64-bit
==========================

CRF-20 preset-"fast"
--------------------
encoded 1128 frames in 115.11s (9.80 fps), 2991.03 kb/s
encoded 1128 frames in 115.42s (9.77 fps), 2991.03 kb/s
encoded 1128 frames in 114.84s (9.82 fps), 2991.03 kb/s
encoded 1128 frames in 116.42s (9.69 fps), 2991.03 kb/s

Results for x265.exe build 1.4+5 [vcchroma]
x265 Benchmark: 64-bit
==========================

CRF-20 preset-"fast"
--------------------
encoded 1128 frames in 118.03s (9.56 fps), 2991.03 kb/s
encoded 1128 frames in 118.19s (9.54 fps), 2991.03 kb/s
encoded 1128 frames in 118.38s (9.53 fps), 2991.03 kb/s
encoded 1128 frames in 118.77s (9.50 fps), 2991.03 kb/s


Results for x265.exe build 1.4+5 [iccru]
x265 Benchmark: 64-bit
==========================

CRF-20 preset-"fast"
--------------------
encoded 1128 frames in 115.23s (9.79 fps), 2991.03 kb/s
encoded 1128 frames in 114.67s (9.84 fps), 2991.03 kb/s
encoded 1128 frames in 115.50s (9.77 fps), 2991.03 kb/s
encoded 1128 frames in 115.25s (9.79 fps), 2991.03 kb/s


Results for x265.exe build 1.4+5 [gccru]
x265 Benchmark: 64-bit
==========================

CRF-20 preset-"fast"
--------------------
encoded 1128 frames in 116.73s (9.66 fps), 2991.03 kb/s
encoded 1128 frames in 117.00s (9.64 fps), 2991.03 kb/s
encoded 1128 frames in 116.44s (9.69 fps), 2991.03 kb/s
encoded 1128 frames in 116.77s (9.66 fps), 2991.03 kb/s


Results for x265.exe build 1.4+5 [gcceu]
x265 Benchmark: 64-bit
==========================

CRF-20 preset-"fast"
--------------------
encoded 1128 frames in 118.41s (9.53 fps), 2991.03 kb/s
encoded 1128 frames in 119.12s (9.47 fps), 2991.03 kb/s
encoded 1128 frames in 118.59s (9.51 fps), 2991.03 kb/s
encoded 1128 frames in 119.55s (9.44 fps), 2991.03 kb/s
Viel wesentlicher ist da das generelle Setup und die Version.
z.B. war die x265-1.5.251 mit GCC 4.6.3 die bisher schnellste (signifikant! + >1fps).

Das liegt auch daran, das der Code generell schon optimiert ist (assembler).
Bei unoptimiertem Code könnte da evtl. einiger benefit zu holen sein, aber so ...
 

Ähnliche Themen

eratte
Download HandBrake 1.3.0 für Windows, Mac und Linux vefügbar.
Antworten
3
Aufrufe
2K
Hotstepper
Hotstepper
eratte
MSI A88XM Gaming & A10 7860k und DDR3 2100 vs Gigabyte GA-B85M-D2V (rev. 3.0) & Intel i3 4130 und DDR3 1600
2
Antworten
37
Aufrufe
13K
eratte
eratte
eratte
News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)
29 30 31
Antworten
760
Aufrufe
99K
eratte
eratte
Dr@
Download AMD Catalyst 13.4 Proprietary Linux Display Driver
Antworten
10
Aufrufe
9K
Liszca
L
Dr@
Fujitsu STYLISTIC Q572 mit AMD Z-60 APU
Antworten
0
Aufrufe
52K
Dr@
Dr@
Zurück
Oben Unten