Jetzt wo der Servermüllhaufen wieder so was ähnliches wie funktioniert habe ich die ausstehenden Ergebnisse gerade nachgetragen, waren ja eh nur zwei! 
x264 Benchmark (kein Schnelldurchgang! 32-Bit multicore und ≥1GB RAM)
-
Dann direkt mal weiter....
00:33:05.132| undertaker_2 | 1/6/12 +8 E Cores | Intel i5 14500 | 16 GiB DDR5-5600MHz 50-45-45-90-135 | Dell 0W74D (Optiplex 7020MT) | Windows 11 Pro
-
Und ist drin!
-
00:30:06.894 | RaVeNsClaw | 1/24/48 | AMD EPYC 7402P 2.80GHz | 512GB DDR4/2666 19-19-19-43 | TYAN S8030GM4NE-2T | Windows 11 Professional 24H2
-
00:30:06.894 | RaVeNsClaw | 1/24/48 | AMD EPYC 7402P 2.80GHz
Hmmm.. das hätte ich mir jetzt aber deutlich flotter vorgestellt.
Arbeiten hier nur eine gewisse Anzahl Kerne/Threads mit, oder liegt es an dem recht niedrigen Takt, oder an beidem?
(Frage auch an GrandAdmiralThrawn)
-
Boost ist limitiert auf 3,35 GHz bei der ZEN2 CPU. Und die Skalierung mit den Kernen wird hier nicht besonders gut sein.
Zumindest ist er schneller als meine Intel Kiste mit 80 Threads.
-
Der x264 Benchmark - das wurde schon mehrfach erwähnt, aber das geht halt logischerweise immer im Thread unter - ist nicht für Many-Core CPUs geeignet. Außer man will explizit messen wie stark die Skalierung in solchen Szenarien einbricht. Dementsprechend habe ich auch die Threadtitel der x264 und x265 Benchmarks angepaßt (multicore und manycore). Jetzt kann man natürlich drüber streiten, wo "manycore" anfängt, aber ich definierte die Bruchlinie so um die 32 logische CPUs. Also RaVeNsClaw's Prozessor wäre meiner Definition schon in dem Sektor unterwegs, weil gut mehr als 32 logische CPUs.
Man muß aber auch dazusagen, daß dank des Kernwahns seitens AMD - der mit dem Threadripper begonnen hatte - mittlerweile auch der x265 Benchmark skalierungstechnisch am Ende ist. Das ging viel schneller als ich erwartet hatte. Auch konnte ich die echte Skalierung vom x265er mangels entsprechend extremer Systeme vorab nicht belegen. Ich konnte nur theoretisch vermuten. Tests mit 96 und 128 logischen CPUs pro System belegen aber, daß so um die 70-90 das Ende der Skalierung auch für diesen Test beginnt.
Aber hey, jetzt gibt's ja sogar den x265er bald 10 Jahre!
Und den x264er seit 15 Jahren, heiiilige Scheiße...RaVeNsClaw: Ergebnis ist drin! Dein Board habe ich als "Tyan Tomcat SX S8030" eingetragen, das ist scheint's der offizielle Produktname, wohingegen "S8030GM4NE-2T" die SKU darstellt. Ich bevorzuge hier die menschenlesbareren Produktbezeichner.
Edit (Kopie aus'm x265 Benchmark Thread): Ich habe deinen RAM als "Reg. ECC" eingetragen, weil deine Speichermenge das nahelegt. Solltest du einen anderen Speichertyp haben, einfach sagen. Aber ich denke die Plattform kann eh noch keine LRDIMMs, also wird's wohl Reg. ECC sein.
-
wohingegen "S8030GM4NE-2T" die SKU darstellt. Ich bevorzuge hier die menschenlesbareren Produktbezeichner
Ich weiß gar nicht, was Du hast! Esachtzigdreißiggemviernestrichzweit ist doch eingängig
-
-
37:01:06.094 | gtxe | 2/1/1 | Intel Pentium III 866 MHz | Tyan Tiger 133 | VIA VT82C694X (Apollo Pro 133A) | 1.5 GiB PC133 Reg. ECC SDRAM 3-2-2-6 | Windows 2000 Pro SP4
-
Aktuell Platz 1343. Du bist somit als "schmerzresistent" zertifiziert!
-
Denke der Beiname passt
Das System lauffähig und stabil zu bekommen hat mindestens genau soviel Zeit in Anspruch genommen wie der Belastungstest
War auch irgendwo für mich ein Beweis daß jetzt gut ist.Hätte sonst noch das 2xPPro System das eine "noch höhere" Platzierung bekommen könnte. Aber da will ich den Rechner nicht durch quälen
-
Sehr gut das es rennt! GEZ!
Und jetzt musst du liefern!
-
37:01:06.094 | gtxe | 2/1/1 | Intel Pentium III 866 MHz | Tyan Tiger 133 | VIA VT82C694X (Apollo Pro 133A) | 1.5 GiB PC133 Reg. ECC SDRAM 3-2-2-6 | Windows 2000 Pro SP4
Nettes Sytem
Es gibt übringens einen SMP Patch, der angeblich für viele Spiele funktionieren soll.
Infos gibt es diesbezüglich dazu hier.
We found a dual Cpu patch (SMP) that works on old games. \ VOGONS
Evtl. etwas für dich?
Eine Bestätigung dessen wäre natürlich ein extremer Mehrwert.
-
Ja danke. Werde das System noch vorstellen.
Der Patch klingt auf jeden Fall interessant, scheint sogar universal für OpenGL zu sein?!
Bin jetzt aber erstmal für eine Woche wech
danach geht's weiter. -
So, damit die Liste nicht einschläft hier mein Schlepptop:
0000:33:49.746 | Umlüx | 1/12/24 | AMD Ryzen AI 9 HX PRO 370 2GHz | Lenovo Thinkpad P14s Gen6 | 64GB DDR5/5600 22-16-16-32-48 | Windows 11 Pro 24H2
0000:16:25.877 | Umlüx | 1/12/24 | AMD Ryzen AI 9 HX PRO 370 2GHz | Lenovo Thinkpad P14s Gen6 | 64GB DDR5/5600 22-16-16-32-48 | Windows 11 Pro 24H2 (Offical r3222 Build)
-
Ist drin!
gtxe: Jo, scheint ein genereller Offload des Renderers in einen eigenen Thread zu sein. Wohl vor allem mit Software T&L sinnvoll, wo die CPU noch einiges an Geometriearithmetik übernehmen muß, Dreiecke transformieren und sowas.
-
Sajuk : Diesen SMP MiniGL Layer mal mit Q3 ausprobiert, läuft echt gut.
Hier mal ein paar Ergebnisse mit dem OpenGL Treiber der beim Amigamerlin 3.1 R11 dabei ist (Auflösung / ohne SMP / mit SMP MiniGL), alles in 16bit ohne AA640x480 / 62.0 / 99.5
1024x768 / 61.7 / 97.0
1280x1024 / 60.2 / 77.6
1600x1200 / 52.4 / 54.5Mit dem Wicked3D funktioniert es auch:
640x480 / 77.9 / 116.8
1024x768 / 76.8 / 106.1
1280x1024 / 69.2 / 72.7
1600x1200 / 53.8 / 53.2Das ist schon ganz nice
Edith: Eine V5 war das, V3 will in dem Board igendwie nicht
-
Das ist doch Mal ein Statement! Vielleicht war Geometry-Offload damals doch weniger sinnlos als wir dachten... und frühes Hardware T&L auf NVIDIA Karten war einfach nur zu schlecht, um das Potential freizuschalten? 1280×1024 wäre für mich persönlich noch interessant, falls du dir das antun willst.
Nebst 1024×768 war das damals so eine favorisierte Auflösung von mir, die oft aus Leistungsgründen nicht drin war - zugegebenermaßen auch oft aufgrund von FSAA, aber trotzdem. -
Das ist ne Auflösung die nie mein Favourit war, ist kein 4:3 oder 16:9 oder 16:10
Hab ich oben ergänzt.
Der Wicked3D profitiert ab 1280x1024 nicht mehr viel.
