Jup ... Hab die Windows Platte allerdings schon zu gunsten einer ESXi Spielwiese plattgemacht bevor ich den x265 in Erinnerung bekam .. Vielleicht mach ich das auch nochmal ...
x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)
-
-
Mein neuer Billo Laptop
One K56-8F (Clevo NB50TK1)
01:35:53.882 | MasterOf486er | 1/4/4 | Intel Core i3-8350K 4Ghz) | Clevo NB50TJ1/TK1 (Intel H370) | 8 GB DDR4-2400 | Windows 10 Pro 1809 64 Bit
-
Ein i3 Quadcore in einem Notebook.
Ich wusste nicht, dass es das gibt.
-
Naja ist halt ein "Billigteil". Hab ich aber bewusst gekauft. Es hat eine Wartungsklappe und die CPU ist gesockelt, ich kann sie tauschen wenn ich will.
-
So, das neue ReactOS 0.4.10 ist herausgekommen, und das wurde ja recht groß hinausposaunt, weil es jetzt von btrfs anstatt von FAT32 booten kann, plus zig andere Verbesserungen, so meinte die [Ankündigung]. Erst Mal das Ergebnis (timethis.exe funktioniert noch immer nicht korrekt auf dem ReactOS System, man muß das Benchmarkskript also nach wie vor modifizieren, so wie [hier] angemerkt):
09:38:33.633 | GAT | 1/1/1 | Intel Core i7 980X 3.33GHz | 2GiB DDR-III/1333 CL10 | ASUS P6T Deluxe V2 | Intel X58 Tylersburg | ReactOS 0.4.10 on VBox/CentOS 6.9 Linux
Leider stellt ReactOS nach wie vor eine ernüchternde Erfahrung dar. Der Vergleich "ReactOS ist zu Windows was Linux zu UNIX ist" kann also maximal auf dem Papier stehen bleiben, weil in der Praxis ist das System nach wie vor untragbar. Immer noch funktionieren manche Sachen auf der GUI einfach nicht, die btrfs Einbindung bringt vorerst mehr schlechtes als gutes mit sich, zig Windows Programme laufen nicht korrekt (auch ältere!), und das System neigt nach wie vor zu Abstürzen.
Ganz zu schweigen davon, daß das OS meine Workloads nicht würde stemmen können; Es steckt noch immer in 32-Bit Singlecore Welten fest, und wird das wohl noch eine halbe Ewigkeit tun, so langsam wie die Entwicklung vorankriecht... Langsam beginne ich da die Hoffnung in das "quelloffene, freie Windows" zu verlieren.
ReactOS gibt es jetzt seit 20 Jahren. Von 1998 bis 2018 lief das Projekt. Und DAS ist der Zustand. In 20 Jahren (1993 - 2013) ist Linux zu einem Major Player in der Serverlandschaft und im Embedded Bereich aufgestiegen, hat eine kleine, aber stabile Userbase bei Desktops aufgebaut und die Basis für das heute weltweit verbreitetste mobile Betriebssystem gebildet. Und stürzt dabei wenigstens nur dann ab, wenn ein echter Grund vorliegt.
Irgendwas läuft da grundlegend falsch bei ReactOS.
-
Stock
0011:14:48.109 | Chosen_One | 1/4/4 | Broadcom BCM2837 (ARM Cortex-A53) @ 1.2 GHz | 1 GB LPDDR2-900 | Raspberry Pi 3 Model B Rev 1.2 | Raspbian Linux (4.14.71-v7), Custom x264 Build 0.155.x (GCC 6.3.0)
Overclocked
0009:45:11.238 | Chosen_One | 1/4/4 | Broadcom BCM2837 (ARM Cortex-A53) @ 1.4 GHz | 1 GB LPDDR2-1000 | Raspberry Pi 3 Model B Rev 1.2 | Raspbian Linux (4.14.71-v7), Custom x264 Build 0.155.x (GCC 6.3.0)Stock
0009:53:35.748 | Chosen_One | 1/4/4 | Broadcom BCM2837B0 (ARM Cortex-A53) @ 1.4 GHz | 1 GB LPDDR2-1000 | Raspberry Pi 3 Model B+ Rev. 1.3 | Raspbian Linux (4.14.71-v7), Custom x264 Build 0.155.x (GCC 6.3.0)
Overclocked0008:56:48.817 | Chosen_One | 1/4/4 | Broadcom BCM2837B0 (ARM Cortex-A53) @ 1.6 GHz | 1 GB LPDDR2-1000 | Raspberry Pi 3 Model B+ Rev. 1.3 | Raspbian Linux (4.14.71-v7), Custom x264 Build 0.155.x (GCC 6.3.0)
-
Alles drin!
-
Teaser
-
das ist doch einmal ein ungewöhnliches Bild, wie eine Armbanduhr am Big Ben.
-
Himmel hilf! Was geht denn da ab?
Da bin ich Mal gespannt, ob der Wahnsinn was bringt! Der Kompressor spürt den sanften Hauch von Abwärme von der Platine wahrscheinlich so gut wie gar nicht.
-
Das ist mehr als durchgeknallt, aber geil
-
Leider haben die RPi 3 einen lock bei 1600 MHz. Der 3 B+ erreicht die 1600 MHz unter Luft und ist benchable. Der 3 B kann mit 1600 MHz booten, ist aber leider nicht stabil unter dem x264-Benchmark.
Beide booten aber nicht mit 1601 MHz.
Subzero bringt beim 3 B zumindest etwas. Der Aufwand steht aber in keinem Verhältnis zum Nutzen
Ich erwarte in den frühen Morgenstunden das Ergebnis.
Demnächst wird es auch eine Runde ARMv6 RPi-Durchläufe geben. Hier dauert ein Benchmark aber ca. 14 Tage, das wird dann ohne Kompressorkühlung stattfinden.
-
0008:55:15.647 | Chosen_One | 1/4/4 | Broadcom BCM2837 (ARM Cortex-A53) @ 1.55 GHz | 1 GB LPDDR2-1000 | Raspberry Pi 3 Model B Rev. 1.2 | Raspbian Linux (4.14.79-v7), Custom x264 Build 0.155.x (GCC 6.3.0)
+150 MHz hat die Sache gebracht.
Hab damit den den 1.6 GHz RPI 3 B+ überholt
Anm.: x264 wurde neu gebaut und es gab auch einen neuen Linux-Kernel zwischen den beiden Tests.
-
Du musst damit das Odroid-XU4 kriegen
Das ist aber noch doppelt so schnell
-
Irre... die eingegossene Platine und alles..
btw., hat der BCM2837 irgendwie eine höhere IPC als der (neuere?) BCM2837B0? Schaut ja fast danach aus. Bei gleichem Takt (das OC auf 1.4GHz) war ja auch der BCM2837 schneller.
-
Über das kleine Lötkunstwerk wurden auch 1.8V direkt an den CPU VCore gelegt. Ausgelesen hat er aber leider immer nur noch 1.4V, von daher weiß ich nicht, ob der VMod geklappt hat.
Er hat aber dazu geführt, dass das kabelgebundene Netzwerk und alle USB-Ports ausgestiegen sind. USB+Eth werden von einem Chip geregelt, zum Glück gibt es ja noch WLAN+BT auf einem anderen Chip.
Einen Versuch wird es noch geben. Eine Möglichkeit der minimalinvasiven VCore-Manipulation gibt es noch über die Veränderung des Spannungsteilers, der für den VCore zuständig ist. Dazu fehlen mir gerade aber passende Widerstände und ich brauche da ggf. einen weiteren RPi für.
Ich werde bald einen Gegentest mit einem RPi 3 B+ mit identischen Takt und x264-Build machen. Beim Test mit 1.4 GHz waren die Ergebnisse aber vergleichbar. Gleicher x264-Build und die Takte waren auch identisch.
-
Der Vergleichsdurchgang mit gleicher Software
0008:58:02.587 | Chosen_One | 1/4/4 | Broadcom BCM2837B0 (ARM Cortex-A53) @ 1.55 GHz | 1 GB LPDDR2-1000 | Raspberry Pi 3 Model B+ Rev. 1.3 | Raspbian Linux (4.14.79-v7), Custom x264 Build 0.155.x (GCC 6.3.0)
Der RPi 3 B ist damit 3 Minuten schneller. Das sind bei der Laufzeit 0,5% Unterschied. Ist der Benchmark so genau? Für mich wäre das identisch im Sinne der Messungenauigkeit.
Beim Vergleich mit 1.4 GHz beträgt der Unterschied 1,4% über die Laufzeit.
-
Es gibt schon Varianzen, aber die bewegen sich üblicherweise (wenn ich das richtig im Kopf habe) unter'm 1%-Bereich. 1.4% sind daher schon fast etwas viel für Zufall bzw. Meßungenauigkeiten, denke ich. Aber um die Varianzen auf der Plattform zu ermitteln, müßtest mehrere Runs auf der selben Box durchführen. Das ist wohl ein wenig mühsam...
-
Mehrere Durchläufe mit Kompressorkühlung sind in der Tat etwas aufwendig.
Aktuell laufen noch zwei Benchmarks mit den ARMv6. In ca. 2 Wochen gibt es Ergebnisse
-
Krankes Setup
Die 2 Wochen sind ja jetz auch bald um, läuft der Test noch?
Mal wieder ein VIA Ergebnis:
91:18:57.401 | xxx | 666psycho | 1/1/1 | VIA C3 Nehemiah 1,33GHz | VIA EPIA SP | VIA CN400 | 1GB DDR/400 2,5-3-3-8 | Windows 2000 Pro SP4
Und ein paar CPU-Z Screens dazu
@GAT
Bei deiner Suche-Funktion in der Liste ist das Feld "Speicher" wohl nicht berücksichtigt? Wollte eben mal alle "RDRAM" oder "SDRAM" oder "DDR-I" filtern, gab aber keine Treffer.
-