Workstation: erste Tests

Am 07.06.2023 um 16:18 schrieb Helmut Schellong:

Link zu Bildern:

Siehe 07.06.2023, 16:18

WS = Xeon 3435X, 16 Kerne, 32 CPUs, Basis 3100 MHz, 128 GB PC = 2006 E8600, 2 Kerne, 2 CPUs, 3333 MHz, 4 GB

Testwerte: (WS, PC sind Geschwindigkeiten)

tar-Archiv herstellen : WS / PC = 52 tar-Archiv verschlüsseln: WS / PC = 43 tar-Archiv hash sha3-256: WS / PC = 1,8

Bench CPU-Z: [WS/E8500] Multi-Thread: 12236/530 = 23 Single-Thread: 683/272 = 2,5 WS: AVX-512 Multi-Thread: 15666/530 = 30 Single-Thread: 808/272 = 3 WS: AVX2 Multi-Thread: 16951/530 = 32 Single-Thread: 993/272 = 3,65

Ein Riesenvorteil der WS ist ihr vergleichsweise extrem schnelles RAM. Das wird besonders deutlich beim Herstellen eines tar-Archivs. Bei der Herstellung eines Hash werden offenbar in extrem großem Anteil Instruktionen ohne MEM-Zugriff verwendet (z.B. Register), so daß das RAM seine Vorteile beim Vergleich kaum ummünzen kann. Beim Verschlüsseln ist der Anteil solcher Instruktionen viel größer als bei der Archiv-Herstellung.

Die Bench-Ergebnisse zeigen den Vorteil der Benutzung von AVX-Instruktionen. Es gibt ja den Aspekt, daß die Vorteile steiler werden, wenn Programme auf einer Plattform kompiliert und ausgeführt werden, die viele oder alle existierenden zusätzlichen Instruktions-Familien unterstützt.

Am 17.07.2023 um 16:31 schrieb Helmut Schellong:

CPU-Streßtest:

In Ruhe liegen etwa 90 W bei 800 MHz vor. Bei Streß sind es 270..320 W bei 3700 MHz. Die Lüfter haben dabei etwa 70% ihrer maximalen Drehzahl, vor Streß 45%. CPU-Temperatur konstant bei 33 Grad (auch vor dem Streß). Temperaturen maximal bei etwa 60% ihrer Alarmschwelle. CPU-Core-Spannung 1 / 0,68 V bei Streß / Idle.

Bei der Konzeption der WS habe ich offenbar alles sehr richtig gemacht.

Wenn Deine Weltsicht keine Zwischenstufe zwischen RAM und Registern kennt, solltest Du Dir mal überlegen, welche Fortschritte das CPU-Design in den letzten 30 Jahren gemacht hat.

Das kann heute jeder 200-Euro-Rechner.

Bis auf die Bedarfsbestimmung.

Ich kenne die Caches L1, L2, L3. Caches gibt es schon sehr lange. Ich schätze mal, im PC seit den frühen 1990ern.

Ich habe Caches absichtlich nicht erwähnt, um Verwirrung zu vermeiden. Ich ordne zumindest L1-Caches den Registern zu.

Auf jeden Fall haben alle verglichenen Prozessoren Caches. Somit ist das Cache-Thema egal. Caches können zudem nicht so operieren, wie Register durch ihre Instruktionen.

Es gibt AVX, AVX2 und AVX512.

Es stellt sich die Frage, welche AVX-Familien die meisten 200-EUR-Rechner unterstützen? AVX512 ist jedenfalls selten implementiert.

Das ist ein Irrtum. Ich arbeite recht viel wissenschaftlich, analytisch, testend, untersuchend. Ich benötige absolute Datenkorrektheit, wenn ich 100 GB durchanalysiere. Eine Workstation ist ein typisches Ingenieur-Gerät!

Helmut Schellong schrieb:

Die Betriebsspannung konnte Dank der Weiterentwicklung der CMOS- Technik weiter gesenkt werden. Das wollte man, um die Geschwindigkeit zu erhöhen ohne den Strom zu erhöhen. Das war schon in der DTL-Zeit so. Bus-Terminierung und so.

Bei gegebenem Strom und gegebener Kapazität ist das Signal eben schneller auf 1 V als auf 5 V. Wenn man die Betriebsspannung reduziert und die Taktfrequenz zurücknimmt, wird überproportional die Heizleistung gesenkt. Im Idealfall quadratisch.

Helmut Schellong schrieb:

...

Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt es keine wirklich grossen Sprünge mehr.

Das sieht jetzt so aus, als wäre AVX2 schneller als AVX-512, obwohl es nur halb so breit ist und nur halb so viele Register aufweist.

AVX gibt es eigentlich schon seit 2008, so ganz langsam müsste das doch mal reindiffundieren.

Helmut Schellong schrieb:

