x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)

undertaker_2 · August 20, 2024 at 7:04 PM

Eine weitere Höllenmaschine.

GrandAdmiralThrawn · August 20, 2024 at 11:22 PM

Aalles klar, hab' die Rakete Mal eingetragen!

undertaker_2 · August 21, 2024 at 8:43 PM

Jetzt mal etwas flotteres:

@GAT

In wie fern hat die Speichermenge über 4GB eigentlich mit dem Gesamtergebnis zu tun?

Die gleiche Frage auch mit der Speichertaktung.

Wirklich große Unterschiede kann ich so nicht feststellen.

GrandAdmiralThrawn · August 22, 2024 at 1:57 AM

Da hast du Recht. das ist so. x264 bei 1080p Eingabedaten (so wie hier) mit einem Riesenhaufen an RAM zu bewerfen bringt gar nichts, außer andere, speicherhungrige Software läuft gleichzeitig. Zudem ist x264 (wie auch x265) primär von der CPU-Leistung und vorhandenen Befehlssatzerweiterungen (SSE, SSE2, usw.) abhängig. Die I/O Leistung (Disk, Systembus, RAM) ist nebensächlich. So ist sogar Swapping für x264 nicht annähernd so schlimm wie für andere Software. Es braucht zwar einiges an RAM, liest und schreibt aber nur wenig pro Zeiteinheit, weil die CPU so enorm viel Arbeit dabei hat. Er muß also salopp gesagt viel mehr rechnen als Daten herumschaufeln.

Die beiden arbeiten auch mit nur 8 Bit oder 16 Bit breiten Operanden, je nachdem welche Farbtiefe die Farbkanäle des Eingabevideos haben. Beim x264 Benchmark sind es standardmäßig 8 Bit pro Farbkanal. Da nur geringe Datenmengen auf einmal bearbeitet werden, paßt das meiste in den Cache der CPU. Somit hat die Speichergeschwindigkeit schon einen gewissen Einfluß, aber keinen besonders signifikanten.

Was auch ginge wären 10 Bit oder bei x265 sogar 12 Bit "Deep Color", das vor allem für HDR genutzt wird, aber auch für SDR gewisse Vorteile bringt (weniger signifikante Rundungsfehler). Da CPUs keine 10 oder 12 Bit breiten Operationen oder Operanden verstehen, wird hier mit 16 Bit gearbeitet. Die überflüssigen Bits werden einfach mit 0 gefüllt. Das ist einen Tick langsamer und belegt mehr Ressourcen. Aber selbst hier bringt Speichertakt so gut wie nichts extra, weil die jeweils gerade aktiv bearbeiteten Datenmengen trotz allem immer noch winzig sind und die Recheneinheiten jetzt einen Tick länger pro Datenblock brauchen, also weniger oft neue Daten vom/zum RAM gelesen und geschrieben werden müssen.

Was man auch noch sagen kann, nur so als Zusatzinfo: Die beiden Tests fressen zwar gewisse SIMD Befehlssatzerweiterungen zum Frühstück, lassen die FPU aber links liegen. Die Fließkommaeinheiten sind nahezu das einzige, was diese beiden Benchmarks bei einer CPU nicht belasten; Es handelt sich also um reine Integerlast.

Ergebnis ist drin!

undertaker_2 · August 22, 2024 at 11:07 PM

Übrigens für deine ausführliche Antwort danke ich dir. Bin jetzt allerdings zu müde um drauf zu reagieren.

In diesem Sinne: Gute Nacht!

undertaker_2 · August 23, 2024 at 7:16 PM

GrandAdmiralThrawn · August 26, 2024 at 8:33 AM

Morgen,

Der A8-6500 ist drin, der A8-7600 aber nicht. Da muß irgendwo ein Tippfehler oder ein Copy & Paste Fehler passiert sein. Eine Laufzeit von 3 Minuten, 8 Sekunden und 872 Millisekunden macht eher nur begrenzt Sinn für die CPU. Da hast du scheinbar die Stunden irgendwie abgeschnitten.

Vielleicht hast du das Ergebnis noch zum Nachreichen herumliegen?

undertaker_2 · August 26, 2024 at 2:50 PM

