Hat geklappt auch wenns gedauert hat. FÜr mich als Linux b00n wars ne gute Übung.
x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)
-
-
ups...
-
Kabini nichPower I
13:35:10 | 3mbryoyo | 1/2/2 | AMD A4 1200 1,0GHz | 2GiB DDR3 1066 7-7-8-19 | Asus X102BA | AMD K16 IMC | MX Linux 19.1 GCC 8.3.0
Command rate muss ich noch rausfinden wenn der Schrotthaufen fertig ist.
-
War das das gleiche Kompilat wie beim letzten Lauf?
Das geht nämlich, wenn die gleichen Bibliotheken vorhanden sind und der Kernel relativ gleich ist.
-
MX Linux.. von dem habe ich auch noch nicht gehört.
-
Keine Ahnung Ich bin einfach zwei Male der Linux Anleitung für den Benchmark gefolgt. Einmal mit Fedora und einmal mit MX Linux. Hat sich ziemlich gleich angefühlt.
Wie finde ich das heraus?
MX Linux.. von dem habe ich auch noch nicht gehört.
Ich auch kürzlich erst, das Internet behauptet es wäre das beliebteste Linux des Interwebz,
-
Ein "Kompilat" ist das Ergebnis, das der Compiler aus dem C/C++ Code baut. Du hast neu vom Quellcode gebaut, also isses nicht das selbe Kompilat gewesen. Das selbe wäre es gewesen, wenn du die fertigen ffmpeg Bibliotheken und das x264 Programm manuell einfach "rüberkopiert" hättest. Nicht sicher ob das funktioniert hätte. Wegen Dingen wie libc, libstdc++ usw.
-
Okay, ja hab ich neu kompiliert.
Sind zwei Kompilate zwangsläufig unterschiedlich? Oder entsteht unter gleichen Bedingungen (System, OS, Pipapo) auch ein identisches Kompilat?
-
Solange du auf dem gleichen System mit exakt gleichem Betriebssystem und gleicher Compilerversion bleibst, dann in der Regel ja. Aber das trifft auch nicht immer und überall zu, hängt vom Verhalten des Compilers (Edit: Und des Linkers) ab. Ein Wechsel des Compilers wird wahrscheinlich dazu führen, daß sich der Binärcode unterscheidet. Vielleicht optimiert der Compiler ein bißchen besser, oder ein wenig anders, usw. Vielleicht geht er her und übersetzt "a = 3; a = a * 3 + 4" nicht in ein MUL 3, 3* und ein ADD 9, 4*, sondern in ein VFMADD132SS a, 3, 4*, weil er weiß daß deine CPU FMA3 kann, und weil der neuere Compiler damit umgehen kann.
Das ist nur ein kleines Beispiel.
*Das ist Pseudo-Assembler. Der echte Code sieht syntaktisch ein wenig anders aus, aber egal.
-
Zur Verdeutlichung reicht das ja.
Edit: Wie stellt man einen Custombiuld für Windows Versionen her?
-
Nach dem gleichen Schema wie für Linux.
MinGW runterladen (inkl. GCC, NASM / YASM usw.), Quellcode runterladen, BASH starten (wegen der Shell-Skripte, die der Windows Prompt nicht kennt), entpacken usw.
-
Kabini nichPower II
23:45:00.477 | 3mbryoyo | 1/2/2 | AMD A4 1200 1,0GHz | 2GiB DDR3 1066 7-7-8-19 | Asus X102BA | AMD K16 IMC | Windows 8.1 x64
ganz schön Kacke
-
Kabini Power IV
05:38:56.132 | 3mbryoyo | 1/4/4 | Athlon 5350 2,05GHz | 16GiB DDR3 1600 8-8-8-24-1T | AsRock AM1H-ITX | AMD K16 IMC | Windows 8.1 Pro x64
bevor das gänzlich untern Tisch fällt
-
Hier ist die Diskrepanz zwischen Linux und Windows Mal wieder schön schlimm, wegen dem viel neueren x264 auf Linux. Es wurde ja schon drum gebeten, eine bessere Version des Benchmarks zu bauen (ähnlich dem x265er). Damit wäre dann auch eine bessere, offizielle Vergleichbarkeit von Betriebssystemen möglich (weil Version Lock statt Binary Lock). Also gültige Ergebnisse aus Linux & UNIX usw.
Bisher war ich aber zu faul dafür.
Ergebnisse sind eingetragen!
-
Das erklärt die doch nicht zu verachtende Diskrepanz. Hab mich ganz schön erschrocken.
Achja, bei dem Asus X102BA kann ich die command rate nirgends nachsehen.
-
Ist ok, dann lassen wir sie einfach weg. Hilft nichts. Bei manchen Mainboards kann auch CPU-Z die CR nicht auslesen, da kann man dann halt nichts machen.
Um Linux und Windows in x264 halbwegs fair zu vergleichen, müßte man die exakt selbe Version des Quellcodes nutzen, um dann daraus das Programm zu bauen. Beim x265 Benchmark ist es so, deswegen sind z.B. Linux und Windows 10 nicht so weit auseinander. Der hat nur andere Krankheiten, sowie den NUMA Fuckup auf Windows, und die niedrige Fallback-Leistung auf XP x64 / Server 2003 x64 / Vista x64 und Server 2008 x64.
Aaber das wäre erst Mal ein Haufen Arbeit, das Ding neu zu bauen und zu modernisieren...
-
So, endlich geschafft, nach zig Abbrüchen, von denen einige Tage gebraucht haben um zu passieren. Ganz habe ich den Luke nicht auf 400MHz Estherniveau hinuntergebracht, aber immerhin hat es mit 408MHz geklappt. Das sollte für einen halbwegsen IPC Vergleich zwischen Esther und Nehemiah reichen, hier das Ergebnis:
0260:49:52.562 | GAT | 1/1/1 | VIA Luke Corefusion / C3-M (Nehemiah) 408MHz | 1GiB DDR/254 2.5-3-3-7-2T | VIA Epia NL5000EG | VIA CN400 + VT8237 | Windows XP Pro SP3
Damit zeigt sich, daß Esther mit 231½ Stunden bei 400MHz mit neueren SSE Einheiten zwar die Nase vorn hat, bei der Standardversion des Benchmarks aber gar nicht Mal um so viel. Die Rekordjagd muß ich jedoch leider abbrechen, Luke erlaubt es mir einfach nicht, den Takt noch weiter zu drücken, egal was ich versuche. Leider lassen sich keine Multiplikatoren ändern, um die Bustakte oben zu halten.
Edit: Und den gestörten Wahnsinn mit deaktivierten L1/L2 Caches (wo sogar notepad.exe bei der Texteingabe ruckt) mache ich derweil erst Mal noch nicht.
-
Sehr schönes Ergebnis. Echt geil!
-
Hier also das Ergebnis zur "China-CPU"
02:21:10.070 | Löschzwerg | 1/8/8 | Zhaoxin KX-U6780A @ 2.70GHz | CJOYIN C1888 | 2x 8GB DDR4-2400 CL18-15-17-39-2T | Windows 10 Pro x64 1909
-
Ist drin!
Ich beiße mir in den Arsch. Werde meinen Import wohl zugunsten eines KX-7000 abbrechen müssen. Hah...
Ajo! Du hast 16GiB RAM... Darf man auf einen x265 Benchmark Run hoffen?
-