Mit Tiger Lake auch im Notebook... seit etwa 2020.

Am 20.07.2023 um 22:23 schrieb Rolf Bombach:

Diese Spannung ist bei mir bei 800 MHz bei 0,68 V. Das ist schon erstaunlich. Die CPU verbrät dann 85W. Bei höherer CLK geht das allerdings nicht mehr. Man braucht dann mehr Umschaltkraft.

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:

Das kann nur verbessert werden, wenn man sich mit dem Konzept des Alpha-Prozessors anfreundet, oder ähnlich. Der wird wohl nicht mehr produziert, weil er zu gut ist.

Ich war auch erschrocken, als ich bei meinem Testpunkt 3) den Faktor 1,8 sah.

Wenn ich mich richtig erinnere, hat die AVX2-Familie viel mehr verschiedene Instruktionen. Und es kommt auch darauf an, wie gut ein Compiler AVX512 einkompiliert.

Man ist sehr zurückhaltend/konservativ in solchen Angelegenheiten. Per Voreinstellung verwendet ein Compiler auf meiner alten Plattform nur MMX (16 Byte). Man ist aber auch träge. Im 'calendar'-System bei mir werden derzeit alle Zeichen > 127 (ASCII) weggeworfen.

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:

Das kann nur verbessert werden, wenn man sich mit dem Konzept des Alpha-Prozessors anfreundet, oder ähnlich. Der wird wohl nicht mehr produziert, weil er zu gut ist.

Ich war auch erschrocken, als ich bei meinem Testpunkt 3) den Faktor 1,8 sah.

Wenn ich mich richtig erinnere, hat die AVX2-Familie viel mehr verschiedene Instruktionen. Und es kommt auch darauf an, wie gut ein Compiler AVX512 einkompiliert.

Man ist sehr zurückhaltend/konservativ in solchen Angelegenheiten. Per Voreinstellung verwendet ein Compiler auf meiner alten Plattform nur MMX (16 Byte). Man ist aber auch träge. Im 'calendar'-System bei mir werden derzeit alle Zeichen > 127 (ASCII) weggeworfen.

Am 20.07.2023 um 22:39 schrieb Rolf Bombach:

Weswegen Cryptominer, Videocutter, VFX-Artisten, CAD-Ingenieure, Elementarteilchenphysiker und KI-Forscher ja auch auf 10 Jahre altem Equipment beharren.

Volker

Weswegen Cryptominer, Videocutter, VFX-Artisten, CAD-Ingenieure, Elementarteilchenphysiker und KI-Forscher ja auch auf 10 Jahre altem Equipment beharren.

Volker

Am 21.07.2023 um 04:33 schrieb Helmut Schellong:

Es ist nicht MMX, sondern SSE mit den xmm#-Registern 128 Bit.

Am 21.07.2023 um 04:33 schrieb Helmut Schellong:

Die letzten großen Sprünge im Kontext waren der Pentium60 und Core Duo. Weitere solche Sprünge sind gewiß nicht einfach. Seit einigen Jahren steckt man da fest. Im Konzept des _kompromißlosen_ Alpha ist mehr enthalten, als man zunächst denkt.

Das Konzept des Itanium, der die Hauptlast dem Compiler auferlegte, gefiel mir spontan gar nicht. Das große Problem ist die Kompatibilität zu x86. Man muß endlich weg von x86 und seinen künstlichen, angehefteten Erweiterungen! Der Weg könnte sein, daß (intel) eine Software entwickelt, die alle x86.exe übersetzen kann, in einen neuen, noch zu entwickelnden, überlegenen Instruktionssatz. Diese Übersetzung müßte nur ein einziges Mal geschehen! Die Übersetzungssoftware könnte vielfältig mit den Übersetzungsquellen umgehen.

Man könnte 2 FPU haben, mit je 16 x 128 Bit breiten Registern (jetzt 1 FPU mit 8 x 80 Bit),

Fujitsu-uC: Man könnte einige sehr oft gebrauchte Instruktionen mit nur 1 Byte Länge haben. (Also das Gegenteil von VLIW.) Akkus, die zwei Hälften haben, wobei ein Schreiben in die untere Hälfte den bisherigen Inhalt in die obere Hälfte schiebt. Nachfolgend können viele Operationen mit den beiden Hälften durchgeführt werden, durch kurze Instruktionen. Resultat in unterer Hälfte oder in separatem Resultat-Register.

x86 ist eine 1-Adress-Maschine. Der neue Instruktionssatz sollte eine 2-Adress-Maschine bedienen.

Intel will bis 2030 eine Billion Transistoren auf einem Chip unterbringen! Ich will ungerne sehen, daß die einfach stumpf für 256 Kerne draufgehen. Das sollte doch eher so gemacht werden, wie ich oben skizzierte. Also mit Struktur.

Am 22.07.23 um 15:34 schrieb Helmut Schellong:

