Workstation: erste Tests...

[Hanno Foest]

Am 22.07.23 um 20:32 schrieb Helmut Schellong:

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt,
gewissermaßen hängen will.

Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc.
Prozessoren, Intel investiert massiv in RISC-V.

Hanno

--
The modern conservative is engaged in one of man\'s oldest exercises in
moral philosophy; that is, the search for a superior moral justification
for selfishness.
- John Kenneth Galbraith

 

[Helmut Schellong]

Am 22.07.2023 um 21:43 schrieb Hanno Foest:

Am 22.07.23 um 20:32 schrieb Helmut Schellong:

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt, gewissermaßen hängen will.

Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc. Prozessoren, Intel investiert massiv
in RISC-V.

Dennoch ist x86 nach wie vor sehr beherrschend.
Es erscheint so: man kann nicht davon lassen, man kann nicht, es geht einfach nicht,
es kann keinen Übergang zu etwas anderem geben, ...

x86 ist ein sehr alter Instruktionssatz, vom 8086, 16 Bit, DOS, aus den 1970ern.
Übrigens ein längenatmender Instruktionssatz, der angeblich so ungefähr das Blödeste ist, was
man sich antun kann.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Gerrit Heitsch]

On 7/23/23 00:01, Helmut Schellong wrote:

Am 22.07.2023 um 21:43 schrieb Hanno Foest:
Am 22.07.23 um 20:32 schrieb Helmut Schellong:

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt,
gewissermaßen hängen will.

Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc.
Prozessoren, Intel investiert massiv in RISC-V.

Dennoch ist x86 nach wie vor sehr beherrschend.

Nur beim PC und da liegt es an der Kompatibilität die man meint brauchen
zu müssen.

x86 ist ein sehr alter Instruktionssatz, vom 8086, 16 Bit, DOS, aus den
1970ern.

Wobei der oirginale Befehlssatz kaum noch verwendet werden dürfte sobald
OS und Anwendungen 64Bit sind.

Übrigens ein längenatmender Instruktionssatz, der angeblich so ungefähr
das Blödeste ist, was
man sich antun kann.

Ja, vor allem wenn man ihn mit dem 68000 vergleicht.

Gerrit

 

[Volker Bartheld]

On Sat, 22 Jul 2023 21:43:52 +0200, Hanno Foest wrote:

Am 22.07.23 um 20:32 schrieb Helmut Schellong:
Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt,
gewissermaßen hängen will.
Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc.
Prozessoren, Intel investiert massiv in RISC-V.

Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege. Nicht, daß das für mich jetzt groß ein Problem
darstellen würde, weil ich Apple-Produkte selbst mit der Zange nicht
anfasse und für Experimente mit Raspberry Pi OS oder dem ROCK 5 Model B
nicht experimentierfreudig genug bin.

Aber wer mit LineageOS auf seinem Smartphone klarkommt, wird wohl auch
ein passendes OS für seine etwas exotischere PC-Architektur finden
können. Von \"Stuß\" oder \"Gedeih und Verderb\" kann also keine Rede sein.

Außer bei Helmut natürlich.

Volker

 

[Thomas Prufer]

On Sun, 23 Jul 2023 09:45:28 +0200, Volker Bartheld <news2023@bartheld.net>
wrote:

Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege. Nicht, daß das für mich jetzt groß ein Problem
darstellen würde, weil ich Apple-Produkte selbst mit der Zange nicht
anfasse und für Experimente mit Raspberry Pi OS oder dem ROCK 5 Model B
nicht experimentierfreudig genug bin.

Ich hab vor längerer Zeit eine alten Laptop mit Linux versehen, um einen
verzichtbarer Reise-PC zu haben: ISTR NEC Versa Pentium MMX mit 1 Gb FP und mit
dreistellig MB Ram. Zu dem Zeitpunkt schon eine uralte Gurke, aber mit
wunderbarer Tastatur und mechanisch richtig stabil.

Alle ausprobierten Linux-Distributionen die ich so als fertiges Paket
runterladen konnte waren schnarchlangsam. (Klar, totgeswappt, Speicher hart an
der Grenze.)

