Alles rund um Compiler und Softwareentwicklung

gruffi

Grand Admiral Special
Mitglied seit
08.03.2008
Beiträge
5.393
Renomée
65
Standort
vorhanden
Damit die anderen Threads nicht noch weiter geshreddert werden, mach ich mal hier einen neuen auf, wo weiterdiskutiert werden kann.


Zum Thema ICC, und um mit dem Ammenmärchen aufzuräumen, dass der auch für AMD immer der schnellste wäre. Da LAME und ähnliche Encoder gerne in Reviews verwendet werden, habe ich LAME mal durch den aktuellen GCC 4.9.0 (MinGW 64-bit) gejagt, -march/mtune auf native, also für meinem Llano X4 optimiert. Ergebnis, ~15% schneller als der aktuelle ICC 14 Build von rarewares. Der MinGW Build läuft selbst auf meinem Core2 Notebook noch etwas schneller als der ICC Build. Allerdings sind dort die Unterschiede erwartungsgemäss deutlich geringer.

ICC


GCC (MinGW)


MinGW 4.9.2 Builds

K10 (amdfam10):
http://www.file-upload.net/download-10070595/lame_mingw_4.9.2_x86_64_amdfam10.7z.html

Llano (native):
http://www.file-upload.net/download-10070599/lame_mingw_4.9.2_x86_64_llano_native.7z.html

Vishera / Trinity / Richland (bdver2):
http://www.file-upload.net/download-10070594/lame_mingw_4.9.2_x86_64_bdver2.7z.html

Kaveri (bdver3)
http://www.file-upload.net/download-10073768/lame_mingw_4.9.2_x86_64_bdver3.7z.html

Sandy Bridge (sandybridge):
http://www.file-upload.net/download-10070598/lame_mingw_4.9.2_x86_64_sandybridge.7z.html

Haswell (haswell):
http://www.file-upload.net/download-10070592/lame_mingw_4.9.2_x86_64_haswell.7z.html

Falls gewünscht, kann ich auch noch MinGW Builds für andere Prozessoren hochladen.




Liste bekannter bzw nützlicher kostenfreier Software für Entwicklung und Benchmarken:

Cinebench
Benchmark für 3D-Rendering - Webseite
Code::Blocks
Multiplattform Entwicklungsumgebung (unterstützt etliche Compiler, Open Source) - Webseite
CPU-Z
Infotool für wichtige Systemkomponenten - Webseite (Cache Latency Tool)​
GPU-Z
Infotool für Grafikprozessoren - Webseite
Hyper Pi
Pi-Berechnung (Super Pi integriert) - Webseite
LAME
MP3 Audio Encoder (Open Source) - Webseite
MinGW
Multiplattform Compiler (GCC Port für Windows, Open Source) - Webseite (32-bit, 64-bit)​
POV-Ray
Raytracer (Benchmark integriert, Open Source) - Webseite
RightMark Memory Analyzer
Analysetool für Cache oder RAM (Open Source) - Webseite
System Stability Tester
Benchmark und Stresstester mittels Pi-Berechnung - Webseite
Visual Studio Express
Entwicklungsumgebung von Microsoft - Webseite
x264
H.264 Video Encoder (Open Source) - Webseite
x265
H.265 Video Encoder (Open Source) - Webseite
y-cruncher
Benchmark und Stresstester mittels Berechnung diverser mathematischer Konstanten - Webseite

Stand: 08.06.2014




Verhaltensregeln:

Ich bitte alle hier sachlich zu bleiben und konstruktive Beiträge zu verfassen. Sinnvolle Spekulationen, Fakten, Fragen, Vorschläge, Tests, Kritik, ist alles erwünscht. Leute, die das zusammengetragene Material ständig mit Erkenntnisresistenz torpedieren und nichts sinnvolles beitragen, sind hier unerwünscht.
 
Zuletzt bearbeitet:
Hallo!
Ich hätte Interesse an einem FX-8350-optimierten LAME. Da ich kein Fan von Kommandozeilen bin, nutze ich bislang WinLAME. Es scheint mir nicht, als könne man die LAME-Komponente einfach austauschen.
Kennst du zufällig eine GUI für LAME, die ich alternativ verwenden könnte und die den Austausch von LAME ermöglicht?
 
Vielleicht LameXP? Ich kenne WinLAME ehrlich gesagt nicht. Kann dir daher auch nicht sagen, was funktionell vergleichbar ist. Früher habe ich immer CDex genutzt. Das hat aber schon seit längerem kein Update mehr gesehen. RazorLame gäbe es auch noch. Einfach mal nach "LAME Frontend" oder ähnlichem suchen. Da wird man einiges finden.