Quote from GrandAdmiralThrawn

Eine Laufzeit von 3 Minuten, 8 Sekunden und 872 Millisekunden

Aargh!

Okay.

Mach das Teil noch mal an.

undertaker_2 · August 26, 2024 at 8:54 PM

So.... ist erledigt!

Diesmal anderes Board + anderen Speicher.

GrandAdmiralThrawn · August 27, 2024 at 8:06 AM

Alles klar, danke! Ergebnis ist drin.

undertaker_2 · August 27, 2024 at 6:05 PM

So... weiter geht's mit FM2(+)

GrandAdmiralThrawn · August 28, 2024 at 3:08 AM

Du hast dir da ja eine ordentliche AMD Restmüllhalde angehäuft? Wenn du so weitermachst stemmst du bald die Hälfte aller AMD A88X Ergebnisse. Dieses hier ist Mal eingetragen!

undertaker_2 · August 29, 2024 at 10:20 PM

Also der A10-7700K will mich offensichtlich flachsen, - oder das verwendete Board mag ihn nicht. Das Gigabyte F2A88XM-D2 läuft (für mich überraschend) stabil und muckt nicht rum. Das Gigabyte F2AA88XM-D3H läuft (wie ich Gigabyte seit jeher kenne) wie eine Zicke, es startet wenn man aus dem Bios/Uefi kommt, oder auch nicht - ganz wie es ihm beliebt. Jedenfalls läuft der AMD A10 7700K mit 3,4GHz und 1866er Speicher auf dem D2 langsamer als mit 3,2GHz und 1333er Speicher als auf dem D3H. Und das nicht nur marginal - Nö, es geht um gute 15 min.

Gut, GAT sprach ja schon das Speicher Timings eine eher untergeordnete Rolle spielen, aber 200MHz mehr Takt? Das sollte doch flotter und nicht langsamer werden.

Die Tage werde ich mir nochmal das EXCEED ZX-A88M2+ und das Gigabyte F2AA88XM-D3H zur Brust nehmen und dies nochmals nachstellen.

vs.

@GAT die Ergebnisse in Schwarz bitte nicht eintragen - die sind schon drinne. Den anderen aber bitte sehr wohl, Danke!