Dann ein Linux für diesen Prozessor optimiert kompiliert -- eine sehr deutliche
Verbesserung! Einfach weil einmal der Befehlssatz zur Compile-Zeit bekannt war
zum anderen weil sehr viel Universal-Eierlegende-Wollmilchsau-Code rausflog: War
nicht ich, sondern das makefile

Dann noch \"Dillo\" als webbrowser statt firefox, und dann war ein adäquates
Arbeiten möglich. Dillo hat vielen Werbekram auch erst garnicht angezeigt,
mangels flash, frames, *script, usw. Zu informieren hat\'s gereicht



Thomas Prufer

 

[Helmut Schellong]

Am 23.07.2023 um 08:04 schrieb Gerrit Heitsch:

On 7/23/23 00:01, Helmut Schellong wrote:
Am 22.07.2023 um 21:43 schrieb Hanno Foest:
Am 22.07.23 um 20:32 schrieb Helmut Schellong:

Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt, gewissermaßen hängen will.

Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc. Prozessoren, Intel investiert
massiv in RISC-V.

Dennoch ist x86 nach wie vor sehr beherrschend.

Nur beim PC und da liegt es an der Kompatibilität die man meint brauchen zu müssen.

x86 ist ein sehr alter Instruktionssatz, vom 8086, 16 Bit, DOS, aus den 1970ern.

Wobei der oirginale Befehlssatz kaum noch verwendet werden dürfte sobald OS und Anwendungen 64Bit
sind.

Das alles läuft unter x86-Plattform.
Auch amd64 ist nur ein aufgebohrter x86 -> x86_64.

Prozessoren: 8086, 80186, 80286, 80386, 80486, Pentium.
Ab 80386 32 Bit.

Übrigens ein längenatmender Instruktionssatz, der angeblich so ungefähr das Blödeste ist, was
man sich antun kann.

Ja, vor allem wenn man ihn mit dem 68000 vergleicht.

Ich bin stets sehr an echten Tatsachen interessiert.
Bereits in den 1980ern habe ich Assembler programmiert.
Ich kenne die Bitstruktur von Instruktionssätzen.

In der konkreten Praxis bringt der uC-Instruktionssatz von Fujitsu erkennbare Vorteile.
Geringe Code-Größe (weil längenatmend) und auch deshalb erhöhte Geschwindigkeit.

Z.B. alle Instruktionen 32 Bit breit, wird auch Vorteile bringen, u.a. weil dies
im voraus bekannt ist (Pauschalität).
Konstanten (Immediate) sind dann _zunächst_ einmal nicht möglich, was aber ein Nogo ist,
weshalb da eine Lösung gefunden werden muß.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.07.2023 um 09:45 schrieb Volker Bartheld:

On Sat, 22 Jul 2023 21:43:52 +0200, Hanno Foest wrote:
Am 22.07.23 um 20:32 schrieb Helmut Schellong:
Der größte Stuß ist, daß man am x86 auf Gedei und Verderb hängt,
gewissermaßen hängen will.
Will man ja gar nicht. Apple setzt auf ARM in Form der M2 etc.
Prozessoren, Intel investiert massiv in RISC-V.

Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege. Nicht, daß das für mich jetzt groß ein Problem
darstellen würde, weil ich Apple-Produkte selbst mit der Zange nicht
anfasse und für Experimente mit Raspberry Pi OS oder dem ROCK 5 Model B
nicht experimentierfreudig genug bin.

Aber wer mit LineageOS auf seinem Smartphone klarkommt, wird wohl auch
ein passendes OS für seine etwas exotischere PC-Architektur finden
können. Von \"Stuß\" oder \"Gedeih und Verderb\" kann also keine Rede sein.

Außer bei Helmut natürlich.

Der Kontext zu meiner Aussage fehlt, wie eigentlich immer.
Man hat es dadurch einfach, sich isoliert mit meinen Aussagen zu befassen
und diese als pur negativ darzustellen.
Folglich eine (bewußte) Verzerrung der Wirklichkeit.