Ein Piledriver Build sollte kein Problem sein. Mal schauen, ob ich den noch heute Abend hochladen kann.
 
@gruffi
Kannst du dazu evt. was sagen:

cinebenchr15_iccz5u7r.jpg


Patched läuft es reproduzierbar schneller, jedoch in der Messtoleranz. *noahnung*
 
Ok, ich hab es jetzt 3x mal in einer Windows Sitzung laufen lassen, die Toleranz geht gegen +/- 3 Pkt.
Sonst hätte ich den I7-4770K nicht "überholen" können:

cb_r15_icc4gfo1.jpg
 
LAME für bdver2 und bdver3 steht im Startbeitrag zur Verfügung.


@gruffi
Kannst du dazu evt. was sagen:

cinebenchr15_iccz5u7r.jpg
Den Patcher kenne ich nicht. Ich würde mir von solchen Sachen aber nicht mehr allzu viel versprechen. Cinebench R15 ist ja noch nicht so alt. Da sollte also eine relativ aktuelle Version des Intel Compilers zum Einsatz kommen. Und Intel scheint bei neueren Versionen nichts beeinträchtigendes mehr mit der CPUID Herstellerkennung anzustellen. Oder formulieren wir es anders. Aufgrund der Auflagen der FTC machen sie es zumindest nicht mehr so offensichtlich. ;D Auch wenn man es nach wie vor noch nicht völlig ausschliessen kann. Die starke Intel Optimierung in Cinebench liesse sich halt nur mit einer Neukompilierung lösen, am besten mit einem neutralen Compiler. Das wird aber so schnell nicht passieren.
 
Zuletzt bearbeitet:
@gruffi
http://winlame.sourceforge.net/index.php
Mein winLAME-Installationsverzeichnis sieht so aus:


@all
Tarnung eines Intels als AMD und umgekehrt für Compilertestzwecke
Ich würde es gern selbst testen, doch laut HWInfo64 ist AMD-V (Virtualisierung) bei mir "disabled", obwohl "supported".
Im BIOS ist "Secure Virtual Machine" aktiviert. Es wird ein Fehler oder eine Einstellung im OS sein. Oder ein Anzeigefehler.
Selbst falls ich VMs zum Laufen bekäme, müsste ich nur für den Test eine einrichten.

Zumindest wird Virtualisierung für den Test benötigt, zudem VMWare (andere VM wird wohl auch gehen).
Für die genaue (kurze!) Anleitung, siehe Beitrag #43 hier
http://www.techpowerup.com/forums/t...courtesy-the-stilt.186056/page-2#post-2927933

@WindHund
Du meintest einen 3770k, nicht einen 4770k, oder?
 
Zuletzt bearbeitet:
So wie ich das gelesen habe, nutzt WinLAME eine eigene Schnittstelle für LAME, bereitgestellt mittels nLAME.dll. Da nützen einem die Standard Builds (lame.exe, lame_enc.dll) leider nichts.
 
gruffi mal ne blöde Frage, nutzt du vllt. die 32bit ICC Version von Lame?
Die hatte ich nämlich auch erst und hatte bei meinem 5800k auch ca. 13-15% Differenz. Mit 64 bit nehmen sich beide Versionen allerdings nichts, bzw. sind die Werte des ICC sogar minimalst besser.

E: eine Gemeinsame Testdatei und vllt. auch noch die selben Parameter wären vllt auch für so einen Test hilfreich.

Unbenannt.png
 
Zuletzt bearbeitet:
Nein, ich habe schon die 64-bit Version genutzt. 32-bit habe ich separat auch getestet. Da hatte ich immer noch bessere Ergebnisse mit MinGW. Auch wenn es etwas weniger war. 32-bit liefert generell niedrigere Ergebnisse. Daher sollte man schon 64-bit nutzen, wenn es das System erlaubt.

Du hast halt einen anderen Prozessor mit anderer Architektur als ich. Das eine lässt sich nicht auf das andere übertragen. Deshalb hatte ich das auch im Startbeitrag nochmal angesprochen. Weil ja auch gerne mal behauptet wird, der ICC würde auch für AMD grundsätzlich die besten Ergebnisse liefern. Zuletzt auch hier im Forum wieder. Dem ist eben nicht so. Der ICC ist und bleibt ein Glücksspiel für AMD CPUs.