(Nebenbei @GAT JETZT, nach diesem Eintrag, habe ich 50% der A88 Ergebnisse.

undertaker_2 · August 30, 2024 at 2:30 AM

Nochmal etwas langweiligeres:

GrandAdmiralThrawn · August 30, 2024 at 10:41 AM

Ergebnisse sind drin! Danke für die Anmerkungen, ich habe für das Ergebnis auf'm F2A88XM-D2 einen "pp." Link zu deinem Beitrag dazugegeben, falls das Mal jemandem komisch vorkommen sollte. Ich kann hier auch nur mit den Schultern zucken. Vielleicht verhält sich der Turbo auf dem Brett anders? Oder Gigabyte hat einfach irgendwas verpfuscht, was ja schon Mal vorkommt bei denen.

Bier.jpg · August 31, 2024 at 4:19 PM

Hier war der Turbo meist auf 3.6 GHz

Transformer · September 20, 2024 at 6:56 PM

Guten Tag

Um mich für die Unterstüzung bei der Auswahl des Encodingrechners zu bedanken, hier ein kleiner Anhaltspunkt zum Comet Lake.
Die Ergebnisse sind sehr! unter Vorbehalt! einzuordnen, denn:
1. sind die Source-Links auf Deiner XIN-Seite zu x264 und libav deprecated (de=veraltet/sprich 'führen in eine Sackgasse')
daher habe ich Mangels Laune und Zeit nicht lange herumgesucht, sondern die bereits instalierten Versionen benutzt.
2. spiegeln die Ergebnisse eher die Eigenschaften des Gerätes wider, weniger die der Leistungsfähigkeit des i5 (siehe hier)
3. lief noch eine mehrere TB HDD-Analyse nebenbei, die ca. 5-8% CPU-Last verursachte. Die wollte und konnte ich nicht mittendrin beenden, pausieren geht nicht.

elephants Dream Benchmark
========================================================
$ x264 --version
x264 0.164.3095 baee400
(libswscale 6.7.100)
(libavformat 59.27.100)
(ffmpegsource 3.0.1.0)
built on Apr 12 2023, gcc: 12.2.0
x264 configuration: --chroma-format=all
libx264 configuration: --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Code

$ time ./launchbenchmark.sh 
ffms [info]: 1920x1080p 1:1 @ 24/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile High, level 4.0, 4:2:0, 8-bit
x264 [info]: frame I:103   Avg QP: 9.74  size:332459                           
x264 [info]: frame P:4611  Avg QP:13.80  size: 90216
x264 [info]: frame B:10977 Avg QP:17.03  size: 29260
x264 [info]: consecutive B-frames:  6.3%  4.7% 11.0% 59.1%  5.5%  3.9%  1.9%  5.1%  2.5%
x264 [info]: mb I  I16..4: 26.8% 39.1% 34.1%
x264 [info]: mb P  I16..4:  4.3% 19.0%  4.0%  P16..4: 26.9% 13.3%  9.1%  1.1%  0.8%    skip:21.5%
x264 [info]: mb B  I16..4:  0.5%  2.3%  0.5%  B16..8: 32.1% 10.1%  3.1%  direct: 5.0%  skip:46.4%  L0:44.0% L1:42.4% BI:13.7%
x264 [info]: final ratefactor: 14.26
x264 [info]: 8x8 transform intra:67.9% inter:42.5%
x264 [info]: direct mvs  spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra: 73.4% 56.8% 36.1% inter: 16.9% 11.2% 2.4%
x264 [info]: i16 v,h,dc,p: 34% 11% 12% 44%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 11% 21%  7%  8%  9%  8% 10% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 10%  8%  9% 13% 13% 11% 11% 11%
x264 [info]: i8c dc,h,v,p: 57% 17% 16% 10%
x264 [info]: Weighted P-Frames: Y:7.0% UV:4.1%
x264 [info]: ref P L0: 65.2%  8.5% 12.4% 13.5%  0.4%
x264 [info]: ref B L0: 83.4% 12.6%  4.0%
x264 [info]: ref B L1: 94.6%  5.4%
x264 [info]: kb/s:9439.26
encoded 15691 frames, 6.62 fps, 9439.26 kb/s
ffms [info]: 1920x1080p 1:1 @ 24/1 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x264 [info]: profile High, level 4.0, 4:2:0, 8-bit
x264 [info]: frame I:103   Avg QP:10.01  size:324353                           
x264 [info]: frame P:4611  Avg QP:13.73  size: 97738
x264 [info]: frame B:10977 Avg QP:17.23  size: 30503
x264 [info]: consecutive B-frames:  6.3%  4.7% 11.0% 59.1%  5.5%  3.9%  1.9%  5.1%  2.5%
x264 [info]: mb I  I16..4: 24.6% 40.6% 34.8%
x264 [info]: mb P  I16..4:  4.1% 20.2%  4.5%  P16..4: 24.5% 13.4%  9.8%  1.4%  1.0%    skip:21.2%
x264 [info]: mb B  I16..4:  0.4%  2.6%  0.6%  B16..8: 32.0% 11.0%  3.2%  direct: 5.2%  skip:45.0%  L0:44.0% L1:41.4% BI:14.7%
x264 [info]: 8x8 transform intra:68.7% inter:41.9%
x264 [info]: direct mvs  spatial:98.2% temporal:1.8%
x264 [info]: coded y,uvDC,uvAC intra: 75.6% 58.1% 38.1% inter: 17.6% 11.7% 2.7%
x264 [info]: i16 v,h,dc,p: 34% 10% 10% 46%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 11% 21%  7%  8%  9%  8% 10% 10%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 10%  8%  9% 13% 13% 11% 11% 11%
x264 [info]: i8c dc,h,v,p: 57% 17% 16% 10%
x264 [info]: Weighted P-Frames: Y:7.0% UV:4.1%
x264 [info]: ref P L0: 71.3%  7.3% 14.2%  6.8%  0.3%
x264 [info]: ref B L0: 82.9% 15.0%  2.0%
x264 [info]: ref B L1: 94.7%  5.3%
x264 [info]: kb/s:10020.37

Display More

encoded 15691 frames, 7.25 fps, 10020.37 kb/s

real 75m36,844s
user 518m58,841s
sys 2m21,672s

Ich weiß nicht wieso das AMD64 bei dem Intel auftaucht, läuft so jedenfalls ganz gut.

Conclusion:
-----------
Das Ganze könnte noch ca. 1/3 schneller ablaufen, wäre der i5 nicht in dieses enge Gehäuse mit einer wirklich lausigen Alu!-Kühlung gezwängt!
Über einen Umbau auf Kupferkühler habe ich bereits nachgedacht aber wegen des hohen Aufwandes und vermutlich geringem Nutzens wieder verworfen.
Die CPU läuft jedenfalls anstatt mit den vollen 4200MHz unter Vollast immer gethrottled im Schnitt auf nur 2,3-2,4GHZ (habe ich öfter nebenbei beobachtet).

Geschätzt könnte der Durchgang pass1 & pass2 rein rechnerisch in ca. 50-55 Minuten durchgelaufen sein. Ich werde das nochmals während des Winters bei Minusgraden ohne Nebenlast im kalten Keller oder im Schuppen starten - zum Vergleich, weil mich die erzielbaren Werte auch selbst in höchstem Maße interessieren.

Videoencoding war sicherlich niemals für dieses Gerät jemals seit der Entwicklung vorgesehen, aber mit besserer Kühlung wäre es durchweg machbar.
Gut, Encoding auf einem Office/Internet Notebook ist nicht das gelbe vom Ei. Da ich das gute und an sich handliche, flotte Gerät trotz noch ca. 1,25 Jahren Gewährleistung+Garantie nicht mit encodieren darniederreiten möchte ist nun die angesprochene Neuanschaffung in Planung, siehe dort im Thema. (Link)

Lotosdrache · September 20, 2024 at 8:29 PM

Quote from Transformer

Ich weiß nicht wieso das AMD64 bei dem Intel auftaucht, läuft so jedenfalls ganz gut.

Weil die 64-Bit Erweiterung der Intel x86-Architektur nicht von Intel, sondern von AMD entwickelt wurde. Intel hat seine Kunden zu jener Zeit am langen Arm des stromfressenden Pentium 4 verhungern lassen, den AMD mit 64-bit ausgerenkt hat. Intel blieb nichts anderes übrig als nachzuziehen, natürlich mit einem eigenen Blablabla-Markennamen (Patentaustauschabkommen).

CryptonNite · September 21, 2024 at 7:07 AM

Es gibt auch von Intel eine 64-Bit-Architektur (IA64). Die kam beim Itanium zum Einsatz. Sie ist auch älter als die AMD'sche Lösung. Da sich beide Hersteller gegenseitig die Patente zuschieben (das ist mehrfach so geschehen), hat sich die Variante von AMD wegen einfacherer Implementierung und ein paar weiteren Vorteilen durchgesetzt.

Lotosdrache · September 21, 2024 at 10:34 AM

Quote from CryptonNite

Es gibt auch von Intel eine 64-Bit-Architektur (IA64). Die kam beim Itanium zum Einsatz.

Nur ist diese zur x86-Architektur inkompatibel gewesen, weil Intel ein Alleinstellungsmerkmal für den Itanium gebrauchte, um die teure CPU konkurrenzlos in den Markt zu drücken. Die Softwarehersteller hätten alle Programme neu schreiben müssen, auch weil die Emulation von x86 auf Itanium zu langsam war. Das war schlicht nicht praktikabel und die Lösung von AMD einfach x86 zu x64 zu erweitern wesentlich effizienter - nicht nur aus Kostensicht:

Quote

Die gegenüber der IA-32/AMD64 durch längere Anweisungen sowie auch schwer vermeidbare NOP-Füllanweisungen wesentlich schlechtere „Instruction set efficiency“ führte dazu, dass die IA-64-Architektur in vielen Benchmarks schlechtere Ergebnisse zeigt.
(https://de.wikipedia.org/wiki/Itanium-A…atibilit%C3%A4t)