Der Kontext ist, daß man sich mit x86 allmählich in einer schlimmen Sackgasse befindet.
Und man will offenbar faktisch in dieser Sackgasse (Technologie-Stau) bleiben.
Nur deshalb habe ich den Satz mit \"Stuß, Gedeih, Verderb\" geschrieben.

Der Verderb ist praktisch bereits erreicht: nämlich der bemerkbare Technologie-Stau.
Was ist dieser Technologiestau?
Na, aus dem Kontext: daß die Single-Thread-Performance sich in den letzten etwa 17 Jahren
nur auf etwa das 2-fache erhöht hat, während sich die RAM-Performance auf vielleicht
den 20-fachen Wert erhöht hat.
Von Rolf Bombach und mir bedauernd bemerkt.
Ich habe das alles haarklein vorgeführt und dargestellt.
(Die Wahrheit) Scheint allerdings nur ganz Wenige zu interessieren.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Gerhard Hoffmann]

Am 22.07.23 um 20:32 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.


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.

Wenn ich eine Schaltung mit 1000 Knoten habe, dann bekomme ich
in Spice eine Leitwertmatrix von 1000*1000. Viel Spaß beim
Lösen. Von der Million Matrix-Einträge sind vermutlich die
meisten 0, weil die meisten Knoten nix direkt miteinander
zu tun haben. Vor jeder \"nützlichen\" FP-operation muss man
drölfzig Werte befummeln um festzustellen, ob die überhaupt
eine Auswirkung haben. Das erzeugt natürlich einen Datenstrom
ohne Ende im Vergleich zu den paar FP-Ops die tatsächlich
stattfinden. --> Cache thrashing --> Willkommen bei der DRAM-
Zykluszeit.


> Das ist das Einzige, was aktuell so richtig was bringt.

ist die Algorithmen umzuschreiben dass man mehrere Kerne
darauf ansetzen kann. Sorry, das macht richtig Arbeit.
Im Spice-Beispiel könnte man lokale, eng gekoppelte
Teilschaltungen getrennt voneinander lösen und sie sich
gegenseitig füttern lassen. Der Zeitgewinn ist über-
proportional zur Matrixgröße, äh, -Kleinheit.

Jedoch die meisten Aufgaben können nicht darauf ausgerichtet werden.
Hingegen stark gesteigerte Single-Tasking-Performance brächte immer viel.

Überlichtschnelle Autos auch.

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

Man muß eben einen neuen überlegenen Instruktionssatz so konstruieren, daß
er mit all dem keine Probleme hat,

\"Überlegene\" instruction sets ist sooo 80-er!

Alle 48 Register, die ich oben aufgeführt habe, sind Universal-Register.
16 Register sind halt Doppel-Akkus.

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.

JaJa. Ich habe von einem Kunden ein Macbook Air bekommen, damit
ich ins Firmennetz kann. Leider sollte da auch Altium
drauf laufen. Nach ein paar Tagen Rumhampeln mit Parallels
und VMware war es plötzlich ganz leicht, statt dessen einen
X86-Laptop zu bekommen. Da bemerkte die IT, dass Arbeit droht.
LTspice, Altium und FPGAs ist eben was anderes als email lesen.

Deine Argumente stammen aus der fernen Vergangenheit, und sind daher
fast irrelevant.

Nein, was aus der fernen Vergangenheit stammt, das ist das
Geseiere vom überlegenen instruction set. Es existiert keiner.
Was als X86-Code gelesen wird, das ist eine Datenfluss-
Beschreibung in hoffentlich halbwegs kompakter Form. Die hat
mit dem Prozessor, der das alles ausführen muss, absolut nix
mehr zu tun.

Der Prozessor, der das alles ausführt, der hat vollkommen andere
Befehle und nicht Deine popeligen 48 Register sondern hunderte.
Die Grenze ist, wo Register anfangen, langsamer als der innerste
Cache zu werden und/oder die Anzahl der Register-Ports anfängt
weh zu tun.

Es gibt da kein EAX-Register, es gibt viele. Und der Prozessor
macht Datenfluss-Analyse um festzustellen, was für entities in welcher
EAX-Incarnation landen. Mach dich mal mit Register-
Renaming vertraut.