Testdatei war übrigens eine ~50 MB grosse WAV Datei, einmal mit -V0 und einmal mit -V2 Flag für LAME. Man sollte am besten mehrere Durchläufe machen, um Ausreisser zu eliminieren. Auch hat es bei mir geholfen, den Prozess mittels Task-Manager auf einen Kern festzupinnen. Dann waren die Ergebnisse relativ konstant. Davor gab es deutlich mehr Schwankungen.

2 Screenshots noch im Startbeitrag eingefügt.
 
Zuletzt bearbeitet:
Ich würde lieber mal LLVM/Clang dagegen testen.
 
Den Patcher kenne ich nicht. Ich würde mir von solchen Sachen aber nicht mehr allzu viel versprechen. Cinebench R15 ist ja noch nicht so alt. Da sollte also eine relativ aktuelle Version des Intel Compilers zum Einsatz kommen. Und Intel scheint bei neueren Versionen nichts beeinträchtigendes mehr mit der CPUID Herstellerkennung anzustellen. Oder formulieren wir es anders. Aufgrund der Auflagen der FTC machen sie es zumindest nicht mehr so offensichtlich. ;D Auch wenn man es nach wie vor noch nicht völlig ausschliessen kann. Die starke Intel Optimierung in Cinebench liesse sich halt nur mit einer Neukompilierung lösen, am besten mit einem neutralen Compiler. Das wird aber so schnell nicht passieren.
Ok, danke für dein Input!
Den ICC-Patcher gibt es z.B. hier: http://encode.ru/threads/1602-ICC-patcher-for-AMDs
Es ist ja ok wenn gewisse Feature abgefragt werden vom Programm, müssen sogar wenn das Programm "kompatible" sein soll.
Aber eine reine Abfragung Intel Präsent oder nicht, ist ein wenig verdächtig.


Hab mal den y-cruncher Multithread gegen SuperPi 1.6 laufen lassen:


17 Minuten 33 Sek vs 9.332 Sek :o
Man könnte meinen, die Software hat sich in 19 Jahre verhundertfacht (111)
 
Hallo!
Ich hätte Interesse an einem FX-8350-optimierten LAME. Da ich kein Fan von Kommandozeilen bin, nutze ich bislang WinLAME. Es scheint mir nicht, als könne man die LAME-Komponente einfach austauschen.
Kennst du zufällig eine GUI für LAME, die ich alternativ verwenden könnte und die den Austausch von LAME ermöglicht?

Wie wäre es mit BeSweet bzw. BeLight?!
 
Man könnte meinen, die Software hat sich in 19 Jahre verhundertfacht (111)
Wobei die Performance von Pi Berechnungen nicht nur vom Prozessor abhängt, sondern vor allem vom verwendeten Algorithmus. Super Pi Mitte der 90er nutze Gauss–Legendre. Mittlerweile werden halt effizientere Algorithmen genutzt, wie zb Chudnovsky. Der System Stability Tester erlaubt übrigens auch die Berechnung mittels Gauss–Legendre.


Übrigens, ich würde im Startbeitrag gerne eine Liste mit häufig genutzten Tools fürs Testen, Benchmarken, Übertakten/Untervolten, etc mit ihren Eigenheiten anlegen. Wünsche sind willkommen.
 
Übrigens, ich würde im Startbeitrag gerne eine Liste mit häufig genutzten Tools fürs Testen, Benchmarken, Übertakten/Untervolten, etc mit ihren Eigenheiten anlegen. Wünsche sind willkommen.
Auch wenn schon vielfach durchgekaut, würde es als direkte Referenz (die dann auch kompakt sämtliche Fragen beantwortet) nichts schaden, gleich auf die häufigsten (oder lautesten?) Vertreter zu sprechen zu kommen, d.h. gerade so Kandidaten wie Cinebench (siehe Kaveri - Thread).
 
@WindHund
Du meintest einen 3770k, nicht einen 4770k, oder?
Den 3770K mit Standard Takt gepatcht und den 4770K übertaktet & gepatcht.
Hast du im UEFI eine "IOMMU" Option, wenn ja "enabled" Einstellen. (evt. geht AMD-V deswegen nicht)

Wobei die Performance von Pi Berechnungen nicht nur vom Prozessor abhängt, sondern vor allem vom verwendeten Algorithmus. Super Pi Mitte der 90er nutze Gauss–Legendre. Mittlerweile werden halt effizientere Algorithmen genutzt, wie zb Chudnovsky. Der System Stability Tester erlaubt übrigens auch die Berechnung mittels Gauss–Legendre.


