Workstation: erste Tests...

[Helmut Schellong]

Am 16.07.2023 um 04:20 schrieb Arno Welzel:

Helmut Schellong, 2023-07-15 16:33:

Am 15.07.2023 um 16:05 schrieb Arno Welzel:
[...]
Deswegen ist die Aussage \"Prozessor x ist um Faktor 1,3
leistungsfähiger, weil die Wärmeabgabe um Faktor 1,3 höher ist\" dennoch
falsch, wenn man Prozessoren mit unterschiedlichem Aufbau vergleicht.

Ich habe im Vorfeld mindestens einmal das Gegenteil gesagt.

Warum beharrst Du dann darauf, dass man auch bei unterschiedlichen CPUs
anhand ihrer Wärmeabgabe die Leistung vergleichen kann?

Ich beharre nicht darauf - oh Wunder.
Ich beharre nur darauf, daß die (wahre) TDP steigt, je mehr Transistoren fortlaufend schalten.
Darauf beruht meine Theorie.

Nämlich, das nur Prozessoren aus einer Familie so verglichen werden können.
Beispielsweise die Xeon 2400 oder die Xeon 3400-Familienmitglieder untereinander.

Ja, und Dinge wie TDP und Cache-Größen ignorieren wir dann einfach mal,
schon klar.

Das Gegenteil ist der Fall.
Ich habe mich doch auf die TDP-Angaben des Herstellers gestützt.
Und die Cache-Größe ist gleich pro Kern.
Die Anzahl der Kerne ist unterschiedlich, u.a. deshalb unterschiedliche TDP.
Meine Theorie paßt also prinzipiell und proportional.
Nur die Hersteller-TDP (irgendwie politisch) passen nicht zu meiner Theorie.
Tests von PC-Medien z.B. haben für den 56-Kerner nämlich 520 W ergeben.
Damit paßt meine Theorie ganz ordentlich.
Von der Tendenz her paßt sie sowieso.

Es war mir schon zuvor klar, daß meine simple Berechnung nicht aufwendige Testläufe ersetzen kann.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 07.06.2023 um 16:18 schrieb Helmut Schellong:

Link zu Bildern: https://magentacloud.de/s/Eg8idByd7BA4EJy

Ein Vergleichstest
------------------
[...]

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.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 17.07.2023 um 16:31 schrieb Helmut Schellong:

Am 07.06.2023 um 16:18 schrieb Helmut Schellong:

Link zu Bildern: https://magentacloud.de/s/Eg8idByd7BA4EJy

Ein Vergleichstest
------------------
[...]

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
[...]

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Marc Haber]

Helmut Schellong <var@schellong.biz> wrote:

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.

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.

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.

Das kann heute jeder 200-Euro-Rechner.

--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834

 

[Marc Haber]

Helmut Schellong <var@schellong.biz> wrote:
>Bei der Konzeption der WS habe ich offenbar alles sehr richtig gemacht.

Bis auf die Bedarfsbestimmung.
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834

 

[Helmut Schellong]

Am 18.07.2023 um 09:57 schrieb Marc Haber:

Helmut Schellong <var@schellong.biz> wrote:
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.

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.

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.

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.

Das kann heute jeder 200-Euro-Rechner.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 18.07.2023 um 09:58 schrieb Marc Haber:

Helmut Schellong <var@schellong.biz> wrote:
Bei der Konzeption der WS habe ich offenbar alles sehr richtig gemacht.

Bis auf die Bedarfsbestimmung.

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!


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Helmut Schellong schrieb:

Die kapazitiven Umladungen wegen Schaltflanken sind DIE einzige dominierende Hitzequelle in Prozessoren!
Aus diesem Grund wurde die interne Kern-Betriebsspannung mittlerweile auf unter 1 V gesenkt.
Je mehr Transistoren des Prozessors fortlaufend schalten, umso mehr Leistung (U*I) verbrät dieser (1).
Das ist linear proportional. (1)

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.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Helmut Schellong schrieb:

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

....

> Single-Thread:   683/272 =  2,5

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

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

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.

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.

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

--
mfg Rolf Bombach

 

[Rolf Bombach]

Helmut Schellong schrieb:

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

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

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 20.07.2023 um 22:23 schrieb Rolf Bombach:

Helmut Schellong schrieb:

Die kapazitiven Umladungen wegen Schaltflanken sind DIE einzige dominierende Hitzequelle in
Prozessoren!
Aus diesem Grund wurde die interne Kern-Betriebsspannung mittlerweile auf unter 1 V gesenkt.
Je mehr Transistoren des Prozessors fortlaufend schalten, umso mehr Leistung (U*I) verbrät dieser
(1).
Das ist linear proportional. (1)
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.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:

Helmut Schellong schrieb:


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

...

Single-Thread:   683/272 =  2,5

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

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.

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

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.

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.

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.

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:

Helmut Schellong schrieb:


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