Es geht aber darum, daß es _heutzutage_ keine nennenswerten Zuwächse bei
Single-Tasking gibt.
Das ist oben unschwer zu erkennen.

Die niedrig hängenden Früchte sind eben aufgegessen. Etwa, dass
man für 10% der Chipfläche (hauptsächlich Register) mehr einen
2. thread bekommt.

Verbessere DAS mal - mach!
Ich bin bereit, Gedanken dazu zu skizzieren - Du offenbar in krasser
Weise nicht.

Ich skizziere nicht, ich schreibe die notfalls in VHDL und packe die in
ein Virtex. Da kann ich z.B. hundert Multiplier in einem
digitalen Filter ohne idle-Zyklen voll auslasten.

Gerhard

 

[Helmut Schellong]

Am 23.07.2023 um 11:19 schrieb Gerhard Hoffmann:

Am 22.07.23 um 20:32 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.


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.

Wenn ich eine Schaltung mit 1000 Knoten habe, dann bekomme ich
in Spice eine Leitwertmatrix von 1000*1000. Viel Spaß beim
Lösen. Von der Million Matrix-Einträge sind vermutlich die
meisten 0, weil die meisten Knoten nix direkt miteinander
zu tun haben. Vor jeder \"nützlichen\" FP-operation muss man
drölfzig Werte befummeln um festzustellen, ob die überhaupt
eine Auswirkung haben. Das erzeugt natürlich einen Datenstrom
ohne Ende im Vergleich zu den paar FP-Ops die tatsächlich
stattfinden. --> Cache thrashing --> Willkommen bei der DRAM-
Zykluszeit.

Als der Pentium mit stark gesteigerter FP-Performance erschien, wurde gejubelt!
Besonders die 3 Takte für die Multiplikation wurden bejubelt.
Die immense FP-Performance des Alpha hatte Bewunderung, fast Ehrfurcht ausgelöst.

Auf dem PC bei Privatleuten ist FP kaum ein Thema - das ist bekannt.
Auf Workstations und in der Education hingegen ist FP außerordentlich wichtig.
Wozu gibt es SpecInt und SpecFP?

2000 Performance-Vergleich
(auf Basis von SPECint95 und SPECfp95 Result)
System CPU MHz integer floating point
--------------------------------------------------------------
AlphaServer ES40 6/833 21264 (EV6) 833 50.0 100.0
Intel VC820 Motherboard Pentium III 1000 46.8 31.9
HP 9000 C3600 PA-8600 _______________ 552 42.1 64.0

Das ist das Einzige, was aktuell so richtig was bringt.

ist die Algorithmen umzuschreiben dass man mehrere Kerne
darauf ansetzen kann. Sorry, das macht richtig Arbeit.
Im Spice-Beispiel könnte man lokale, eng gekoppelte
Teilschaltungen getrennt voneinander lösen und sie sich
gegenseitig füttern lassen. Der Zeitgewinn ist über-
proportional zur Matrixgröße, äh, -Kleinheit.

|Was ich durch Multitasking herausholen kann, habe ich hier bereits konkret gezeigt.

Ich habe keine Algorithmen umgeschrieben, sondern einfach gleichzeitige Prozesse gestartet.
Bis zu 18, mit dem Erfolg von etwa 5 Minuten Zeitbedarf statt Stunden!
Wenn ich z.B. 5 Dateisysteminhalte in je ein Archiv packe, dann den Hash ziehe und
schließlich (n-fach) verschlüssele, kann ich dazu ganz einfach 5 Prozesse gleichzeitig starten.

Jedoch die meisten Aufgaben können nicht darauf ausgerichtet werden.
Hingegen stark gesteigerte Single-Tasking-Performance brächte immer viel.

Überlichtschnelle Autos auch.

Ein Null-Argument.
Stark gesteigerte Single-Tasking-Performance bringt 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´.

Man muß eben einen neuen überlegenen Instruktionssatz so konstruieren, daß
er mit all dem keine Probleme hat,