Übrigens, ich würde im Startbeitrag gerne eine Liste mit häufig genutzten Tools fürs Testen, Benchmarken, Übertakten/Untervolten, etc mit ihren Eigenheiten anlegen. Wünsche sind willkommen.
Ok, also kann ein Algo soviel ausmachen?
Der System Stability Tester skaliert mit Gauss-Leg. negative auf mehr Threads:
Borwein ist in allen Disziplinen langsamer/braucht länger.

Was halltest du von: http://www.yeppp.info/home/yeppp-performance-numbers/
 
Der System Stability Tester skaliert mit Gauss-Leg. negative auf mehr Threads:
Die negative Skalierung bei mehreren Threads ist eigentlich normal. Je mehr Threads Last erzeugen, umso weniger Performance hast du pro Thread, weil dann diverse Ressourcen geteilt werden müssen oder weil Threadsynchronisierung ausbremst. Und gerade von 4 auf 8 Threads fällt bei deinem FX die Performance pro Thread deutlicher ab, da sich nun 2 Threads ein Modul teilen müssen. Man sollte bedenken, dass in der Zeit dann aber auch 8x 32M Stellen berechnet wurden und nicht nur 4x 32M. Das macht in der gleichen Zeit immer noch fast 50% mehr berechnete Stellen bei 8 Threads.
 
Ich würde lieber mal LLVM/Clang dagegen testen.
Weiss nicht, ob sich das wirklich lohnt. LLVM Clang schaut nicht gerade gut gegen GCC 4.9 aus, wenn es um Audio Encoding geht. GCC 4.10 ist ja auch schon am Start. Habe ich bisher aber noch nicht getestet, da er noch instabil sein soll.

---------- Beitrag hinzugefügt um 22:37 ---------- Vorheriger Beitrag um 22:16 ----------

Falls es möglich ist z.B. einen x264 mit GCC 4.9.0 + Bd.Ver2 zu compilieren, der diese Bibliothek nutzt wär das mal ein lohnendes Testobjekt.
Naja, das Problem ist, die Software müsste erst mal eine solche Bibliothek nutzen. Ich glaube nicht, dass das bei x264 der Fall ist. Wenn eine solche Bibliothek nicht genutzt wird, dann müsste man es erst implementieren. Das kann uU recht aufwändig werden. Und die Frage wäre dann, ob es sich in dem Fall überhaupt lohnt. Im Endeffekt sind das in den Yeppp Diagrammen nur spezielle und für Prozessoren meist sehr aufwändig zu berechnende Operationen, die in den meisten Anwendungen gar keine oder eine nur sehr begrenzte Verwendung finden. Schaut in den Diagrammen zwar toll aus, wenn zB log dreimal so schnell berechnet werden kann. Wenn es aber zB nur 0,1% der Laufzeit ausmacht, springt unterm Strich trotzdem keine sichtbar verbesserte Performance heraus. Das fällt dann eher unter Messtoleranz. Solche Bibliotheken machen wirklich nur dort Sinn, wo solche Operationen auch häufig genutzt werden.
 
@WindHund
Und dein FX-8350 konnte beide einholen oder gar überholen?
IOMMU ist eingeschaltet.

@LoRDxRaVeN
Werden die vom Cache-Tool angezeigten Werte von BIOS-Einstellungen beeinflusst?
 
Zuletzt bearbeitet:
Kann ich eigentlich nicht sagen - ich habe selbst keinerlei Erfahrung mit der Anwendung der Tools. Aber prinzipiell, wenn es sich auf "pro Takt" bezieht, fällt mir jetzt nichts ein, das du im BIOS verändern kannst, dass eine Auswirkung hat. Absolute Latenzen etc. würden sich mit unterschiedlichen Cachetaktfrequenzen natürlich ändern.
Wenn du willst, kannst du "MusicIsMyLife" fragen. Er hat den Vishera Artikel geschrieben und die Tools eingesetzt.

LG
 