Als der 200 MHz pentium+ rauskam, da hatte es sich innerhalb eines knappen Jahres ausge-alphat. Der Hammer, wenn man FPGAs zu routen hatte. TI 99K, Clipper, Zilog, Sparc, Mips auch, mit unterschiedlichen Siechtumsdauern. Wobei, der MIPS4000 hat mir gefallen.

Das war nicht von Intel, das kam komplett von HP. Intel hätte sich komplett in die Brennnesseln gesetzt wenn sie nicht parallel an x86 weitergearbeitet hätten.

Das existiert längst als Hardware für on-the-fly. Aktuelle x86- Prozessoren sind intern schon sooo lange RISCs mit hunderten von Renaming-Registern.

Es existieren kaum fp-limitierte workloads. Nein, numerische Integration oder Matrix-Kicken wie in Spice auch nicht. Das hat sich schon zu NS16032-Zeiten und Weitek-Coprozessoren gezeigt. Big Fail. Holen & Entsorgen der Operanden ist nun mal das aufwendigste. Da mache ich lieber ein paar threads mehr auf, damit die FPUs auch ihre Infrastruktur haben.

Der Transputer T800 hatte 1 Nibble als kürzeste Instruktion, WIMRE. Hat's voll gebracht. Äh, nein! (Wenn ich noch wüsste, wo mein T800-Cluster abgeblieben ist!)

Ein Instruction set mit atmender Instruktionslänge ist so ungefähr das blödeste, was man sich antun kann. Das sorgt zuverlässig dafür, dass man eine Instruktion erst decodieren kann, wenn man weiss wo die davor endet. D.h. man muss sie schon decodiert HABEN. Pipelinestufe++. Und dass man sich einen barrel shifter vor dem Instruktions- Decoder einfängt mit NOCH einer extra Pipelinestufe um fest- zulegen, wieviel geshiftet werden muss. Und schön breit muss der Shifter auch werden, die Instruktion könnte ja erst im nächsten Wort aus dem Speicher enden, und das ist dann hoffentlich gelesen oder wenigstens im Cache. Kann auch nach 100 Takten aus dem Hauptspeicher kommen, vor allem bei einem pipeline stall nach einem Jump.

Ja, geil! Jetzt auch noch Daten zwangsverheiraten, die nix miteinander zu tun haben. Ein normales INC des unteren macht das obere wertlos, oder erfordert noch 2 instruction bits für oben/unten/beide. Oder ein move/trennen eines Halbworts, möglichst Aufräumen der Quelle.

Erinnert sehr an den Tod des 68060, wo es mit execptions und page faults Instruktionen geben konnte die niemals endeten. Aber Adressierungsarten wie double memory indirect mit ++ / -- waren ja sowas von geil, und Zeugnis der Technologie- überlegenheit gegenüber Intel. Und, wo isser?

Selten so hochkonzentrierten Stuß auf 1mal gelesen.

Schlong eben.

Gerhard

Am 22.07.2023 um 17:24 schrieb Gerhard Hoffmann:

Dies scheint kaum etwas zu bringen, bei Single-Thread, siehe oben. Und, warum wird dann kein neuer, überlegener Instruktionssatz gemacht?

Der Kontext hier ist Single-Thread. Warum gibt es da keine nennenswerten Sprünge, beklagen Rolf Bombach und ich.

Was ich durch Multitasking herausholen kann, habe ich hier bereits konkret gezeigt. Das ist das Einzige, was aktuell so richtig was bringt. Jedoch die meisten Aufgaben können nicht darauf ausgerichtet werden. Hingegen stark gesteigerte Single-Tasking-Performance brächte immer viel.

Ich weiß. Es erschienen im Lauf der Zeit immer wieder stark gehypte Prozessoren. Auch von Transmeta beispielsweise.

Man muß eben einen neuen überlegenen Instruktionssatz so konstruieren, daß er mit all dem keine Probleme hat, die Instruktionslänge schon zu Anfang weiß.

Nein, wie kommst Du darauf? Alle 48 Register, die ich oben aufgeführt habe, sind Universal-Register.

Intel selbst wirbt ständig damit, daß die zusätzlichen Instruktionen der Extensions

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt, gewissermaßen hängen will. Man erstickt seit Jahren mehr und mehr daran. Ich will nicht erleben, daß der x86 noch Jahrzehnte länger beherrschend ist. Das wäre ja krank. Deine Argumente stammen aus der fernen Vergangenheit, und sind daher fast irrelevant. Es geht aber darum, daß es _heutzutage_ keine nennenswerten Zuwächse bei Single-Tasking gibt. Das ist oben unschwer zu erkennen. Verbessere DAS mal - mach! Ich bin bereit, Gedanken dazu zu skizzieren - Du offenbar in krasser Weise nicht. Du willst wohl nur 'Schlong' anbringen.