\"Überlegene\" instruction sets ist sooo 80-er!

Schwache Argumentation.

Alle 48 Register, die ich oben aufgeführt habe, sind Universal-Register.
16 Register sind halt Doppel-Akkus.

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.

JaJa. Ich habe von einem Kunden ein Macbook Air bekommen, damit
ich ins Firmennetz kann. Leider sollte da auch Altium
drauf laufen. Nach ein paar Tagen Rumhampeln mit Parallels
und VMware war es plötzlich ganz leicht, statt dessen einen
X86-Laptop zu bekommen. Da bemerkte die IT, dass Arbeit droht.
LTspice, Altium und FPGAs ist eben was anderes als email lesen.

Deine Argumente stammen aus der fernen Vergangenheit, und sind daher fast irrelevant.

Nein, was aus der fernen Vergangenheit stammt, das ist das
Geseiere vom überlegenen instruction set. Es existiert keiner.

Na ja, ich würde den vom Alpha als stark überlegen bezeichnen.

Was als X86-Code gelesen wird, das ist eine Datenfluss-
Beschreibung in hoffentlich halbwegs kompakter Form. Die hat
mit dem Prozessor, der das alles ausführen muss, absolut nix
mehr zu tun.

Der Prozessor, der das alles ausführt, der hat vollkommen andere
Befehle und nicht Deine popeligen 48 Register sondern hunderte.
Die Grenze ist, wo Register anfangen, langsamer als der innerste
Cache zu werden und/oder die Anzahl der Register-Ports anfängt
weh zu tun.

Warum hat dann dieser ganze Aufwand kaum einen angemessenen Erfolg?
Es sieht für mich so aus, als sei der Gewinn von etwa 2-fach innerhalb von Jahrzehnten
einfach durch Verschnellerung von einzelnen Instruktionen über die Zeit entstanden.
32 Bit -> 64 Bit bringt etwa das 1,3-fache.

Es gibt da kein EAX-Register, es gibt viele. Und der Prozessor
macht Datenfluss-Analyse um festzustellen, was für entities in welcher EAX-Incarnation landen. Mach
dich mal mit Register-
Renaming vertraut.

Was sind das für Behauptungen.
Von Register-Renaming hörte ich bereits vor mehr als 10 Jahren.

Es geht aber darum, daß es _heutzutage_ keine nennenswerten Zuwächse bei Single-Tasking gibt.
Das ist oben unschwer zu erkennen.

Die niedrig hängenden Früchte sind eben aufgegessen. Etwa, dass
man für 10% der Chipfläche (hauptsächlich Register) mehr einen
2. thread bekommt.

Schon wieder Multitasking.

Verbessere DAS mal - mach!
Ich bin bereit, Gedanken dazu zu skizzieren - Du offenbar in krasser Weise nicht.

Ich skizziere nicht, ich schreibe die notfalls in VHDL und packe die in ein Virtex. Da kann ich
z.B. hundert Multiplier in einem
digitalen Filter ohne idle-Zyklen voll auslasten.

Das hat aber nichts mit einer Verbesserung von Prozessoren in der PC-Welt zu tun.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Volker Bartheld]

On Sun, 23 Jul 2023 09:45:28 +0200, Volker Bartheld <news2023@bartheld.net
wrote:
Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege.

On Sun, 23 Jul 2023 10:29:05 +0200, Thomas Prufer wrote:

Ich hab vor längerer Zeit eine alten Laptop mit Linux versehen [...]
Alle ausprobierten Linux-Distributionen die ich so als fertiges Paket
runterladen konnte waren schnarchlangsam. [...]
Dann ein Linux für diesen Prozessor optimiert kompiliert -- eine sehr deutliche
Verbesserung!

Ach Du meine Güte! Also dafür wäre ich nicht leidensfähig genug. Mein
Thinkpad T30 lief mit irgendeiner Linux Mint Mate LTE Version für
32-Bit vollkommen problemlos. Ich hatte dem selbstredend eine NVMe-SSD
mit P-ATA-Adapter spendiert. Ja, etwas exotische Adapteritis, aber was
willst machen, wenn Du eine echte RS232 brauchst.