Die negative Skalierung bei mehreren Threads ist eigentlich normal. Je mehr Threads Last erzeugen, umso weniger Performance hast du pro Thread, weil dann diverse Ressourcen geteilt werden müssen oder weil Threadsynchronisierung ausbremst. Und gerade von 4 auf 8 Threads fällt bei deinem FX die Performance pro Thread deutlicher ab, da sich nun 2 Threads ein Modul teilen müssen. Man sollte bedenken, dass in der Zeit dann aber auch 8x 32M Stellen berechnet wurden und nicht nur 4x 32M. Das macht in der gleichen Zeit immer noch fast 50% mehr berechnete Stellen bei 8 Threads.
Ok, dann ist das eher was für Stabilitätstest. Interessant dann sollte man nicht nur die Zeit sehen sondern auch die Datenmenge die Verarbeitet wird.

Hier mal noch y-cruncher Single Thread & MT 256MB / ST 32M

Ich hab das letztens auch schon zweimal gepostet, wir komplett wegignoriert. 8-(

Falls es möglich ist z.B. einen x264 mit GCC 4.9.0 + Bd.Ver2 zu compilieren, der diese Bibliothek nutzt wär das mal ein lohnendes Testobjekt.
Vielleicht könnte sich das ein Compilierprofi mal ansehen. 8)
Bei x264 hilft es oft die neuste Datei Version zu laden: http://www.x264.nl/x264_main.php
@WindHund
Und dein FX-8350 konnte beide einholen oder gar überholen?
IOMMU ist eingeschaltet.

@LoRDxRaVeN
Werden die vom Cache-Tool angezeigten Werte von BIOS-Einstellunegn beeinflusst?
Sieht man doch im CineBench R15 Bild oben, alle FX-8350 Ergebnisse sind mit dem selben System zustande gekommen.
Ja die Cache Werte werden beeinflusst, mit höherem Takt sinkt die Latenz. ;)

€dit: Bezüglich AMD-V, das hier schon probiert: http://www.youtube.com/watch?v=YzaCOZAYtJs ?
 
Zuletzt bearbeitet:
Naja, das Problem ist, die Software müsste erst mal eine solche Bibliothek nutzen. Ich glaube nicht, dass das bei x264 der Fall ist. Wenn eine solche Bibliothek nicht genutzt wird, dann müsste man es erst implementieren. Das kann uU recht aufwändig werden. Und die Frage wäre dann, ob es sich in dem Fall überhaupt lohnt. Im Endeffekt sind das in den Yeppp Diagrammen nur spezielle und für Prozessoren meist sehr aufwändig zu berechnende Operationen, die in den meisten Anwendungen gar keine oder eine nur sehr begrenzte Verwendung finden. Schaut in den Diagrammen zwar toll aus, wenn zB log dreimal so schnell berechnet werden kann. Wenn es aber zB nur 0,1% der Laufzeit ausmacht, springt unterm Strich trotzdem keine sichtbar verbesserte Performance heraus. Das fällt dann eher unter Messtoleranz. Solche Bibliotheken machen wirklich nur dort Sinn, wo solche Operationen auch häufig genutzt werden.

Das ist klar.
Ich ging mal davon aus, das x264 doch recht viele mathematische Berechnungen durchführt (weiss batürlich nicht genau welche exakt).
Wenn die Bibliothek kaum genutzt wird ist es natürlich obsolet.

---------- Beitrag hinzugefügt um 12:47 ---------- Vorheriger Beitrag um 12:37 ----------

Bei x264 hilft es oft die neuste Datei Version zu laden: http://www.x264.nl/x264_main.php

Hab immer die Neueste (r2431) am Start. 8)
Auf deiner Seite ist nur die (r2334) als aktuell verzeichnet.
Die nehmen auch erst den GCC 4.7.2

Wo kann man sich denn mal einlesen wie man z.B. x264 Prozessorspezifisch compiliert?
Oder kann einer (wenn es wenig genug ist) mal auflisten, was man (neben GCC nat.) braucht.
Bin da nicht so in dem Thema drin.

Gibt es ein MinGW-build mit GCC 4.9.0?
Das letzte MinGW-build ist ja fast ein Jahr alt und noch mit GCC 4.8.1.
 
Zuletzt bearbeitet:
MinGW ist im Startbeitrag verlinkt. Da findest du aktuelle 32- und 64-bit Versionen. Ich kann ja mal versuchen, ob ich x264 mit Version 4.9 kompiliert bekomme. Viel erwarten solltest du aber nicht. So wie ich das sehe, ist x264 schon ziemlich gut handgetuned mittels Assembler. Da kann auch der beste Compiler nicht mehr viel machen. Zumal dann eh ein separater Assembler zum Einsatz kommt wie NASM oder YASM.
 
Zuletzt bearbeitet:
Zurück
Oben Unten