...

Single-Thread:   683/272 =  2,5

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

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.

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

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.

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.

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.

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

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 20.07.2023 um 22:39 schrieb Rolf Bombach:

Helmut Schellong schrieb:

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

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

https://www.epey.co.uk/cpu/e/YToxOntpOjUwOTc7YToxOntpOjA7czo2OiI0Mjg1NzUiO319X2I6MDs=/3/


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Volker Bartheld]

On Thu, 20 Jul 2023 22:38:22 +0200, Rolf Bombach wrote:

Helmut Schellong schrieb:
WS = Xeon 3435X, 16 Kerne, 32 CPUs, Basis 3100 MHz, 128 GB
PC = 2006 E8600,  2 Kerne,  2 CPUs, 3333 MHz, 4 GB
Single-Thread:   683/272 =  2,5
Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt
es keine wirklich grossen Sprünge mehr.

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

Volker

 

[Volker Bartheld]

On Thu, 20 Jul 2023 22:38:22 +0200, Rolf Bombach wrote:

Helmut Schellong schrieb:
WS = Xeon 3435X, 16 Kerne, 32 CPUs, Basis 3100 MHz, 128 GB
PC = 2006 E8600,  2 Kerne,  2 CPUs, 3333 MHz, 4 GB
Single-Thread:   683/272 =  2,5
Eigentlich traurig für 15 Jahre Fortschritt. Offenbar gibt
es keine wirklich grossen Sprünge mehr.

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

[sup] Oh, und Softwareentwickler. Die hatte ich vergessen.

Volker

 

[Helmut Schellong]

Am 21.07.2023 um 04:33 schrieb Helmut Schellong:

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:
Helmut Schellong schrieb:
[...]

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

Man ist sehr zurückhaltend/konservativ in solchen Angelegenheiten.
Per Voreinstellung verwendet ein Compiler auf meiner alten Plattform nur MMX (16 Byte).

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


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 21.07.2023 um 04:33 schrieb Helmut Schellong:

Am 20.07.2023 um 22:38 schrieb Rolf Bombach:
Helmut Schellong schrieb:


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

...

Single-Thread:   683/272 =  2,5

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

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.

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),
3 IPU, mit je 48 x 64 Bit Registern, je 16 Akkus mit je 128 Bit,
eine VPU mit superbreiten Registern, 64 x 1024 Bit, eine Instruktions-Familie ´EVI´.

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.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Gerhard Hoffmann]

Am 22.07.23 um 15:34 schrieb Helmut Schellong:

Am 21.07.2023 um 04:33 schrieb Helmut Schellong:
Am 20.07.2023 um 22:38 schrieb Rolf Bombach:
Helmut Schellong schrieb:


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

...

Single-Thread:   683/272 =  2,5

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

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.

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.

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

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 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 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.

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.

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

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.

3 IPU, mit je 48 x 64 Bit Registern, je 16 Akkus mit je 128 Bit,
eine VPU mit superbreiten Registern, 64 x 1024 Bit, eine
Instruktions-Familie ´EVI´.

Fujitsu-uC:
Man könnte einige sehr oft gebrauchte Instruktionen mit nur 1 Byte Länge
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.

(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.

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.

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

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?

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.

Selten so hochkonzentrierten Stuß auf 1mal gelesen.

Schlong eben.

Gerhard

 

[Helmut Schellong]

Am 22.07.2023 um 17:24 schrieb Gerhard Hoffmann:

Am 22.07.23 um 15:34 schrieb Helmut Schellong:
Am 21.07.2023 um 04:33 schrieb Helmut Schellong:
Am 20.07.2023 um 22:38 schrieb Rolf Bombach:
Helmut Schellong schrieb:


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

...

Single-Thread:   683/272 =  2,5

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

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.

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.


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

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 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 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.

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.

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

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

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 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.

3 IPU, mit je 48 x 64 Bit Registern, je 16 Akkus mit je 128 Bit,
eine VPU mit superbreiten Registern, 64 x 1024 Bit, eine Instruktions-Familie ´EVI´.

Fujitsu-uC:
Man könnte einige sehr oft gebrauchte Instruktionen mit nur 1 Byte Länge 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!)

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

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.

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

(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.

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.

Nein, wie kommst Du darauf?
Alle 48 Register, die ich oben aufgeführt habe, sind Universal-Register.
16 Register sind halt Doppel-Akkus.
Ein INC soll in diesen Doppel-Akkus gar nicht ausgeführt werden, sondern nur
Operationen mit 2 Operanden.

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

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?

Intel selbst wirbt ständig damit, daß die zusätzlichen Instruktionen der Extensions
2-Adress-Instruktionen sind, die keine Werte überschreiben.

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.

Selten so hochkonzentrierten Stuß auf 1mal gelesen.

Schlong eben.

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.


--
Mit freundlichen Grüßen
Helmut Schellong