Der einzige Fummelkram war m. E. n. die Konfiguration von WIFI/W-LAN.

Dann hatte ich einem Asus EeePC 1008 HA erste eine S-ATA SSD und dann
Linux Mint Mate spendiert. Konnte man durchaus mit leben. Einziges
Problem waren die unsäglich schrottigen China-Nachbauakkus, der eine war
DOA und der andere blähte sich nach ein paar Ladezyklen so auf, daß es
fast die Tastatur aus dem Clamshell-Gehäuse sprengte.

Wir dieses Klappnotebook kennt, weiß wie geil es ist, dort den Akku zu
tauschen. Mehrmals. Ich habe dann resigniert und das Teil an einen
dse-Regular gegen Portokosten verschenkt.

Und irgendwann flog mir ein Asus Nexus 7 zu, das irgendwelche
Umweltschweinderl @work in die Tonne mit dem Elektroschrott gefeuert
haben, als ich gerade drinnensaß. Da kratzte ich den Google-Dreck aus
den Ritzen und spielte UBports/Ubuntu Touch drauf. War auch kein großes
Problem, mein Kind liebt das Teil für irgendwelchen Anton-Schulkram und
die YouTube-Filmchen, die Kinder halt so schauen. Apps für E-Mail,
Usenet & Co gibts da auch, vermisse nichts. Auch nicht in Sachen
Geschwindigkeit.

Bei meinen Eltern steht noch ein recht anachonistischer Dualcore-PC aus
Konkursmasse, der läuft mit S-ATA-SSD und Mint Mate auch brauchbar.
Mußte allerdings meine alte passive PCIe-Grafikkarte reintecken, weil
mit VGA holst DU halt heute keinen Hund hinterm Ofen mehr hervor. Läuft
alles, Netzwerk, Scanner, Soundkarte, Officeapplikationen, Browser, ...
Wir natürlich Herrn Schellong in Sachen Performance nicht
zufriedenstellen und Parity-SDRAM hat das Dingens natürlich auch nicht.

Und am Ende der Welt werkelt (m)ein Fujitsu-Siemens Esprimo P2510, den
ich mit soviel Speicher aufgerüstet habe, wie der Computerflohmarkt
hergab. Und einer alten 128GB-SSD. Mit der ollen ATI Radeon Xpress 1100
kannst Du zwar nicht gamen, aber zumindest gibts DVI für den 24-Zöller,
den ich - wer räts? - aus dem E-Schrott-Container gezogen habe. Keine
Ahnung, welches Linux ich dadrauf getan habe, aber es tat.

Und während das tolle Microsoft-Convertible meiner besseren Hälfte, das
man in ihrer Schule für unentbehrlich hielt, den Hitzetod starb, tut
der Lenovo Thinkpad T460 immer noch, dem ich anderswen als
pragmatischen Laptop von https://www.thinkstore24.de/ für den halben
Preis in gebrauchter A-Ware empfohlen habe.

Also, mei, es muß nicht immer Latest-Greatest sein. Sogar mein etwas
angestaubter i7, vor dem ich aktuell sitze, macht beim Videoschnitt mit
Lightworks eine ordentliche Figur. Klar, 16GB und eine (passive)
GeForce GT1030 hat der natürlich auch, ein paar leise Noctua-Lüfter und
zwei SSDs. Und bei Material in 4K muß man halt Proxies erzeugen. Ich
bin halt nicht Linus^Wääääh Krösus und kann für mein Hobby mal eben ein
paar k¤ raushauen.

Dann noch \"Dillo\" als webbrowser statt firefox, und dann war ein adäquates
Arbeiten möglich. Dillo hat vielen Werbekram auch erst garnicht angezeigt,
mangels flash, frames, *script, usw. Zu informieren hat\'s gereicht

Eben. Da sind kreative Lösungen gefragt. Der Faulpelz wirft halt Geld
auf sein Problem. Auch gut. Jeder, wie er mag.

Volker

 

[Helmut Schellong]

Am 23.07.2023 um 22:45 schrieb Volker Bartheld:

On Sun, 23 Jul 2023 09:45:28 +0200, Volker Bartheld <news2023@bartheld.net
wrote:
Dennoch ist es so, daß ich z. B. mein favorisiertes Linux-OS (Linux
Mint) nur für 64-Bit x86-Plattformen und als etwas abgehangene Version
für 32-Bit kriege.

On Sun, 23 Jul 2023 10:29:05 +0200, Thomas Prufer wrote:
[...]
Ach Du meine Güte! Also dafür wäre ich nicht leidensfähig genug. Mein
Thinkpad T30 lief mit irgendeiner Linux Mint Mate LTE Version für
32-Bit vollkommen problemlos. Ich hatte dem selbstredend eine NVMe-SSD
mit P-ATA-Adapter spendiert. Ja, etwas exotische Adapteritis, aber was
willst machen, wenn Du eine echte RS232 brauchst.

uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0

Vorstehendes zeigt FreeBSD beim Booten an, in meiner Workstation.

Ich habe für 5 EUR ein Slotblech mit zwei 9-pol. D-SUB darauf gekauft.
Das Mainboard hat eine Stiftbuchse dafür.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 23.07.2023 um 10:52 schrieb Helmut Schellong:

Am 23.07.2023 um 08:04 schrieb Gerrit Heitsch:
[...]
Übrigens ein längenatmender Instruktionssatz, der angeblich so ungefähr das Blödeste ist, was
man sich antun kann.

Ja, vor allem wenn man ihn mit dem 68000 vergleicht.

Ich bin stets sehr an echten Tatsachen interessiert.
Bereits in den 1980ern habe ich Assembler programmiert.
Ich kenne die Bitstruktur von Instruktionssätzen.

In der konkreten Praxis bringt der uC-Instruktionssatz von Fujitsu erkennbare Vorteile.
Geringe Code-Größe (weil längenatmend) und auch deshalb erhöhte Geschwindigkeit.

Z.B. alle Instruktionen 32 Bit breit, wird auch Vorteile bringen, u.a. weil dies
im voraus bekannt ist (Pauschalität).
Konstanten (Immediate) sind dann _zunächst_ einmal nicht möglich, was aber ein Nogo ist,
weshalb da eine Lösung gefunden werden muß.

Dazu sind mir neue Ideen eingefallen:

Es können (externe) Instruktionen definiert werden, die _nur_ eine Index-Zahl enthalten.
Dieser Index adressiert die jeweils passenden Komponenten der inneren Instruktions-Struktur.
Eine innere Instruktion wird von einer anderen Pipeline verarbeitet.

Bei den Werten 0..127 ist der Index (die externe Instruktion) nur 1 Byte lang.
Der Index ist maximal 2 Byte lang (128..65535).

Für 1 Byte Länge sollen nur die _häufigsten_ Instruktionen zugeordnet werden.
Egal, wie komplex diese Instruktionen sind.
Beispielsweise Zuordnung nur der ersten 2..6 Register eines Register-Arrays (je 32).

Es ist vorstellbar, daß 1-Byte-Instruktionen 60% bis fast 100% Anteil haben würden.
Die Code-Menge einer Executable würde extrem sinken.
Das Fetchen würde wesentlich schneller.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Arno Welzel]

Helmut Schellong, 2023-07-21 04:12:

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.

Die 64-Bit-CPU in meinem Smartphone hat 8 Kerne mit verschiedenen
Taktfrequenzen:

2x ARM Cortex-A76 mit 2,25 GHz
4x ARM Cortex-A55 mit 1,8 GHz
2x ARM Cortex-X1 mit 2,8 GHz

Der Akku von dem Gerät hat nominell eine Kapazität von 16,97 Wh. Das
hält problemlos für 20-30 Stunden und selbst unter Last mehrere Stunden,
was ein Indikator ist, dass die CPUs selbst bei stärkerer Last mit weit
unter 16 Watt auskommen. Eine besondere Kühlung braucht das Gerät auch
nicht, es wird gerade mal handwarm, wenn es stärker ausgelastet wird.

