Ist schon ok. Diese Angabe war augenscheinlich unglücklich gewählt, weil da haben sich schon viele Leute vertan. Daher muß es wohl unintuitiv sein. Aber nach all der Zeit stell' ich das auch nicht mehr um, zuviel Arbeit.
x265 Benchmark (kein Schnelldurchgang! 64-Bit manycore und ≥12GB RAM)
-
-
Windows 10 war tatsächlich messbar schneller?
-
Windows 10 war tatsächlich messbar schneller?
kann auch daran liegen das ich bei Windows 10 keine Vollbestückung der RAM Bänke machen konnte.
Dann Taktet aber der RAM höher...
Bei Windows 7 kann ich vollbestücken (was ich gerne tue)...
Der Test war auch um zu sehen ob es jetzt endlich Stabil läuft. Da ich ja die ganze Hardware verkaufen will.
Und damit ist der beweis erbracht: Windows 10 ist kacke und instabil bei solcher Server Hardware
-
Musste mal mein Linux neu installieren:
04:08:34.000 | xxx | 666psycho | 1/6/12 | Intel Core i5 11600KF | 32GB DDR-IV/2933 14-14-14-34 | Gigabyte H470 HD3 | H470 | Debian 11 (Bullseye RC2)
-
Wir müssen über ARM64-Kompatibilität unter Windows reden
...oder über eine Batch-Datei, die einfach losläuft.
-
Sowas ist bei Linux und UNIX halt ungleich einfacher, weil sowieso (fast) alles von Quellcode gebaut wird. Also beim Endbenutzer, auf dessen eigener Hardware.
Unter Windows ist das alles Arsch. Hat ja kein normales Win10 eine Compiler Toolchain mit drauf. Ich weiß auch (noch) nicht Mal wie man mit dem VS2017 und cmake3 zu ARM64 cross-compiled. Zudem kann ich mich darum aktuell nicht kümmern, wie [etwas weiter oben] angekündigt. Ab Ende nächster Woche werde ich erst Mal für eine Weile nicht zur Verfügung stehen können (für eine noch nicht ganz genau definierte Zeitperiode). Das betrifft sowohl Ergebniseintragungen wie auch Softwarespielereien und den ganzen Rest.
Ich lade aber natürlich gerne dazu ein, es einfach selber zu probieren! git + mercurial + Visual Studio 2017 oder neuer + cmake 3.x + nasm 2.13.02 oder neuer brauchst, so irgendwas um den Dreh.
-
Hat alles Zeit.
-
Ich meine... du könntest dir ja... also Lizenzen vorausgesetzt, da könntest du dir ja den Stack Mal installieren und herumprobieren. Also he, ich meine... Ich bin kein Gegner von Contribs bei Software! Das wäre ja unmoralisch! Nein nein, ich heiße sowas durchwegs willkommen, ich bin da voll tolerant und offen und so, wenn jemand etwas beitragen möchte!
-
Kompilieren unter Windows? Das kombiniert mit meiner Person?
Ich umschreibe das mal mit "Jugend forscht" oder "wie ein Schwein ins Uhrwerk schauen"
-
Hat ja kein normales Win10 eine Compiler Toolchain mit drauf
Muesstest du unter Linux eine toolchain fuer Windows benutzen, wohl mit MingW. Aber dann kannst warscheinlich auch MingW unter Windows benutzen um fuer einen Arm64 zu bauen. ODer halt eine Toolchain fuer Linux wieder die fuer Windows arm baut. Das wird wohl etwas dauern
-
Blöd is nur: Ich baue x265 mit den vorgefertigten Solution Files für Microsoft Visual Studio. Dazu cmake, git/hg und Sachen wie NASM, die halt mit eingebunden sind. MinGW als Compiler ist für x265 nach wie vor nicht unterstützt, und der Bau damit ist wohl recht problematisch. Im Krosskompilat noch schlimmer.
Also: Ich baue unter Windows für Windows. Bei allen anderen Plattformen gibt es nur Buildskript + Source und alle Verantwortung zur Systempräparation wird dem Nutzer zugeschoben (mit etwas Unterstützung vom Skript).
Lediglich weitere Komponenten wie das chopped ffmpeg oder Mediainfo werden auch für Windows mit GCC gebaut (soweit ich mich jetzt richtig erinnere).
Aber: Ich würde es generell gut finden, wenn jemand die Zeit finden könnte das ganze Mal nachzustellen und ggf. weiterzuentwickeln. Wobei wohl nicht alles hinreichend in der README.txt dokumentiert sein wird, hm.
-
10:04:29.533 | Maniac81 | 1/4/8 | AMD Ryzen 5 3400G | Gigabyte AB350M-DS3H-CF | AMD X370 | 32GB DDR-IV/3200 16-18-18-36 | Windows 11 21H2 Build 22000.100
Die Windows Version liest er falsch aus.
-
Hier ein neues Ergebnis von meinem DeskMini A300 der auf das BIOS vom X300 geflasht wurden ist.
AMD Ryzen 7 5700G
03:46:24.146 | BillytheKitt | 1/8/16 | AMD Ryzen 7 5700G Stock (PBO auf AUTO) | 16GiB Crucial Ballistix SO-DDR4 3200 MHz CL16 18 18 38 1T | AsRock Deskmini A300 zum X300 geflasht | Chipsatz hat der DeskMini gar nicht oder? |Windows 10 Pro Build 19043 21H2
-
BillytheKitt : Chipsätze werden über kurz oder lang wohl ganz verschwinden und SoCs weichen. Dein Deskmini hat eine AMD Carrizo FCH als "Southbridge", sitzt aber glaube ich auch schon in der CPU. Da beißen sich die Realität und die Abbildung in der Ergebnisliste schon etwas.
Maniac81 : Hat Windows 11 überhaupt schon Releasenummern à la 21H2? Weil das is ja alles noch Preview, oder? Ich hab's jetzt Mal nur mit der Buildnummer eingetragen. Dein Mainboard ist auch witzig, hat eine B350 Bezeichnung, aber einen X370 drauf. Als hätte sich im letzten Moment noch jemand gedacht "Uh nein, wir löten doch die größere Bridge drauf!".
Zum Falsch Auslesen: Ja, teilweise. Das Caption ("Windows 11 Pro") liest er scheints richtig aus, nur die "Windows Version" "Description" ist Blödsinn. Die CPU-Z Komponente des Tests gehörte längst schon aktualisiert. Momentan habe ich dazu aber keinen Geist. Vielleicht nächstes Jahr.
-
-
Ok, alles klar. Dann schreibe ich das dazu, auch das "Pro".
-
In einem Anflug entarteten Wahns ebenfalls auf Win11 Pro upgraded, war einen Tick schneller als das 10er:
04:02:51.150 | GAT | 1/6/12 | AMD Ryzen 5 5600X (w. PBO) 3.70GHz | 16GiB DDR4/3200 18-21-21-39-1T | Biostar X470GTN | AMD X470 Promontory | Windows 11 Pro 21H1
PS.: Ich arbeite grade an einer neuen Version des Benchmarks, paar Bugfixes, ein neueres CPU-Z für bessere Erkennung moderner Systeme im Reporting und eine Modifikation des x265 Quellcodes für mehr Zukunftssicherheit und Plattformkompatibilität. Dauert aber noch etwas.
-
So, es steht eine neue Version 0.4.0 in Patchlevel 0 des x265 Benchmarks zur Verfügung. Sowohl die Version für UNIX-artige Systeme wie auch die für Windows wurde aktualisiert.
Die wichtigsten Änderungen schreibe ich auch hier her, im zweiten Beitrag im Thread stehen dann mehr Details:
- Alle Systeme: CPU Adressierung in x265 von 64 auf 256 CPUs verbreitert, so wie es auch in modernen Betriebssystemkernen üblich ist. Damit gehen also bis zu 256 logische CPUs pro NUMA Knoten bzw. bis zu 256 pro System, wenn eine flache Bustopologie ohne NUMA vorliegt. Das ist speziell im Hinblick auf moderne CPUs mit sehr vielen Kernen und Threads sinnvoll. Profitieren können hier auch moderne UNICES oder UNIX-nahe Systeme ohne eine von x265 unterstützte NUMA Bibliothek: Zum Beispiel Solaris, FreeBSD, macOS, etc.
Achtung aber: Das verwandelt Betriebssystemkerne die von sich aus nie mehr als 64 CPUs können nicht magisch in solche wo das geht. Das 64-CPU-Limit bleibt also bestehen, wenn man z.B. XP x64, Server 2003 x64 oder sowas wie Linux 2.4 oder FreeBSD 9.x betreibt. - Windows: Neues CPU-Z integriert! Damit werden moderne Plattformen und CPUs endlich besser unterstützt, und das Reporting in RESULTS.txt hat wieder Speicherlatenzen usw. drin, wo das vorher nicht mehr so geklappt hat.
- Windows: Microsoft TimeThis.exe wurde durch [Jem Berkes'] ptime.exe ersetzt. Dies behebt zwei Fehler: 1.: Keine Überläufe mehr bei sehr langsamen Maschinen die gut über 600 Stunden für einen Test brauchen. 2.: Keine Ergebnisverfälschung, wenn die Systemuhr z.B. wegen Sommer-/Winterzeit um eine Stunde umstellt während der Test läuft. Auch ein manuelles Ändern der Systemzeit hat jetzt keine verfälschenden Auswirkungen mehr.
- Windows: Unterstützung von Windows 11.
Leider habe ich bis dato trotz mehrerer Anfragen keine Antwort von Mr. Berkes erhalten, was eine Redistributionsbewilligung für seine Freeware angeht. Ich habe es jahrelang versucht, aber jetzt reicht es mir, und ich verteile das Programm einfach mit. Scheint sich um Abandonware zu handeln, um die sich Mr. Berkes auch administrativ nicht länger kümmern möchte.
Die schnellen Downloadmirror von Blacktron und RayVIP sind noch nicht aktualisiert, momentan gibt's also nur Schneckendownload.
- Alle Systeme: CPU Adressierung in x265 von 64 auf 256 CPUs verbreitert, so wie es auch in modernen Betriebssystemkernen üblich ist. Damit gehen also bis zu 256 logische CPUs pro NUMA Knoten bzw. bis zu 256 pro System, wenn eine flache Bustopologie ohne NUMA vorliegt. Das ist speziell im Hinblick auf moderne CPUs mit sehr vielen Kernen und Threads sinnvoll. Profitieren können hier auch moderne UNICES oder UNIX-nahe Systeme ohne eine von x265 unterstützte NUMA Bibliothek: Zum Beispiel Solaris, FreeBSD, macOS, etc.
-
Hi Leute,
die Dateien sind nun hochgeladen und sollten bald in ordentlicher Geschwindigkeit zur Verfügung stehen
MfG Ray
-
Die Firma dankt! Links hier in Beitrag 1 des Threads und auf den Benchmarklisten sind hinzugefügt!
-