Nominell hat die CPU eine TDP von gerade mal 5,6 Watt.


--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-18 11:35:

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.

Und wieso glaubst Du, dass die nicht gegeben ist, wenn die Hardware kein
Xeon 3435X mit 128 RAM ist?

> Eine Workstation ist ein typisches Ingenieur-Gerät!

Ach so, Du siehst deine Betätigung an diesem Gerät als die eines
Ingenieurs und nicht als Hobby. Welche Projekte hast Du denn damit
geplant, die nicht nur für Dich privat von Interesse sind?

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-18 11:22:

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.

Und was hat das mit Fortschritten im CPU-Design zu tun?

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.

Ok, 200 EUR vielleicht nicht, aber ein AMD Ryzen 5 7600 unterstützt
AVX512 und der kostet aktuell ca. 230 EUR. Mit PC drumherum kommt man
sicher mit 400-500 EUR hin.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-21 04:33:

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.

ARM ist auch eine echte Konkurrenz. Nicht umsonst nutzt Apple
mittlerweile durchgehend nur noch ARM, auch bei den Laptops. Und die
sind in etlichen Beriechen deutlich performanter als vergleichbare
x86-Geräte.

Auch bei mobilen Geräten ist x86 kein Thema, weil viel zu ineffizient.

--
Arno Welzel
https://arnowelzel.de

 

[Arno Welzel]

Helmut Schellong, 2023-07-22 15:34:

[...]

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.

Apple hat das schon, damit x86-Software auch weiterhin auf den aktuellen
Geräten mit ARM-CPU läuft. Ist noch nicht optimal, aber schon ein guter
Anfang.

--
Arno Welzel
https://arnowelzel.de

 

[Hans-Peter Diettrich]

On 7/24/23 8:25 PM, Helmut Schellong wrote:

Es können (externe) Instruktionen definiert werden, die _nur_ eine
Index-Zahl enthalten.

Also mit fest zugeordneten Adressen, Registern, Konstanten usw? Das ist
Unsinn :-(

Wenn schon, dann ein leistungsfähigeres Komprimierungsverfahren.

DoDi

 

[Helmut Schellong]

Am 25.07.2023 um 07:52 schrieb Arno Welzel:

Helmut Schellong, 2023-07-18 11:35:

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.

Und wieso glaubst Du, dass die nicht gegeben ist, wenn die Hardware kein
Xeon 3435X mit 128 RAM ist?

Verstehe ich nicht.
RAM 128 GB bewirkt doch keine Datenkorrektheit.
Hingegen ECC bewirkt Datenkorrektheit.
Der Prozessor verlangt zwingend ECC+Registered RAM.
Da heraus ergibt sich automatisch Datenkorrektheit.

Eine Workstation ist ein typisches Ingenieur-Gerät!

Ach so, Du siehst deine Betätigung an diesem Gerät als die eines
Ingenieurs und nicht als Hobby. Welche Projekte hast Du denn damit
geplant, die nicht nur für Dich privat von Interesse sind?

Ich führe meinen Beruf+Ausbildung als Entwicklungsingenieur als Hobby weiter.
Ist das so schwer nachzuvollziehen?
Gewiß nicht - es ist vollkommen natürlich, daß ich dies tue.

Ich habe aber auch kürzlich für eine Firma in Augsburg
als Entwicklungsingenieur in Rente gearbeitet - mit Versteuerung des Einkommens.
Völlig normal - und staatlich erwünscht!


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 25.07.2023 um 07:55 schrieb Arno Welzel:

Helmut Schellong, 2023-07-18 11:22:

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.

Und was hat das mit Fortschritten im CPU-Design zu tun?

Das mußt Du Marc Haber fragen.
Ist das nicht klar?
Ich habe das Thema Cache hier nicht eingebracht.

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.

Ok, 200 EUR vielleicht nicht, aber ein AMD Ryzen 5 7600 unterstützt
AVX512 und der kostet aktuell ca. 230 EUR. Mit PC drumherum kommt man
sicher mit 400-500 EUR hin.

--
Mit freundlichen Grüßen
Helmut Schellong