CISC besser als RISC?

[p...@pocnet.net]

Moin,

in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit
interessantem Beigeschmack. Der Autor Dirk Hasselhof hatte die Möglichkeit,
hier einen recht dicken Server von AT&T Computer Systems zu testen:
StarServer mit einer der damals zahlreich vorhandenen Portierungen von AT&T
Unix SysV. Siehe hier:

<https://en.wikipedia.org/wiki/AT%26T_Computer_Systems#Servers>

Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu 128
User und 200 Clients bedienen können, mit "nur" "bis zu 4" 486-33 CPUs, max.
einem halben Gigabyte RAM und einem eigenen Bussystem, was gegenüber dem
damals angesagten EISA-Bus der PC-Welt knapp den achtfachen Datendurchsatz
erlaubt.

Der Autor behauptet im weiteren Verlauf, die "Zielvorstellungen,
Hardwarestandards zu verwenden (Intel 80486) und bis zu 328 Benutzer zu
unterstützen, erklären den Einsatz eines CISC-Prozessors. Für
Multiuser-Systeme ist ein CISC-Prozessor geeigneter als die heute
allgegenwärtigen RISC-Prozessoren."

Er untermauert diese Behauptung damit, "dass die SPARCstation 2 im BSD-Test
der SSBA bei forc-Werten deutlich langsamer ist als dieser 486er. Der
BSD-Test ist auf SysV angepasst und beschreibt insgesamt recht gut den
Durchsatz und die Qualität des zugrundeliegenden Unix Derivats.
RISC-Prozessoren sind darauf optimiert, eine Befehlspipe abzuarbeiten und
möglichst je Taktzyklus einen Befehl zu bearbeiten. Dadurch und durch den
restringierten Befehlscode sind RISC-Prozessor-Systeme besonders für
Workstations geeignet, die eher dazu benutzt werden, eine 'Haupt'-Anwendung
zu fahren, ein CAD-Konstruktionsprogramm beispielsweise. Und genauso wie
Vektorrechner ihre speziellen Einsatzgebiete haben, lassen CISC-Systeme bei
Multiuser- und damit Multi-'Anwendungs'-Betrieb eher eine bessere
Performance des Gesamtsystems erwarten."

Für's Protokoll: Ausgabe 07/91 ist m. W. kein Aprilheft. Es gibt keinen
abgedruckten Leserbrief zu diesem Artikel in den Folgeheften.

Mit meiner eher oberflächlichen Kenntnis von CPU-Interna möchte ich mich
nicht zu weit aus dem Fenster lehnen. Aber ein einzelner "Vergleich" scheint
mir doch ein recht dünner Beleg für seine Behauptung zu sein. Seine
Beweisführung über die Optimierung der RISC-CPUs auf einen Befehl pro Takt
empfinde ich als gelinde gesagt als verwirrend. Der Anstand verbietet mir,
deutlichere Worte zu verwenden. :-)

Was hält die Leserschaft hiervon? IBM hätte wohl für ihre damals bereits auf
dem Markt befindliche RS/6000 keine POWER-CPUs verwendet, wenn der Autor mit
seiner Behauptung auch nur ungefähr den Sachverhalt getroffen hätte. IBM ist
m. E. bekannt dafür, an solchen neuralgischen Stellen keine Kompromisse
einzugehen: Lieber noch teurer aber dafür auch mit ordentlich Ompf!
Geschweige denn dass sie 1993/1994 die Hardwarebasis der AS/400 auf RISC
(PowerPC AS) ugestellt hätten, *das* Multiuser-System der "mittleren
Datentechnik" schlechthin.

Ich lehne mich nun zurück und genieße mein Popcorn. :-)

:wq! PoC

[Kay Martinen]

Am 19.03.23 um 14:16 schrieb p...@pocnet.net:

> Moin,
>
> in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit

Liegt dir die Quelle vor? Im Heise Archiv findet sich die iX nur ab
09/94. Die c't gibt es länger.

> Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu 128
> User und 200 Clients bedienen können, mit "nur" "bis zu 4" 486-33 CPUs, max.
> einem halben Gigabyte RAM und einem eigenen Bussystem, was gegenüber dem
> damals angesagten EISA-Bus der PC-Welt knapp den achtfachen Datendurchsatz
> erlaubt.

Nur das die 486 m.E. damals noch nicht wirklich auf ein Multi-CPU System
hin optimiert waren. Da dürfte viel Energie in die Cache-kohärenz
geflossen sein und das nicht eine CPU gegen die anderen arbeitete.

Sonst dürfte auch ein besserer Bus wenig helfen.

Und dann könnte man fragen wie viele Ressourcen damals denn ein
(Terminal?) "User" brauchte und wie viele ein "Client". Wenn man von
einem Netzwerk ausgeht sind 200 Clients eher denkbar als wenn es
Terminal-Anschlüsse an einem System wären. Aber auch das dürfte doch
kein Limit sein oder?

Ich sitze hier als einziger User an einem Multiuser/Multitasking
tauglichen Linux. Aber mit KDE Desktop und fettem unterbau - auf einer
i3 CPU mit 4 Kernen. :-) Vor 30 Jahren war das wohl utopisch - oder nur
per X Terminal machbar? Wäre obiges dann der Server auf dem die
Anwendungen eigentlich liefen?

> Hardwarestandards zu verwenden (Intel 80486) und bis zu 328 Benutzer zu
> unterstützen, erklären den Einsatz eines CISC-Prozessors. Für
> Multiuser-Systeme ist ein CISC-Prozessor geeigneter als die heute
> allgegenwärtigen RISC-Prozessoren."

Ich würde einer CISC CPU eine höhere Leistung zugestehen wenn es darum
geht EIN Programm ohne Störungen (Taskwechsel z.b.) durch zu arbeiten.
Das ginge aber nur mit einem Singletask System denke ich.

Aber: Zählst du oben jetzt 128 User und 200 Clients zu 328 Benutzern
zusammen? Ich denke das paßt nicht.

> RISC-Prozessoren sind darauf optimiert, eine Befehlspipe abzuarbeiten und
> möglichst je Taktzyklus einen Befehl zu bearbeiten. Dadurch und durch den
> restringierten Befehlscode sind RISC-Prozessor-Systeme besonders für
> Workstations geeignet, die eher dazu benutzt werden, eine 'Haupt'-Anwendung
> zu fahren, ein CAD-Konstruktionsprogramm beispielsweise. Und genauso wie
> Vektorrechner ihre speziellen Einsatzgebiete haben, lassen CISC-Systeme bei
> Multiuser- und damit Multi-'Anwendungs'-Betrieb eher eine bessere
> Performance des Gesamtsystems erwarten."

Den Vorteil dieses Konzepts der RISC CPU sehe ich eher darin das die
Taskwechsel in einem Multitasking-System schneller von statten gehen
könnten. Wenn ein Befehl nach einem Takt abgearbeitet ist dann kann man
wechseln. Bei CISC muß man ggf. warten bis der eine Befehl nach X Zyklen
abgearbeitet ist. Oder ihn nach dem Wechsel erneut beenden wenn der
Scheduler hart abbricht.

Bei moderneren CPUs mit Sprungvorhersage u.s.w. ist das vielleicht
entschärft. Aber bei den hier in rede stehenden 486-33 IMHO nicht.

> Für's Protokoll: Ausgabe 07/91 ist m. W. kein Aprilheft. Es gibt keinen
> abgedruckten Leserbrief zu diesem Artikel in den Folgeheften.

Die c't z.b. erscheint 14 Tägig. Damit wäre eine 07/91 der c't schon
eher eine April-Ausgabe (Jan-März=6 Hefte, 07 als Erstes im April). Bei
iX weiß ich nicht ob die auch diese Erscheinungsweise übernahmen.

Die Aprilscherze wurden m.W. auch nicht zwangsläufig durch Leserbriefe
als solche benannt.

> Mit meiner eher oberflächlichen Kenntnis von CPU-Interna möchte ich mich
> nicht zu weit aus dem Fenster lehnen. Aber ein einzelner "Vergleich" scheint
> mir doch ein recht dünner Beleg für seine Behauptung zu sein. Seine
> Beweisführung über die Optimierung der RISC-CPUs auf einen Befehl pro Takt
> empfinde ich als gelinde gesagt als verwirrend.

Wieso denn. Das R steht doch für Reduced, das C in CISC für Complex.
Logischerweise müßte eine RISC CPU ggf. mehrere Befehle brauchen um die
Wirkung eines CISC Befehls zu erreichen. Aber ich weiß dazu auch nicht
genug um mehr zu vermuten als das so was wohl eher für spezielle
Anwendungsfälle in frage käme. FPU-Berechnungen vielleicht?

Ich erinnere mich nur an ein Buch über die 80386 das Kontext- und
Task-Wechsel eben an bestimmte Bedingungen geknüpft sind. Die nicht
unbedingt zum Vorteil der Rechenleistung sind.

OBTW. Der 486(DX) wurde seinerzeit nicht nur mit der eingebauten FPU
beworben. Sondern auch damit das er viele Befehle schneller (idealfall:
nur ein Takt) ausführte. War er damit nicht der Erste der CISC durch
internes RISC ersetze? :-)

> Geschweige denn dass sie 1993/1994 die Hardwarebasis der AS/400 auf RISC
> (PowerPC AS) ugestellt hätten, *das* Multiuser-System der "mittleren
> Datentechnik" schlechthin.

Naja. Der IBM PC war ja auch nicht unbedingt ein Leuchtfeuer der
Spitzenleistung. Ich vermute der Artikel ist entweder ein
nicht-bekannter Aprilscherz oder schlichtweg daneben gewesen.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Peter J. Holzer]

On 2023-03-19 13:16, p...@pocnet.net <p...@pocnet.net> wrote:
> in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit
> interessantem Beigeschmack. Der Autor Dirk Hasselhof hatte die Möglichkeit,
> hier einen recht dicken Server von AT&T Computer Systems zu testen:
> StarServer mit einer der damals zahlreich vorhandenen Portierungen von AT&T
> Unix SysV. Siehe hier:
>
><https://en.wikipedia.org/wiki/AT%26T_Computer_Systems#Servers>
>
> Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu 128
> User und 200 Clients bedienen können, mit "nur" "bis zu 4" 486-33 CPUs, max.
> einem halben Gigabyte RAM und einem eigenen Bussystem, was gegenüber dem
> damals angesagten EISA-Bus der PC-Welt knapp den achtfachen Datendurchsatz
> erlaubt.

Das ist plausibel. Wir hatten (ein paar Jahre später) durchaus ähnliche
User-Zahlen. Zwar auf PA-RISC, aber mit weniger CPUs und weniger RAM -
und die User haben alle ein GUI verwendet.

Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU im
Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann man das
jedenfalls nicht begründen, denn der 486er hatte auch eine. Allenfalls
könnte der CPU-State kleiner (weniger Register) und dadurch ein
Kontext-Switch schneller gewesen sein. Aber WIMRE war die
x86-Architektur nicht gerade für schnelle Kontext-Switches bekannt.
Im wesentlichen läuft seine Argumentation auf "RISC ist bei X schneller,
also muss CISC bei nicht-X schneller sein" hinaus.

Ich vermute, dass der gute Mann einfach von der Marketing-Broschüre
abgeschrieben hat.

hp

[Hermann Riemann]

Die Frage ist nach micro code und Speicher.

Register und gewiss Arten von cache sind beide SRAM,
die gleiche Geschwindigkeit haben können.

Und Befehle werden per pipeline in micro code
übersetzt, so das einige sogar parallel ausgeführt werden können.

CISC braucht weniger DRAM und können daher
bei großen Programmen wegen Transferzeiten schneller sein.

RISC kann wegen weniger Rechenschritte weniger Energie verbrauchen.

Mischen bzw. Übergangsformen gehen auch.

Hermann
vermutend, das intel das Wissen von DEC alpha
mehr oder weniger ausgenutzt hat.

--
http://www.hermann-riemann.de

[p...@pocnet.net]

Peter J. Holzer <hjp-u...@hjp.at> wrote:

> Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU im
> Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann man das
> jedenfalls nicht begründen, denn der 486er hatte auch eine.

Gut, dann scheine ich mit meiner ähnlichen Einschätzung nicht ganz falsch zu
liegen.

> Im wesentlichen läuft seine Argumentation auf "RISC ist bei X schneller,
> also muss CISC bei nicht-X schneller sein" hinaus.

Schön zusammengefasst. Wobei diese Zusammenfassung der Logik nach ja durchaus
nachvollziehbar ist. Wie sehr sich das in der Praxis äußert ist die andere
Frage.

:wq! PoC

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

>> in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit
>
> Liegt dir die Quelle vor?

Ja.

> Nur das die 486 m.E. damals noch nicht wirklich auf ein Multi-CPU System
> hin optimiert waren. Da dürfte viel Energie in die Cache-kohärenz
> geflossen sein und das nicht eine CPU gegen die anderen arbeitete.

Ersteres weiss ich nicht, letzteres wurde im Artikel nicht erwähnt.

> Sonst dürfte auch ein besserer Bus wenig helfen.

Dieser Bus bezog sich vermutlich nur auf die Anbindung der Peripherie.

> Ich würde einer CISC CPU eine höhere Leistung zugestehen wenn es darum
> geht EIN Programm ohne Störungen (Taskwechsel z.b.) durch zu arbeiten.
> Das ginge aber nur mit einem Singletask System denke ich.

Warum?

> Aber: Zählst du oben jetzt 128 User und 200 Clients zu 328 Benutzern
> zusammen? Ich denke das paßt nicht.

Das Zusammenzählen ist bereits im Artikel erfolgt. Ich habe dies 1:1 zitiert.

> Den Vorteil dieses Konzepts der RISC CPU sehe ich eher darin das die
> Taskwechsel in einem Multitasking-System schneller von statten gehen
> könnten. Wenn ein Befehl nach einem Takt abgearbeitet ist dann kann man
> wechseln. Bei CISC muß man ggf. warten bis der eine Befehl nach X Zyklen
> abgearbeitet ist. Oder ihn nach dem Wechsel erneut beenden wenn der
> Scheduler hart abbricht.

Bei dem verwendeten 486 mit 33 MHz war die Zykluszeit bei ca. 30 ns. Selbst
komplexe Befehle wie Wurzelziehen, die meinetwegen 100 Zyklen bräuchten, sind
damit noch immer in wenigen µs abgearbeitet und wirken sich m. E. nicht auf
das Multitasking per se aus.

Kein mir bekannter Scheduler arbeitet mit derart kleinen Zeitfenstern. Wenn
ich nach einem CPU-Befehl den nächsten Task drankommen lasse, wird ja auch ein
Großteil der Caches mit neuen Befehlen überschrieben.

Ich denke daher nicht, dass Dein Argument sticht. :-)

> Die c't z.b. erscheint 14 Tägig. Damit wäre eine 07/91 der c't schon
> eher eine April-Ausgabe (Jan-März=6 Hefte, 07 als Erstes im April). Bei
> iX weiß ich nicht ob die auch diese Erscheinungsweise übernahmen.

Die iX erscheint seit langer Zeit monatlich, das tut sie noch heute. iX und
c't miteinander zu vergleichen bringt an der Stelle nichts.

> Wieso denn. Das R steht doch für Reduced, das C in CISC für Complex.
> Logischerweise müßte eine RISC CPU ggf. mehrere Befehle brauchen um die
> Wirkung eines CISC Befehls zu erreichen.

Wenn das die ganze Wahrheit wäre, bräuchte man kein RISC. So wie ich das
verstanden habe, sind RISC-CPUs zwar eingeschränkter was den Befehlssatz
betrifft, aber die vorhandenen Befehle werden im Regelfall in sehr wenigen
Zyklen abgeschlossen, was bei CISC-CPUs eher nicht der Fall sein soll. Das
Versprechen damals war, dass die RISC-CPUs im Schnitt schneller wären als die
CISC-Pendants, weil komplexe Befehle vergleichsweise selten im
"haushaltsüblichen" Programmcode vorhanden wären. Diese müsste man den
Compiler in die einzelnen RISC-Opcodes zerlegen lassen, die aber wiederum in
RISC-manier in wenigen Zyklen abgeabeitet wären und damit nur unwesentlich
langsamer im Vergleich zu einer CISC-Implementation wären. Die meisten anderen
Befehle würden von der RISC-CPU in weniger Taktzyklen abgearbeitet im
Vergleich zu einer CISC-Implementation.

Das RISC-Konzept erwuchs aus einer Studie von IBM (!), die existierenden Code
untersucht hatten:

---8<---

The design was based on a study of IBM's extensive collection of statistics
gathered from their customers. This demonstrated that code in high-performance
settings made extensive use of processor registers, and that they often ran
out of them. This suggested that additional registers would improve
performance. Additionally, they noticed that compilers generally ignored the
vast majority of the available instructions, especially orthogonal addressing
modes. Instead, they selected the fastest version of any given instruction and
then constructed small routines using it. This suggested that the majority of
instructions could be removed without affecting the resulting code. These two
conclusions worked in concert; removing instructions would allow the
instruction opcodes to be shorter, freeing up bits in the instruction word
which could then be used to select among a larger set of registers.

---8<---

Quelle:
<https://en.wikipedia.org/wiki/Reduced_instruction_set_computer#IBM_801>

> OBTW. Der 486(DX) wurde seinerzeit nicht nur mit der eingebauten FPU
> beworben. Sondern auch damit das er viele Befehle schneller (idealfall:
> nur ein Takt) ausführte. War er damit nicht der Erste der CISC durch
> internes RISC ersetze? :-)

In der iX und den c't Heften aus der Ära wird tatsächlich in mehreren Artikeln
genau das behauptet.

>> Geschweige denn dass sie 1993/1994 die Hardwarebasis der AS/400 auf RISC
>> (PowerPC AS) ugestellt hätten, *das* Multiuser-System der "mittleren
>> Datentechnik" schlechthin.
>
> Naja. Der IBM PC war ja auch nicht unbedingt ein Leuchtfeuer der
> Spitzenleistung.

Das war 10 Jahre vorher. Was erwartest Du?

Zudem war IBM-PC war alles, aber keine echte IBM-Entwicklung. Du vergleichst
gerade Äpfel (PC-Technik) mit Birnen (Server-Technik). :-)

[...] a proposal by Lowe that by forming an independent internal working group
and abandoning all traditional IBM methods, a design could be delivered within
a year and a prototype within 30 days.

vs.

The public responded to these rumors with skepticism, owing to IBM's tendency
towards slow-moving, bureaucratic business practices tailored towards the
production of large, sophisticated and expensive business systems. As with
other large computer companies, its new products typically required about four
to five years for development, and a well publicized quote from an
industry analyst was, "IBM bringing out a personal computer would be like
teaching an elephant to tap dance."

Quelle: <https://en.wikipedia.org/wiki/IBM_Personal_Computer#History>

> Ich vermute der Artikel ist entweder ein nicht-bekannter Aprilscherz oder
> schlichtweg daneben gewesen.

Nicht unbedingt der ganze Artikel, aber die zitierte Behauptung finde ich
schon abenteuerlich in ihrer Begründung. Ich scheine mit dieser Einschätzung
nicht alleine zu sein.

:wq! PoC

[Peter J. Holzer]

On 2023-03-19 15:26, p...@pocnet.net <p...@pocnet.net> wrote:

> Kay Martinen <use...@martinen.de> wrote:
>> Wieso denn. Das R steht doch für Reduced, das C in CISC für Complex.
>> Logischerweise müßte eine RISC CPU ggf. mehrere Befehle brauchen um die
>> Wirkung eines CISC Befehls zu erreichen.
>
> Wenn das die ganze Wahrheit wäre, bräuchte man kein RISC. So wie ich das
> verstanden habe, sind RISC-CPUs zwar eingeschränkter was den Befehlssatz
> betrifft,

Das stimmt zwar, aber John Mashey (seinerzeit Maintainer der RISC-FAQ
und wenn ich mich recht erinnere auch Autor des MIPS-Backends für den
GCC) hat gerne argumentiert, dass das "R" eigentlich für "Regular"
stehen sollte. Das war tatsächlich ein großer Unterschied zu vielen
CISC-Prozessoren damals: Die "komplexen" Instruktionen haben oft nur mit
bestimmten Registern funktioniert (z.B. bei 8086 stand das Ergebnis
einer Multiplikation immer in DX:AX, Ein REP-Intruktion nahm den Count
immer aus CX, ein MOVS die Source-Adresse aus SI und die
Destination-Adresse aus DI). Es gab aber auch sehr regelmäßige
CISC-ISAs, wie z.B. VAX.

> aber die vorhandenen Befehle werden im Regelfall in sehr wenigen
> Zyklen abgeschlossen, was bei CISC-CPUs eher nicht der Fall sein soll. Das
> Versprechen damals war, dass die RISC-CPUs im Schnitt schneller wären als die
> CISC-Pendants, weil komplexe Befehle vergleichsweise selten im
> "haushaltsüblichen" Programmcode vorhanden wären.

Was sie unter anderem deshalb nicht waren, weil Compiler sie nicht
erzeugt haben. Die waren für Compiler zu kompliziert und kamen
eigentlich nur in handgeschriebenem Assembler vor.

(Der Vollständigkeit halber sollte ich erwähnen, dass einige frühe RISCs
auch einige recht grundlegende Operationen wie MUL und DIV nicht kannten
- die kamen natürlich in compilergeneriertem Code schon vor.)

> Diese müsste man den Compiler in die einzelnen RISC-Opcodes zerlegen
> lassen,

Der Compiler muss nichts zerlegen - nur nicht erzeugen (was er eh nicht
macht).

> die aber wiederum in RISC-manier in wenigen Zyklen abgeabeitet wären
> und damit nur unwesentlich langsamer im Vergleich zu einer
> CISC-Implementation wären. Die meisten anderen Befehle würden von der
> RISC-CPU in weniger Taktzyklen abgearbeitet im Vergleich zu einer
> CISC-Implementation.

Und nicht zu vergessen:

* Das einfachere Design ermöglichte höhere Taktfrequenzen
* Des regelmäßige Instruction Set machte es wesentlich einfacher,
Compiler zu schreiben, die effizienten Code erzeugen.

Wer sich für die Designprizipien und Grundlagen von RISC-Prozessoren
(bzw. Prozessoren im Allgemeinen, aber der Schwerpunkt liegt auf Grund
der Autoren und des Erscheinungsjahrs bei RISC) interessiert, dem sei
"Computer Architecture - A Quantitative Approach" von Hennessy und
Patterson (1. Auflage 1990, 6. Auflage 2017) ans Herz gelegt.

hp

[p...@pocnet.net]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Die Anzahl der "User" spielt bei der Betrachtung auf Betriebssystemebene
> und drunter keine Rolle. Das ist dort einfach nur Multitasking.

Der Artikel sollte durchaus die Gesamtperformance des Systems aufzeigen. Mehr
User = mehr RAM, bzw. mehr Paging.

>> Für Multiuser-Systeme ist ein CISC-Prozessor geeigneter als die heute
>> allgegenwärtigen RISC-Prozessoren."
>

> So was kann man behaupten. Ich sehe keine Belege, damals nicht, nachträglich
> und heute genausowenig.

Danke für Deine Einschätzung.

>> Dadurch und durch den restringierten Befehlscode sind
>> RISC-Prozessor-Systeme besonders für Workstations geeignet, die eher dazu
>> benutzt werden, eine 'Haupt'-Anwendung zu fahren, ein
>> CAD-Konstruktionsprogramm beispielsweise.
>

> Auch das war und ist ein Multitasking-System. Wo liegt der Unterschied
> zu Multi User?

Eine berechtige Frage. Möglicherweise weil eine "Workstation" eben nur eine
'Haupt'-Anwendung verwalten muss? Unterbrechungen durch andere Tasks dürften
da vergleichsweise selten sein.

>> IBM hätte wohl für ihre damals bereits auf dem Markt befindliche RS/6000
>> keine POWER-CPUs verwendet, wenn der Autor mit seiner Behauptung auch nur
>> ungefähr den Sachverhalt getroffen hätte.
>

> IBM war einer der beiden Großen der PowerPC-Entwicklung. Wenn IBM auf eine
> andere Architektur geschwenkt wäre, wäre der PPC damals tot gewesen.

Das ist die monetäre Betrachtung. Mir ging es eher um den technischen
Sachverhalt.

:wq! PoC

[Kay Martinen]

Am 19.03.23 um 18:04 schrieb p...@pocnet.net:

> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>
>> Die Anzahl der "User" spielt bei der Betrachtung auf Betriebssystemebene
>> und drunter keine Rolle. Das ist dort einfach nur Multitasking.
>
> Der Artikel sollte durchaus die Gesamtperformance des Systems aufzeigen. Mehr
> User = mehr RAM, bzw. mehr Paging.

Natürlich wird der RAM Bedarf steigen wenn mehr User (gleichzeitig)
online sind. Um das abschätzen zu können müsste man wissen wie viel RAM
das dortige OS pro User braucht oder reserviert. Und wie viel es für
sich braucht.

Und Paging ist doch eher ein Interner Weg zu sagen "Den Teil brauch ich
grad nicht im RAM, der kann raus" wenn man eh schon den Speicher in
feste Seitengrößen aufgeteilt hat. Nebenbei hängt das Schutzkonzept auch
da mit drin. Also Codeseiten als RO, Datenseiten als RW markieren. Ab
386 gab es da ein Granularity-Bit das IMO die Seitengröße steuert.
Funktioniert im Protected-Mode also nicht mit DOS. ;)

>>> RISC-Prozessor-Systeme besonders für Workstations geeignet, die eher dazu
>>> benutzt werden, eine 'Haupt'-Anwendung zu fahren, ein
>>> CAD-Konstruktionsprogramm beispielsweise.
>>
>> Auch das war und ist ein Multitasking-System. Wo liegt der Unterschied
>> zu Multi User?

Workstation: Nur EIN Benutzer zur Zeit angemeldet, Client am Netzwerk.
Server: KEIN lokaler Benutzer, aber viele gleichzeitig vom Netzwerk aus.
Können aber Beides Multi User Systeme sein. ?

> Eine berechtige Frage. Möglicherweise weil eine "Workstation" eben nur eine
> 'Haupt'-Anwendung verwalten muss? Unterbrechungen durch andere Tasks dürften
> da vergleichsweise selten sein.

Seltener als beim einem Server auf dem schlimmstenfalls das gleiche
Multitasking OS läuft wie auf der Workstation. Der Server nutzt es nur
anders, dort läuft selten ein Gimp es sei denn als X Anwendung.

Ich denke nicht das man genau EIN Programm in einem OS als
Haupt-Anwendung ansehen kann. IMHO konnte/kann man zwar einem Prozess
höhere Priorität zuordnen (nice) oder ihn auch auf genau einen CPU Kern
festnageln (pinning?) aber damit ist er immer noch nur ein Programm von
vielen die das Multitasking-OS immer wieder abwechselnd ausführt.

Und was man dem einen Programm an mehr zuschanzt fehlt ggf. dann den
anderen. Und das ändert sich ja nicht. Heute ist nur die Gesamtleistung
höher als bei einem "vier mal 486-33" Setup.

Was sich ggf. Ändern könnte: Wenn diese eine spezielle Anwendung
intensiven Gebrauch von CISC Befehlen machte - auf einem Kern. Dann
könnte sie evtl. schneller sein als ein Kompilat der Gleichen Anwendung
das die nicht nutzt - oder RISC Pendants nutzen will. Meine Vermutung!

Gab es nicht das gleiche Gewese auch später mit Programmen die optimiert
waren auf MMX, SSE oder Multithreading oder akt. AES-NI. Alles um den
Durchsatz, die Leistung zu steigern. Kurz: um Schneller Fertig zu
werden. Sind alles auch Befehlssatz-erweiterungen oder?

Ist aus dem anfänglichen RISC damit nicht heute effektiv doch wieder ein
CISC geworden?

[Sebastian Barthel]

Am Sun, 19 Mar 2023 14:54:01 +0000 schrieb poc:

> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>
>> Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU im
>> Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann man das
>> jedenfalls nicht begründen, denn der 486er hatte auch eine.
>
> Gut, dann scheine ich mit meiner ähnlichen Einschätzung nicht ganz
> falsch zu liegen.

Mit der Pipeline kann man sehr schön eine Verlangsamung bei Taskwechseln
begründen. Insebesondere dann, wenn die Pipeline sehr lang ist wird das
auch meßbar (im direkten Vergleich innerhalb gleicher Architektur, sehr
schön zu sehen z.B. bei StrongARM vs. normal-ARM (610, 710 oder gar ARM 2
oder 3). Begründung: die gefüllte Pipeline wird verworfen und dann erstmal
wieder gefüllt. ZUmindest habe ich das als Begründnung so in Erinnering.
Ob das dann passiert, weil das ein normaler Taskwechsel ist oder weil das
ein Userwechsel ist, wird der CPU völlig egal sein. Wenn CISC und RISC
beide sowas haben, sollte man m.E. da keinen Unterschied sehen (also z.B.
486/586 vs PPC).

Interessanter für User/Taskwechsel dürfte sein, wieviel und welches Cache-
RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen
parken kann und nicht zuviele "User" da sind, dürfte man das ziemlich
deutlich merken.

[Sebastian Barthel]

Am Sun, 19 Mar 2023 15:26:25 +0000 schrieb poc:

> Kay Martinen <use...@martinen.de> wrote:
>
>>> in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit
>>

> ...

Genau so kann man das schreiben, wenn man sich entscheiden muß, ob man
nun im Opcode ein Bit für die zusätzliche Instruktion oder lieber für ein
Register (oder vielleicht ein Flag) vergibt. Das Problem hat man aber
auch nur, wenn man über 8 oder 16 Bit redet. Wenn die damals gleich it 32
Bit oder 64 Bit angefangen hätten, wäre die niemals in dieses Problem
gelaufen, weil man dann irgendwann eher in die "Erschöpfung" läuft, weil
man nicht mehr weiß, welche sinnvollen Operationen man sich noch
ausdenken könnte. Und der normale Durchschnittsprogrammierer kommt
wahrscheinlich immer gut mit 8 Registern hin. (Menschen können sich ja
üblicherweise nur 7 Dinge gleichzeitig merken, das wußten schon die alten
Alchemisten.)


Ein wichtiger Punkt, der für mein Dafürhalten bei RISC ganz(!) wichtig
ist, steht da oft nicht so explizit in solchen Begründungen drin,
nämlich: RISC erlaubt schlicht keine Zugriffe aufs RAM, außer Register
laden und speichern (Load/Store Architektur). Und das wiederum zwingt den
Programmierer - egal ob menschlicher oder maschineller (Compiler) - dazu,
möglichst alles und dann eben auch gleich möglichst viel hintereinander
in einem Register bzw in den Registern zu rechnen. Und DAS wiederum ist
VIEL schneller, als wenn die CPU zwischendurch eben doch immer mal aufs
RAM zugreift.


Der andere für die Zeit wesentliche Punkt ist, daß es mit den
abgespeckten Befehlssätzen überhaupt erst möglich wird, sinnvolle
Compiler zu bauen, die an Menschen herankommen. Nicht umsonst war
Programmiererei vorher ja sowas wie eine "schwarze Kunst".

Gerade solche Sachen wie einen nicht vorhandenen Multipikationsbefehl
immer durch eine geeignete Reihenfolge von Additionen zu ersetzen, macht
doch schon ein passendes Assemblermacro ziemlich gut. Wenns bißchen
geschickt gebaut ist, fragt es vorher noch bißchen was ab (etwa ob man
gerade mit 2,4,8,16 multipiliziert).

Und zu den "Extensions" (Multimedia, Vektorprozessor): Ohne wirklich
Ahnung davon zu haben, aber die laufen doch eigentlich parallel und sind
quasi nur Seitenarme die halt auf die 16 Register oder so zugreifen und
dann das Ergebnis wieder dahin zurückschreiben. Eigentlich schalten die
sich doch nicht in den eigentlichen Signalverlauf in so einer CPU ein.
Daher kann man, wenn das so stimmt, aber nicht davon reden, daß dadurch
aus einem RISC wieder ein CISC wird. Es sind halt echte Extras. Ungefähr
so, wie wenn man aller 4 oder 5 Register (passend zu nötingen Bitbreite
für float) eine Floatingpointeinheit hat/hätte.


Gruß, SBn

[Kay Martinen]

Am 19.03.23 um 21:11 schrieb Sebastian Barthel:

> Am Sun, 19 Mar 2023 14:54:01 +0000 schrieb poc:
>
>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>
>>> Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU im
>>> Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann man das
>>> jedenfalls nicht begründen, denn der 486er hatte auch eine.
>>
>> Gut, dann scheine ich mit meiner ähnlichen Einschätzung nicht ganz
>> falsch zu liegen.
>
> Mit der Pipeline kann man sehr schön eine Verlangsamung bei Taskwechseln
> begründen. Insebesondere dann, wenn die Pipeline sehr lang ist wird das

Eine Pipeline ist doch eher die aneinander Reihung von

- Nächsten Befehl holen
- Befehl dekodieren
- Operanden holen

um das sofort (in einem Takt) parat zu haben wenn der laufende Befehl
seine Arbeit erledigt hat - und alles (in caches) weg geschrieben hat.

Der Cache dürfte der pipeline vorgeschaltet sein.
Und war beim 486 8-16 kB groß und das für Daten und code gleichermaßen.
Erst mit Pentium (Slot) oder Pro kamen Größere (aufgeteilte) Cache in
das CPU-Gehäuse/Package die mit CPU-Takt laufen konnten. Und spekulative
Ausführung, TLB u.a. auch erst dann.

Wenn der Task-wechsel also angestoßen ist dann dürfte auch alles was
bisher in der pipeline vor-dekodiert wurde nicht mehr gültig sein und
verworfen werden.

> ein Userwechsel ist, wird der CPU völlig egal sein. Wenn CISC und RISC
> beide sowas haben, sollte man m.E. da keinen Unterschied sehen (also z.B.
> 486/586 vs PPC).

Ich zweifele ob man PPC und 486/586 so vergleichen kann.

> Interessanter für User/Taskwechsel dürfte sein, wieviel und welches Cache-
> RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen
> parken kann und nicht zuviele "User" da sind, dürfte man das ziemlich
> deutlich merken.

Übersiehst du da nicht das bei einem Taskwechsel auch der im Cache
vorgehaltene inhalt nicht mehr gültig sein kann - weil nach dem wechsel
ja anderer code geladen werden muß.

Wenn da noch teile vom alten Kontext/Task im Cache liegen weil das
Register o.a. sind die weg geschrieben werden müssen dann wäre es blöd
den cache komplett zu invalidieren oder? Da wird man wohl warten müssen.

[Sebastian Barthel]

Am Sun, 19 Mar 2023 22:01:13 +0100 schrieb Kay Martinen:

> Am 19.03.23 um 21:11 schrieb Sebastian Barthel:
>> Am Sun, 19 Mar 2023 14:54:01 +0000 schrieb poc:
>>
>>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>>
>>>> Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU
>>>> im Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann
>>>> man das jedenfalls nicht begründen, denn der 486er hatte auch eine.
>>>
>>> Gut, dann scheine ich mit meiner ähnlichen Einschätzung nicht ganz
>>> falsch zu liegen.
>>
>> Mit der Pipeline kann man sehr schön eine Verlangsamung bei
>> Taskwechseln begründen. Insebesondere dann, wenn die Pipeline sehr lang
>> ist wird das
>
> Eine Pipeline ist doch eher die aneinander Reihung von
>
> - Nächsten Befehl holen - Befehl dekodieren - Operanden holen
>
> um das sofort (in einem Takt) parat zu haben wenn der laufende Befehl
> seine Arbeit erledigt hat - und alles (in caches) weg geschrieben hat.
>
> Der Cache dürfte der pipeline vorgeschaltet sein.
> Und war beim 486 8-16 kB groß und das für Daten und code gleichermaßen.
> Erst mit Pentium (Slot) oder Pro kamen Größere (aufgeteilte) Cache in
> das CPU-Gehäuse/Package die mit CPU-Takt laufen konnten. Und spekulative
> Ausführung, TLB u.a. auch erst dann.
>
> Wenn der Task-wechsel also angestoßen ist dann dürfte auch alles was
> bisher in der pipeline vor-dekodiert wurde nicht mehr gültig sein und
> verworfen werden.

Ja, genau so. Und wenn man das so macht, dann ist die ganz Pipeline leer
und man muß erstmal (Länge der Pipeline -1) Takte warten bis überhaupt
wieder was gerechnet wird. Da die Pipelines durchaus auch noch
"kleinteiliger" werden, sind das am Ende dann durchaus auch mal 5 Takte
oder 12 oder ... keine Ahung, wie lange heutzutage sowas ist und was da
alle drin passiert, nacheinander.

Genau aus dem Grund wurde ja Sprungvorhersage auch so interessant. Wenn
man das korrekt vorhersagt, dann kann man die Pipeline behalten und läuft
mit einem Befehl pro Takt weiter. Wenn nicht zerstört das die Statistik.
Wenn man es gar nicht macht, wirft man quasi bei jedem IF THEN die
Pipeline weg und wartet.

>> ein Userwechsel ist, wird der CPU völlig egal sein. Wenn CISC und RISC
>> beide sowas haben, sollte man m.E. da keinen Unterschied sehen (also
>> z.B. 486/586 vs PPC).
>
> Ich zweifele ob man PPC und 486/586 so vergleichen kann.

Na ja - man kann schon. Muß halt Tests machen. Dann kann man sowas wie
VAX-MIPS ausrechnen und vergleicht, oder man macht Anwendungstests - wo
dann da komplett andere Ergebnis herauskommen kann.

Das Thema ist ja bis heute quasi ungelöst - guck Dir mal die Spieltests
bei den RTX Grafikkarten an. Die Vorhersagen und das erzielte Ergebnis
sind da manchmal schon weit auseinander. Und manchmal liegt es an so
"simplen" Sachen, daß jemand im BIOS das DualChannel Memory nicht
angeschaltet hat, aber ein Game testet, was davon profitiert.

>> Interessanter für User/Taskwechsel dürfte sein, wieviel und welches
>> Cache-
>> RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen
>> parken kann und nicht zuviele "User" da sind, dürfte man das ziemlich
>> deutlich merken.
>
> Übersiehst du da nicht das bei einem Taskwechsel auch der im Cache
> vorgehaltene inhalt nicht mehr gültig sein kann - weil nach dem wechsel
> ja anderer code geladen werden muß.
>
> Wenn da noch teile vom alten Kontext/Task im Cache liegen weil das
> Register o.a. sind die weg geschrieben werden müssen dann wäre es blöd
> den cache komplett zu invalidieren oder? Da wird man wohl warten müssen.

Wenn der Cache groß genug ist, wird der doch auch "pageweise" verwaltet.
Dann wird der auch nicht komplett verworfen und der Task findet seine
Sachen ganz schnell wieder, wenn er wieder aktiviert wird.

Die HP PA-RISC Sachen haben genau das am Anfang benutzt und massenweise L1
Cache mitgebracht.


Gruß,
SBn

[Sebastian Barthel]

Am Sun, 19 Mar 2023 13:16:18 +0000 schrieb poc:

> Moin,
>
> in iX 07/1991 gibt es ab Seite 32 einen Artikel "Oberweite 128" mit
> interessantem Beigeschmack. Der Autor Dirk Hasselhof hatte die
> Möglichkeit, hier einen recht dicken Server von AT&T Computer Systems zu
> testen:
> StarServer mit einer der damals zahlreich vorhandenen Portierungen von
> AT&T Unix SysV. Siehe hier:
>
> <https://en.wikipedia.org/wiki/AT%26T_Computer_Systems#Servers>
>
> Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu
> 128 User und 200 Clients bedienen können, mit "nur" "bis zu 4" 486-33
> CPUs, max. einem halben Gigabyte RAM und einem eigenen Bussystem, was
> gegenüber dem damals angesagten EISA-Bus der PC-Welt knapp den
> achtfachen Datendurchsatz erlaubt.
>
> Der Autor behauptet im weiteren Verlauf, die "Zielvorstellungen,
> Hardwarestandards zu verwenden (Intel 80486) und bis zu 328 Benutzer zu
> unterstützen, erklären den Einsatz eines CISC-Prozessors. Für
> Multiuser-Systeme ist ein CISC-Prozessor geeigneter als die heute
> allgegenwärtigen RISC-Prozessoren."

... popcorn


Man findet zu dem AT&T StarServer irgendwie auch überhaupt nichts im www.

Lediglich das vermutliche Nachfolgegerät, von dem im Wikipedia Artikel
gesagt wird, daß der StarServer E nochmal 11% "besser" ist, läßt sich
einfach finden.


NCR 3450

dort Seite 9 (15 im PDF)
<https://www.1000bit.it/js/web/viewer.html?file=%2Fad%2Fbro%2Fncr%2Fncr%
5Fproducts%5F1991%2Epdf#zoom=page-fit>

und da auf Seite 3
<https://www.1000bit.it/js/web/viewer.html?file=%2Fad%2Fbro%2Fncr%
2Fncr3000overview%2Epdf#zoom=page-fit>



außerdem, wg. dem Popcorn, das als lustig Infoseite
<https://www.1000bit.it/js/web/viewer.html?file=%2Fad%2Fbro%2Fncr%2Fncr%
2Dcommitment2opensystems%2Epdf#zoom=page-fit>


"Enhanced MicroChannel" ist aber wohl letztlich das Schlagwort, um daß es
beim Geschwindigkeitsvorteil eigentlich geht.

[Peter J. Holzer]

On 2023-03-19 21:31, Sebastian Barthel <nait...@freenet.de> wrote:
> Am Sun, 19 Mar 2023 22:01:13 +0100 schrieb Kay Martinen:
>> Am 19.03.23 um 21:11 schrieb Sebastian Barthel:
>>> Am Sun, 19 Mar 2023 14:54:01 +0000 schrieb poc:
>>>> Peter J. Holzer <hjp-u...@hjp.at> wrote:
>>>>> Geht mir auch so. Es ist vollkommen unbegründet, warum eine CISC-CPU
>>>>> im Multi-User-Betrieb schneller sein sollte. Mit der Pipeline kann
>>>>> man das jedenfalls nicht begründen, denn der 486er hatte auch eine.
>>>>
>>>> Gut, dann scheine ich mit meiner ähnlichen Einschätzung nicht ganz
>>>> falsch zu liegen.
>>>
>>> Mit der Pipeline kann man sehr schön eine Verlangsamung bei
>>> Taskwechseln begründen. Insebesondere dann, wenn die Pipeline sehr lang
>>> ist wird das
>>
>> Eine Pipeline ist doch eher die aneinander Reihung von
>>
>> - Nächsten Befehl holen - Befehl dekodieren - Operanden holen
>>
>> um das sofort (in einem Takt) parat zu haben wenn der laufende Befehl
>> seine Arbeit erledigt hat - und alles (in caches) weg geschrieben hat.

Das ist eine etwas verwirrende Beschreibung. Was die Pipeline macht, ist
die Phasen verschiedener Instruktionen zu überlappen. Wenn man also z.B.
4 Phasen hat (Fetch, Decode, Execute, Store - bei frühen RISCs ziemlich
üblich), dann wird während Instruktion n das Ergebnis speichert,
Instruktion n+1 ausgeführt, n+2 dekodiert und n+3 gelesen.

>> Wenn der Task-wechsel also angestoßen ist dann dürfte auch alles was
>> bisher in der pipeline vor-dekodiert wurde nicht mehr gültig sein und
>> verworfen werden.
>
>
> Ja, genau so. Und wenn man das so macht, dann ist die ganz Pipeline leer
> und man muß erstmal (Länge der Pipeline -1) Takte warten bis überhaupt
> wieder was gerechnet wird. Da die Pipelines durchaus auch noch
> "kleinteiliger" werden, sind das am Ende dann durchaus auch mal 5 Takte
> oder 12 oder ... keine Ahung, wie lange heutzutage sowas ist und was da
> alle drin passiert, nacheinander.

In jedem Fall ziemlich vernachlässigbar im Vergleich zu den hunderten
Takten, die der Taskwechsel insgesamt kostet. Und die Pipelines der
damals aktuellen RISC-Prozessoren waren ziemlich kurz, da wird die des
486 nicht viel kürzer gewesen sein (eher länger).

hp

[Michael Kraemer @ home]

Ralf Kiefer wrote:
> <p...@pocnet.net> wrote:
>
> Ich sehe darin genausowenig einen Beweis. Bedenke, daß zu jener Zeit
> RISC ein Hype war, an den jeder glauben sollte. Daher mußte es
> verbreitet werden.

Naja, der hype war halt real.
Die damaligen RISCs versaegten so ziemlich alles,
was damals als CISC auf dem Markt war (x86,68k,VAX).
Das konnte man messen.
Besonders "demuetigend" war das im Falle des POWER1.
Der ist noch nichtmal ein Single-Chip-"Kaefer" sondern eine Steckkarte
von der Groesse eines MCA-Boards mit 6 oder 7 chips drauf.
Mit schlaffen 25MHz zog der Kreise um alles andere.

Meine erste RS/6000 brachte praktisch die Rechenleistung eines mainframes
aus dem selben Hause auf den Schreibtisch.
Mit super Grafik und einem - sagen wir mal - entgegenkommenderen OS.
Zu einem hundertstel des Preises.

> Schon wenige Jahre danach konnte die 68060-CPU als klassischer Vertreter
> der CISC-Welt mehrere Befehle gleichzeitig und ggf. innerhalb desselben
> Zyklus abarbeiten.

Superskalar war der aber nur bei Integer-Operationen,
Zahlenfresser lieben aber Multiply-and-Add in Floatingpoint.
Ausserdem hoerte dessen Taktfrequenz bei 50Mhz (fuer die Vollvariante) auf.
Da fingen die RISCs grade erst an.

Leider gab es keine echten 68060-Workstations
(wenn man mal vom Exoten DraCo absieht).
Ein vmtl eher schwacher Ersatz waren Amigas mit 060er Turbokarte.
Meiner wurde jedenfalls schon von PPC601 workstations locker abgehaengt.
Dabei erzeugte der damals verfuegabre SAS/C compiler
schon optimierten 060er code.

>>IBM hätte wohl für ihre damals bereits auf
>>dem Markt befindliche RS/6000 keine POWER-CPUs verwendet,

Sondern?
RS6ks sind/waren die Existenzberechtigung fuer POWER.

>>wenn der Autor mit
>>seiner Behauptung auch nur ungefähr den Sachverhalt getroffen hätte.
>

> IBM war einer der beiden Großen der PowerPC-Entwicklung. Wenn IBM auf
> eine andere Architektur geschwenkt wäre, wäre der PPC damals tot
> gewesen.

Diese Gefahr bestand nicht.
Der PPC war ein IBM-Ding,
ihn damals aufzugeben waere eine Blamage 1. Ordung gewesen.
IBM war der Koch, Motorola der Kellner.
Haette Motorola aber nicht nach dem Strohhalm PPC gegriffen,
waeren sie als Prozessorhersteller schon ein Jahrzehnt frueher verschwunden.
Fuer die letzten PPC-Macs musste IBM mit dem PPC970 (aka G5) einspringen,
weil Motorola schlappgemacht hatte.

[Michael Kraemer @ home]

p...@pocnet.net wrote:

> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>

>>
>>Auch das war und ist ein Multitasking-System. Wo liegt der Unterschied
>>zu Multi User?
>
>
> Eine berechtige Frage. Möglicherweise weil eine "Workstation" eben nur eine
> 'Haupt'-Anwendung verwalten muss? Unterbrechungen durch andere Tasks dürften
> da vergleichsweise selten sein.
>

Desktop workstations fuhren damals durchaus mehrere Anwendungen "gleichzeitig".
Simulation oder Datenanalyse im Hintergrund, weil die teure Kiste mit
ein bisschen LaTexen oder gnuplotten natuerlich nicht ausgelastet war.

Ihrer groesseren Brueder, also RISC-Server derselben Architektur
(aber mit mehr RAM und evtl hoeherem Takt)
wurden ab 1992/93 zunehmend als mainframe-Ersatz,
also heftig Multiuser, eingesetzt.
Kaum jemand ware damals auf die Idee gekommen, das mit 486/586 zu machen.

[Bernd Laengerich]

Am 20.03.2023 um 01:27 schrieb Michael Kraemer @ home:
> Meine erste RS/6000 brachte praktisch die Rechenleistung eines mainframes
> aus dem selben Hause auf den Schreibtisch.
> Mit super Grafik und einem - sagen wir mal - entgegenkommenderen OS.
> Zu einem hundertstel des Preises.

Die RS/6000 waren schon ganz gut. Insbesondere zu den ansonsten benutzen x86
mit SCO drauf. Von den RS-Kisten haben wir viele verkauft. Haben viele im
HACMP-Verbund verkauft.
Performancetechnisch fand ich die aber gar nicht so überragend, vielleicht
erst im Massiv-Parallelbetrieb. Zu der Zeit hatten wir eine HP/9000 als
Leihstellung auf der ich eine Portierung unserer Software durchführte, muß
vermutlich eine aus der 800er-Serie gewesen sein. Der Compiler und generell
Integerarithmetik waren rasend schnell im Vergleich, Gleitkomma aber nicht so
doll.

Bernd

[Kay Martinen]

Am 20.03.23 um 02:28 schrieb Ralf Kiefer:

> Michael Kraemer @ home wrote:

>> Haette Motorola aber nicht nach dem Strohhalm PPC gegriffen,
>> waeren sie als Prozessorhersteller schon ein Jahrzehnt frueher verschwunden.
>

> Bei Motorola sah man in den frühen 1990er Jahren größere Erfolgschancen
> im Embedded-Markt. Dort hielten sich diverse 68k-Kerne (ColdFire) noch
> etliche Jahre in ganz anderen Stückzahlen als im PC-Markt. Auch die
> Embedded-PPCs von Motorola liefen in deutlich größerer Stückzahl als die
> Desktop-Varianten.

Hat Cisco ausgeholfen? Ich erinnere mich das ein Catalyst 2924-M-XL hier
als CPU eine PPC604 angibt. Als Switch-Prozessor Embedded oder?

[p...@pocnet.net]

Sebastian Barthel <nait...@freenet.de> wrote:

> Ein wichtiger Punkt, der für mein Dafürhalten bei RISC ganz(!) wichtig ist,
> steht da oft nicht so explizit in solchen Begründungen drin, nämlich: RISC
> erlaubt schlicht keine Zugriffe aufs RAM, außer Register laden und speichern
> (Load/Store Architektur).

Stimmt, das war mir bis Dato überhaupt nicht bewusst.

Ebensowenig hatte ich die vergleichsweise vielen universellen Register "im
Vorderhirn".

:wq! PoC

[p...@pocnet.net]

Sebastian Barthel <nait...@freenet.de> wrote:

> Mit der Pipeline kann man sehr schön eine Verlangsamung bei Taskwechseln
> begründen. Insebesondere dann, wenn die Pipeline sehr lang ist wird das
> auch meßbar

Interessanter Einwand. Wie schätzt Du die Größenordnung dieser potentiellen
Verlangsamung ein, wenn man dem Vergleich vom Autor (486 vs. SPARC) folgen
mag?

> (im direkten Vergleich innerhalb gleicher Architektur, sehr schön zu sehen
> z.B. bei StrongARM vs. normal-ARM (610, 710 oder gar ARM 2 oder 3).

Was genau meinst Du mit "sehen"?

> Interessanter für User/Taskwechsel dürfte sein, wieviel und welches Cache-
> RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen parken
> kann und nicht zuviele "User" da sind, dürfte man das ziemlich deutlich
> merken.

Auch hier, wie schätzt Du die Größenordnung dieser potentiellen Verlangsamung
ein, wenn man dem Vergleich vom Autor (486 vs. SPARC) folgen mag?

:wq! PoC

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

> Und Paging ist doch eher ein Interner Weg zu sagen "Den Teil brauch ich grad
> nicht im RAM, der kann raus" wenn man eh schon den Speicher in feste
> Seitengrößen aufgeteilt hat.

Du hast vollkommen recht. Trotzdem ist das für die Betrachtung der
Gesamtperformance relevant.

> Nebenbei hängt das Schutzkonzept auch da mit drin.

Du meinst, eines der Schutzkonzepte, nämlich dass ein Task nicht dem anderen
im Speicher rumschießen kann.

> Ich denke nicht das man genau EIN Programm in einem OS als Haupt-Anwendung
> ansehen kann.

Doch, kann man. Die alten MacOS Varianten mit kooperativem Multitasking
räumten der Vordergrundanwendung mehr Priorität ein als
Hintergrundanwendungen.

> IMHO konnte/kann man zwar einem Prozess höhere Priorität zuordnen (nice)
> oder ihn auch auf genau einen CPU Kern festnageln (pinning?) aber damit ist
> er immer noch nur ein Programm von vielen die das Multitasking-OS immer
> wieder abwechselnd ausführt.

Überspitzt gesagt: Nur wenn die anderen Programme auch was zu tun haben. Wenn
ein inetd keine Socketanfrage bekommt, braucht er keine Rechenzeit und wird
vom Scheduler m. W. nie aufgerufen. Beispielsweise.

> Und was man dem einen Programm an mehr zuschanzt fehlt ggf. dann den
> anderen.

Und Regen ist nass. :-) Bei einem interaktiv benutzten System möchte man ja
genau das haben: Die interaktive Applikation reagiert mit maximaler
wuppdizität und Hintergrundprozesse dürfen gerne langsamer arbeiten.

> Was sich ggf. Ändern könnte: Wenn diese eine spezielle Anwendung intensiven
> Gebrauch von CISC Befehlen machte - auf einem Kern.

Da wäre die Frage, ob der Autor hier handgeklöppelten Assemblercode mit
entprechend clever eingesetzten Befehlen im Sinn hatte, oder lediglich das was
die damals üblichen Compiler hinten rauswerfen.

> Dann könnte sie evtl. schneller sein als ein Kompilat der Gleichen Anwendung
> das die nicht nutzt - oder RISC Pendants nutzen will. Meine Vermutung!

Das schrieb ich doch in einer anderen Nachricht. :-) Die Frage ist, ob solche
Opcodes vom Assemblergott in relevanter Menge sinnvoll eingesetzt werden
können.

> Gab es nicht das gleiche Gewese auch später mit Programmen die optimiert
> waren auf MMX, SSE oder Multithreading oder akt. AES-NI. Alles um den
> Durchsatz, die Leistung zu steigern. Kurz: um Schneller Fertig zu
> werden. Sind alles auch Befehlssatz-erweiterungen oder?

Ja, aber das hat weniger was mit CISC vs. RISC zutun. Was Du aufführst sind
ausgesprochene SIMD Instruktionen, um "Multimedia" zu beschleunigen.

<https://en.wikipedia.org/wiki/Single_instruction,_multiple_data>

> Ist aus dem anfänglichen RISC damit nicht heute effektiv doch wieder ein
> CISC geworden?

Wenn man alle RISC kennzeichnenden Parameter einbezieht: Nein.

:wq! PoC

[p...@pocnet.net]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

> Desktop workstations fuhren damals durchaus mehrere Anwendungen "gleichzeitig".
> Simulation oder Datenanalyse im Hintergrund, weil die teure Kiste mit
> ein bisschen LaTexen oder gnuplotten natuerlich nicht ausgelastet war.

War das wirklich in der Praxis so universell verbreitet? Eine Kiste (sinnvoll)
beschäftigt zu halten ist IMO noch heute ein Stressfaktor, weil es von der
primär zu erledigenden Aufgabe ablenkt.

> Ihrer groesseren Brueder, also RISC-Server derselben Architektur (aber mit
> mehr RAM und evtl hoeherem Takt) wurden ab 1992/93 zunehmend als
> mainframe-Ersatz, also heftig Multiuser, eingesetzt. Kaum jemand ware
> damals auf die Idee gekommen, das mit 486/586 zu machen.

Bis auf AT&T, und vermutlich noch andere, womit wir wieder am Anfang sind. ;-)

:wq! PoC

[p...@pocnet.net]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

> Naja, der hype war halt real.
> Die damaligen RISCs versaegten so ziemlich alles,
> was damals als CISC auf dem Markt war (x86,68k,VAX).
> Das konnte man messen.
> Besonders "demuetigend" war das im Falle des POWER1.
> Der ist noch nichtmal ein Single-Chip-"Kaefer" sondern eine Steckkarte
> von der Groesse eines MCA-Boards mit 6 oder 7 chips drauf.
> Mit schlaffen 25MHz zog der Kreise um alles andere.

Das war in einer früheren iX bei einem Test der damals frisch vorgestellten
RS/6k so ähnlich auch dargestellt worden.

>>> IBM hätte wohl für ihre damals bereits auf
>>> dem Markt befindliche RS/6000 keine POWER-CPUs verwendet,
>
> Sondern?

Anderes was bereits existierte.

> RS6ks sind/waren die Existenzberechtigung fuer POWER.

Schon klar. Das war ein Gedankenexperiment: Warum sollte IBM viel Geld in eine
im Multuserbetrieb angeblich unterlegene CPU-Architektur investieren?

Deswegen:

>>> wenn der Autor mit seiner Behauptung auch nur ungefähr den Sachverhalt
>>> getroffen hätte.

:wq! PoC

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

> Hat Cisco ausgeholfen? Ich erinnere mich das ein Catalyst 2924-M-XL hier
> als CPU eine PPC604 angibt. Als Switch-Prozessor Embedded oder?

Ausgeholfen klingt so nach "weil ihr es seid". So läuft das m. E. nicht.

Cisco hat das genommen was am preiswertesten war. Embedded PPCs waren in den
älteren Routern und Switches lange Jahre präsent.

Die PPCs waren aber in Switches immer nur für die Control Plane zuständig. Das
eigentliche Paketschubsen hat spezielles Silizium erledigt, was vom Code auf
dem PPC-Kern "kontrolliert" wurde.

:wq! PoC

[p...@pocnet.net]

Sebastian Barthel <nait...@freenet.de> wrote:

> Man findet zu dem AT&T StarServer irgendwie auch überhaupt nichts im www.

Es ist verblüffend zu sehen, wie viele Dinge aus den 1990ern heutzutage schwer
auffindbar oder gar nicht mehr im Netz präsent sind. Ein weiteres Beispiel
wäre EURIX, ein weiterer PC-Port von SVR4. Herausragende Eigenschaft: Komplett
in Deutsch...

:wq! PoC

[Peter Heitzer]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

><p...@pocnet.net> wrote:

>> Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu 128
>> User und 200 Clients bedienen können

>Die Anzahl der "User" spielt bei der Betrachtung auf Betriebssystemebene

>und drunter keine Rolle. Das ist dort einfach nur Multitasking. Damit
>ein System den Taskwechsel schnell vollziehen kann, braucht's eine CPU,
>die ihren internen Zustand (Registersatz) beim Interrupt schnell
>irgendwohin retten kann und einen anderen laden kann. Dazu gehören gute
>Speicherbandbreite und kleine zu transferierende Datenmengen. Ob CISC
>oder RISC ist bis hier egal, IMHO. Oder: je komplexer das Innenleben
>einer CPU, desto größer die Reaktionszeit beim Interrupt und somit der
>Task-Wechsel. Es hat schon einen Grund, weswegen z.B. der 6502 die
>schnellste Interrupt-Reaktionszeit hat, gemessen in Takten. Ok, der 6502
>ist eine frühe Form einer RISC-Architektur :-)
Wobei sich das Reduced auch auf die Anzahl der Register bezieht, quasi
ein Super-RISC ;-)
--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[Michael Kraemer @ home]

Ralf Kiefer wrote:
>
> Motorola hatte die großen 68k-Chips schon lange aufgegeben, als 68060 in
> Stückzahlen auf dem Markt erschienen. D.h. das Ende war schon vor
> Marktreife bekannt. Insofern war klar, daß es nicht mehr weitergeht. Ich
> denke, daß man die Baureihe hätte weiterentwickeln können, wenn es
> Abnehmer gegeben hätte.

Mit etwas (schlappe 30 Jahre) Verspaetung passiert das grade - irgendwie.
Im Amiga Paralleluniversum gibt es grossen Hype um einen "68080".
Implementierung des 68060 plus Extras in FPGA, rennt mit 2GHz
und soll hoechst kompatibel zum Original sein.
Echte hardware, keine unwuerdige Emulation auf einer Fremd-CPU.
Der FPGA kommt allerdings von intel, wimre,
nichtmal sowas bringt Motorola noch zustande.

http://apollo-computer.com/apollo68080.php

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> Ebensowenig hatte ich die vergleichsweise vielen universellen Register "im
> Vorderhirn".

Temporallappen (also an der Seite), nicht Frontallappen. ;-)
Das "Vorderhirn" = Prosencephalon ist ein Zwischenschritt in der
frühen Hirnentwicklung der Embryonalphase.

gruss,
"The More You Know"*

--
"I've seen things you people wouldn't believe. Attack ships on fire off the
shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser
gate. All those moments will be lost in time, like tears in rain."

[Dennis Grevenstein]

p...@pocnet.net wrote:
> StarServer mit einer der damals zahlreich vorhandenen Portierungen von AT&T
> Unix SysV. Siehe hier:
>
> <https://en.wikipedia.org/wiki/AT%26T_Computer_Systems#Servers>
>

> Der Hersteller behauptete gemäß Artikelaufmacher, die Kiste könne bis zu 128

> User und 200 Clients bedienen können, mit "nur" "bis zu 4" 486-33 CPUs, max.
> einem halben Gigabyte RAM und einem eigenen Bussystem, was gegenüber dem
> damals angesagten EISA-Bus der PC-Welt knapp den achtfachen Datendurchsatz
> erlaubt.
>
> Der Autor behauptet im weiteren Verlauf, die "Zielvorstellungen,
> Hardwarestandards zu verwenden (Intel 80486) und bis zu 328 Benutzer zu
> unterstützen, erklären den Einsatz eines CISC-Prozessors. Für
> Multiuser-Systeme ist ein CISC-Prozessor geeigneter als die heute
> allgegenwärtigen RISC-Prozessoren."

Das ist ja auch bestimmt ein schönes Teil gewesen, aber grundsätzlich
ist das schon noch eine Zeit, in der SMP mit x86 ein bisschen
anstrengend war. Überleg nur mal, was die z.B. bei Sequent aufbieten
mussten für große SMP Kisten mit x86.
Wenn jemand 1990 CISC als überragend für multi user feiert, dann
würde ich mich auch eher fragen, ob da nicht jemand noch sehr verliebt
in große, alte VAXen war.

> Er untermauert diese Behauptung damit, "dass die SPARCstation 2 im BSD-Test
> der SSBA bei forc-Werten deutlich langsamer ist als dieser 486er. Der
> BSD-Test ist auf SysV angepasst und beschreibt insgesamt recht gut den
> Durchsatz und die Qualität des zugrundeliegenden Unix Derivats.

Ich frage mich ein bisschen, ob man da nicht gezielt Probleme
erfindet, die vielleicht eher was mit der SunOS kernel Konfiguration
zu tun haben als mit den Eigenschaften der SPARC CPU.
Es gab von Sun sogar extra ein Handbuch zu "performance tuning"
oder so, weil man durch drehen am kernel doch noch einiges
rausholen konnte je nach Anwendung. Unter anderem deshalb wollte
Sun perspektivisch als Solaris (SVR4) umsteigen, weil sie sich
auf größeren SMP Maschinen mehr Optimierungspotential versprochen
haben. Die frühen 90er waren für Sun so eine Durststrecke in dem
Bereich, wo SunOS bei den großen Kisten an seine Grenzen kam, aber
Solaris noch nicht gut/schnell/stabil genug war.

gruss,
Dennis

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

>> Ebensowenig hatte ich die vergleichsweise vielen universellen Register "im
>> Vorderhirn".
>
> Temporallappen (also an der Seite), nicht Frontallappen. ;-) Das
> "Vorderhirn" = Prosencephalon ist ein Zwischenschritt in der frühen
> Hirnentwicklung der Embryonalphase.

Danke, Herr Fachmann! :-)

:wq! PoC

[Michael Kraemer @ home]

je nun, Performance-Lorbeer welkt hat schnell.
Muessten aber 700er Maschinen gewesen sein,
das waren ziemlich coole Teile damals,
nicht nur schnell, sondern kamen auch mit dem
VUE-desktop und anderen schraegen Ideen.
Uncool wurde HP ab 1994, als sie sich dem Evil Empire ergaben.

[Michael Kraemer @ home]

p...@pocnet.net wrote:
> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>
>
>>Desktop workstations fuhren damals durchaus mehrere Anwendungen "gleichzeitig".
>>Simulation oder Datenanalyse im Hintergrund, weil die teure Kiste mit
>>ein bisschen LaTexen oder gnuplotten natuerlich nicht ausgelastet war.
>
>
> War das wirklich in der Praxis so universell verbreitet?

in academia schon.
Eine gut ausgestattete Arbeitgruppe konnte es da schon mit der Zentral-IT aufnehmen.
Es waere Verschwendung gewesen, die dezentralen Rechner
zB nachts einfach Daeumchen drehen zu lassen.

> Eine Kiste (sinnvoll)
> beschäftigt zu halten ist IMO noch heute ein Stressfaktor, weil es von der
> primär zu erledigenden Aufgabe ablenkt.

Definiere "primär zu erledigenden Aufgabe".
Workstations wurden in den fruehen 1990ern fuer alles moegliche benutzt.
U.a. eben auch zum Rechnen im Batch-Betrieb, unter NQS oder LoadLeveler
oder aehnlicher Middleware.
Die sorgte dann auch dafuer, dass Rechenjobs heruntergestuft wurden,
wenn der eigentliche Benutzer zB mit der Maus wackelte.

>
>>Ihrer groesseren Brueder, also RISC-Server derselben Architektur (aber mit
>>mehr RAM und evtl hoeherem Takt) wurden ab 1992/93 zunehmend als
>>mainframe-Ersatz, also heftig Multiuser, eingesetzt. Kaum jemand ware
>>damals auf die Idee gekommen, das mit 486/586 zu machen.
>
>
> Bis auf AT&T, und vermutlich noch andere, womit wir wieder am Anfang sind. ;-)
>

Also von den grossen Rechenzentren in meinem Dunstkreis hat das keiner gemacht,
wimre.
Die sind von (IBM-)Mainframes auf RISC-server umgestiegen,
oft, aber nicht immer RS/6000, wer IBM nicht mochte nahm halt HP (PA-RISC).

[Kay Martinen]

Am 20.03.23 um 10:27 schrieb p...@pocnet.net:

> Kay Martinen <use...@martinen.de> wrote:
>
>> Hat Cisco ausgeholfen? Ich erinnere mich das ein Catalyst 2924-M-XL hier
>> als CPU eine PPC604 angibt. Als Switch-Prozessor Embedded oder?
>
> Ausgeholfen klingt so nach "weil ihr es seid". So läuft das m. E. nicht.

So hab ich es auch nicht gemeint. Nur auch nicht nachgesehen ab wann
diese Geräte verkauft wurden - oder ob die alle einen PPC hätten.

> Cisco hat das genommen was am preiswertesten war. Embedded PPCs waren in den
> älteren Routern und Switches lange Jahre präsent.

Offenbar. So wie Z80, 6502 oder gar 68xx(x) in manchen Modems oder
Steckkarten.

> Die PPCs waren aber in Switches immer nur für die Control Plane zuständig. Das
> eigentliche Paketschubsen hat spezielles Silizium erledigt, was vom Code auf
> dem PPC-Kern "kontrolliert" wurde.

DAS wußte ich. ;)

Und dennoch hat das Cisco IOS wohl nichts mit dem Apple IOS zu tun, noch
weniger mit dem MacOS auf PowerMac (G4) z.b. Oder gab's da
verwandschaftliche Beziehungen?

Dabei fällt mir wieder ein das ich nach dem auswechseln eines Catalyst
29xx verwundert war. Über den anderen Switch waren die Pinp-zeiten
deutlich höher. Ich hab vermutet das es an der Switching-Technik
(Cutthrough vs. store&forward) liegen mag. Aber ich fand seinerzeit
nicht welches Technik in den beteiligten Geräten angewandt wurde.

BTW. Für den Raspi gibt's ein Multiport-Switchboard. In einem Artikel
dazu las ich das es alles an alle ports durch lässt und weder VLAN noch
sonstiges einsperrt - so lange es am Booten ist. Nicht schön. :-/

[Peter Heitzer]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

>Peter Heitzer wrote:

>> >Ok, der 6502
>> >ist eine frühe Form einer RISC-Architektur :-)
>> Wobei sich das Reduced auch auf die Anzahl der Register bezieht, quasi
>> ein Super-RISC ;-)

>Der 6502 hat drei sehr schnelle Register und 256 schnelle Register (1
>Takt Zuschlag) ;-) Mit etwas externer Hardware ließe sich der externe
>"Registersatz" beim Kontextswitch in 4 Zyklen umschalten.
Da gab es AFAIR mal eine Bauanleitung für "direct page" für den 6502, womit
man die ZP in eine beliebige Page legen konnte. Es gibt auch ein nettest
Video von einem Vortrag über eine MMU für den 6502 (hatte ich vor einiger
Zeit hier gepostet).
Die CMOS-Varianten hatten zumindest Push- und Pullbefehle für die
Indexregister. Das war für einen schnellen Kontextswitch schon sehr nützlich.

[Kay Martinen]

Am 20.03.23 um 09:53 schrieb p...@pocnet.net:

... bei RISC CPUs meinst du.

Was ich im anderen Post zur Pipeline schriebt spielt da m.E. auch eine
Rolle. Denn bei einer CISC CPU hat es eben auch diese Möglichkeiten über
indirekte Adressierungsarten, Präfixe, Suffixe, Displacements u.s.w. die
einem Einzigen Befehl zugeordnet diesen deutlich verlängern (Zahl der
Befehlsbytes). IMHO las ich mal von bis zu 15 Bytes die EIN Grundbefehl
dadurch verlängert würde. In dem Extrem hieße das 15 bytes Fetch und
beim decode müssen dann ggf. noch Addressen oder Werte aus dem RAM
gelesen werden. Inkl. Cache-miss und Waitstates auf den Externen
RAM-Zugriff. Viel spaß beim Puzzeln.

Aber: Sind die Befehle wirklich kürzer nur weil RISC drauf steht oder
ist es nicht eher nach außen hin immer noch "Kennt CISC Befehle" und
wird intern ge-RISC'd (Microcode, MicroOps)?

Zumindest bei x86 kann man doch nicht einfach den bisherigen Befehlsatz
weg werfen. Man muß ihn also intern ummodeln. Heißt: Es kann immer noch
so lange Sequenzen geben.

Und wie wirkt sich das in der Praxis aus wenn eine Intern-RISC CPU
solche Langen befehle dekodiert. Wird dann das laden von werten für ein
Register EAX einfach in ein Register XYZ Laden umgemodelt?

Ähm, auf einem 486DX-33...?

N.B. Gelesen im Original-Link: Die einzelnen CPUs sollen keinen
Shared-address-space gehabt haben. Nanu? Nennt sich das "Snuggly
Coupled"? ;)

[Gerrit Heitsch]

On 3/20/23 15:23, Ralf Kiefer wrote:

> Michael Kraemer @ home wrote:
>
>> Mit etwas (schlappe 30 Jahre) Verspaetung passiert das grade - irgendwie.
>

> Ich hatte das vor geraumer Zeit mitbekommen. Ich halte das für eine
> grandiose Leistung von ein paar "Hobbyisten". Ein großer
> wirtschaftlicher Erfolg wird das nicht werden, denn wer erinnert sich
> heute noch an die 68k-Architektur außer den paar ganz "Harten". Und mit
> einer CPU alleine ist es noch nicht getan, es braucht Systeme. Mich
> reizt die Amiga-Welt überhaupt nicht, weder damals noch heute.

Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
bezahlbar? Immer her mit.

Ich hab noch einen A1200 mit 68030-Karte. Von Power on bis Desktop ready
in unter 10 sec (CF-Karte als SSD).

Gerrit

[Kay Martinen]

Am 20.03.23 um 16:41 schrieb Gerrit Heitsch:

> On 3/20/23 15:23, Ralf Kiefer wrote:
>> Michael Kraemer @ home wrote:
>>
>>> Mit etwas (schlappe 30 Jahre) Verspaetung passiert das grade - irgendwie.
>>
>> Ich hatte das vor geraumer Zeit mitbekommen. Ich halte das für eine
>> grandiose Leistung von ein paar "Hobbyisten". Ein großer
>> wirtschaftlicher Erfolg wird das nicht werden, denn wer erinnert sich
>> heute noch an die 68k-Architektur außer den paar ganz "Harten". Und mit
>> einer CPU alleine ist es noch nicht getan, es braucht Systeme. Mich

Tja. NDR Klein Computer Neuauflage vielleicht? ;)

>> reizt die Amiga-Welt überhaupt nicht, weder damals noch heute.
>
> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
> bezahlbar? Immer her mit.

Bezahlbar war seinerzeit mein Problem. Damals wollte ich immer einen
haben... aber eher wg. Grafik, Sound und den Games die das nutzten.

> Ich hab noch einen A1200 mit 68030-Karte. Von Power on bis Desktop ready
> in unter 10 sec (CF-Karte als SSD).

:-) Von Power On bis BASIC Ready: Gefühlt eine Sekunde. C-128.

Leider hab ich Geoworks Ensemble nie im ROM gehabt... Wär' cool gewesen.

[Peter J. Holzer]

On 2023-03-20 12:47, Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

> Bernd Laengerich wrote:
>> Zu der Zeit hatten wir eine HP/9000 als Leihstellung auf der ich eine
>> Portierung unserer Software durchführte, muß vermutlich eine aus der
>> 800er-Serie gewesen sein.

[...]

> Muessten aber 700er Maschinen gewesen sein,

700er waren Workstations, 800er waren Server.

hp

[Stefan Möding]

p...@pocnet.net writes:

>Herausragende Eigenschaft: Komplett in Deutsch...

Mit

sort: Schreiben fehlgeschlagen: Standard Ausgabe: Pfeife gebrochen

und anderen Klassikern? IBM AIX war damals auch so ein Ding, wo man sich
als Unix-Kenner bei den deutschen Fehlermeldungen nur am Kopf kratzen
konnte.

--
Stefan

[p...@pocnet.net]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

>> War das wirklich in der Praxis so universell verbreitet?
>
> in academia schon.
> Eine gut ausgestattete Arbeitgruppe konnte es da schon mit der Zentral-IT
> aufnehmen.

Okay. Da hast Du mehr Einblick als ich. Möglicherweise bin ich auch mit meinem
"modernen" Blick etwas daneben, dass stundenlang laufende Tasks *aus meinem
Blickwinkel, seit ich mit Rechnern zu tun habe* eher ungewöhnlich sind.

> Es waere Verschwendung gewesen, die dezentralen Rechner
> zB nachts einfach Daeumchen drehen zu lassen.

Stimmt. Man hätte sie ausschalten können und damit Strom sparen. ;-)

>> Eine Kiste (sinnvoll)
>> beschäftigt zu halten ist IMO noch heute ein Stressfaktor, weil es von der
>> primär zu erledigenden Aufgabe ablenkt.
>
> Definiere "primär zu erledigenden Aufgabe".

"Mit der Maus wackeln", z. B. Also das was der Benutzer der via X11 an der
lokalen Konsole sitzt halt so macht. Da habe ich keine genauen Kenntnisse.

> Workstations wurden in den fruehen 1990ern fuer alles moegliche benutzt.
> U.a. eben auch zum Rechnen im Batch-Betrieb, unter NQS oder LoadLeveler
> oder aehnlicher Middleware.
> Die sorgte dann auch dafuer, dass Rechenjobs heruntergestuft wurden,
> wenn der eigentliche Benutzer zB mit der Maus wackelte.

Das war mir nicht bewusst. Spannend!

>> Bis auf AT&T, und vermutlich noch andere, womit wir wieder am Anfang sind. ;-)
>
> Also von den grossen Rechenzentren in meinem Dunstkreis hat das keiner gemacht,
> wimre.

Ich unterstelle AT&T dass sie sich irgendwas dabei gedacht haben, als sie das
Ding entwickelten. Ob wir das heute noch nachvollziehen können, ist eine
andere Sache. :-)

:wq! PoC

[p...@pocnet.net]

Kay Martinen <use...@martinen.de> wrote:

>> Ausgeholfen klingt so nach "weil ihr es seid". So läuft das m. E. nicht.
>
> So hab ich es auch nicht gemeint. Nur auch nicht nachgesehen ab wann
> diese Geräte verkauft wurden - oder ob die alle einen PPC hätten.

Ah, das kam hier anders an. :-)

>> Die PPCs waren aber in Switches immer nur für die Control Plane zuständig. Das
>> eigentliche Paketschubsen hat spezielles Silizium erledigt, was vom Code auf
>> dem PPC-Kern "kontrolliert" wurde.
> DAS wußte ich. ;)

Wollte nur sicher gehen. Klang in Deiner Beschreibung anders. :-)

> Und dennoch hat das Cisco IOS wohl nichts mit dem Apple IOS zu tun, noch
> weniger mit dem MacOS auf PowerMac (G4) z.b. Oder gab's da
> verwandschaftliche Beziehungen?

Apple und Cisco hatten sich irgendwann geeignigt, dass Apple den Begriff
iPhone nutzen darf, ohne dass Cisco ihre Anwaltshorden losschickt. Und damit
vermutlich auch iOS.

<https://www.cultofmac.com/468635/today-in-apple-history-cisco-iphone-name/>

> Dabei fällt mir wieder ein das ich nach dem auswechseln eines Catalyst
> 29xx verwundert war. Über den anderen Switch waren die Pinp-zeiten
> deutlich höher. Ich hab vermutet das es an der Switching-Technik
> (Cutthrough vs. store&forward) liegen mag. Aber ich fand seinerzeit
> nicht welches Technik in den beteiligten Geräten angewandt wurde.

Da kann ich Dir kaum helfen. Die XLs die Du im Einsatz ha(tte)st brauchen mir
einfach zu viel elektrische Leistung und machen Krach, weil die entstehende
Wärme ja auch abtransportiert werden muss. Mir die sind 2950 deutlich lieber.
Und wenn man Gigabit haben möchte, dann sind IMO 2960-S eine gute Wahl, weil
auch sehr sparsam.

> BTW. Für den Raspi gibt's ein Multiport-Switchboard. In einem Artikel
> dazu las ich das es alles an alle ports durch lässt und weder VLAN noch
> sonstiges einsperrt - so lange es am Booten ist. Nicht schön. :-/

Tja, so ist das mit dem Software defined gedöhns. :-)

:wq! PoC

[p...@pocnet.net]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Wenn es denn einen Quadra 1000 gäbe, auf dem System 7 und MacOS 8 liefe
> ... :-) Langweilig wär's, wenn der Rechner in 1sec bootet und selbst
> große Bildmanipulationen in Photoshop in Sekundenbruchteilen erledigt
> sind, die früher etliche Sekunden Rechenzeit beanspruchten. Oder ich
> stelle mir mein MacSOUP vor, das in wenigen sec startet.

Och, ich fände das durchaus interessant und nicht im Geringsten langweilig. :-)

:wq! PoC

[p...@pocnet.net]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:

> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
> bezahlbar? Immer her mit.

Mich auch. Bis ich einen in Aktion sah. 50Hz Bildwiederholrate? Mickerige
Auflösung? Äh, nein danke. Ich bleibe bei meinem SE/30 (mit interner
Grafikkarte für externen Buntmonitor).

:wq! PoC

[p...@pocnet.net]

Stefan Möding <Mar2023....@spamgourmet.com> wrote:

> Mit
>
> sort: Schreiben fehlgeschlagen: Standard Ausgabe: Pfeife gebrochen
>
> und anderen Klassikern? IBM AIX war damals auch so ein Ding, wo man sich
> als Unix-Kenner bei den deutschen Fehlermeldungen nur am Kopf kratzen
> konnte.

Vermutlich genau das.

Das war aber "damals", also in den 1980ern und (weniger penetrant) Anfang der
1990er ein Dauerthema der Redakteure von c't und iX: "Handbuch nur in
Englisch", "Software nicht ins deutsche Übersetzt".

Das dann aber gepaart mit "tolles deutsches Handbuch aber so viel teurer als
ein Direktimport aus den USA."

:facepalm:

Jedesmal, wenn ich über sowas in den alten Heften stolpere denke ich mir,
"Leuts, lernt Englisch. Computern ohne Englischkenntnisse is nich. Punkt."

Interessanterweise gab es wenig Leserbriefe die sich über englische Software
beklagten.

:wq! PoC

[Sebastian Barthel]

Am Mon, 20 Mar 2023 08:57:55 +0000 schrieb poc:

> Sebastian Barthel <nait...@freenet.de> wrote:
>
>> Mit der Pipeline kann man sehr schön eine Verlangsamung bei
>> Taskwechseln begründen. Insebesondere dann, wenn die Pipeline sehr lang
>> ist wird das auch meßbar
>
> Interessanter Einwand. Wie schätzt Du die Größenordnung dieser
> potentiellen Verlangsamung ein, wenn man dem Vergleich vom Autor (486
> vs. SPARC) folgen mag?

Das wird von der Länge der Pipeline und dem Auftreten solcher Abbrüche
abhängen. Wenn es für sowas Meßwerte gibt, dann wahrscheinlich am ehesten
für MIPS und SPARC.

>> (im direkten Vergleich innerhalb gleicher Architektur, sehr schön zu
>> sehen z.B. bei StrongARM vs. normal-ARM (610, 710 oder gar ARM 2 oder
>> 3).
>
> Was genau meinst Du mit "sehen"?

Das sollte eigentlich nur heißen, daß ich mir einbilde mich da an
entsprechende Benchmarks erinnern zu können.

Dabei ging es immer darum, daß der originale ARM (also ARM2 oder ARM3)
eine ganz klassische Pipeline hat mit den 3 Stufen, wie hier nebenan im
Thread beschrieben. Beim StrongARM dagegen war die etwas länger (5). Und
wenn man damit Abbrüche provoziert hat und beide Chips auf einen
Vergeleichstakt umgerechnet hat, dann konnte man da wohl sehen, daß der
StrongARM damit mehr zu kämpfen hatte.
Keine Ahnung, wie relevant sowas überhaupt war, aber da beide Varianten
eben noch keine Sprungvorhersagen machen (spekulativ oder sonstwie) und
schon gar nicht sowas wie einen Instruction Reorder Buffer hatten (out of
order) sieht man da den direkten Einfluß der Pipeline, die ja bei sowas
dann regelmäßig komlett verworfen wird.

Praktisch hatte das vermutlich überhaupt keinen Wert, zumal der StrongARM
auch viele Befehle (und wichtige) wesentlich schneller ausführte.

Hier mal so eine Info, was man auch noch ohne Insiderkenntnisse
nachvollziehen kann

<https://web.archive.org/web/19990219191139/http://www.acorn.com/acorn/
products/support/strongarm/saprog/performance.txt>

>> Interessanter für User/Taskwechsel dürfte sein, wieviel und welches
>> Cache-
>> RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen
>> parken kann und nicht zuviele "User" da sind, dürfte man das ziemlich
>> deutlich merken.
>
> Auch hier, wie schätzt Du die Größenordnung dieser potentiellen
> Verlangsamung ein, wenn man dem Vergleich vom Autor (486 vs. SPARC)
> folgen mag?

Das wird vermutlich so eine Kurve sein, wo man unterhalb einer gewissen
Anzahl von Usern/Tasks gar keinen Unterschied sieht und dann aber bei
Überschreiten einen gewaltigen Performanceeinbruch über alles sieht.

Sagen wir mal, der Cache hat 8 kByte und 4 Gruppen (sets) und jede Cache-
Line ist 16 Bytes lang, dann hat eine Gruppe Platz für 128 Cache-
Einträge. Man kann die also mit 128 Tasks komplett "absättigen" und
spätestens dann wird man Performanceverlust drastisch sehen können.
Praktisch passiert das vermutlich schon viel früher. Also vielleicht
(Schätzwert) bei aktiven 16 Tasks pro Gruppe, vielleicht auch nur 8. Das
Ganze geht dann noch mal Zahl der Sets - also bei 4 x 8 = 32 Tasks sollte
man "was merken". Das Beispiel ist zwar hypotetisch und komplett
"vermutet", praktisch ließe sich das in der Form auf einem ARM710
probieren, dort ist das so organisiert.

<https://developer.arm.com/documentation/ddi0033/d/>

Praktisch wird es eher weniger sein, da ja vmtl auch das OS noch
irgendwas macht, was teils auch im Cache liegt und da den Platz begrenzt.
Nur bei den I/O Sachen wird das nicht gemacht, sondern direkt geschrieben/
gelesen; aber grafische Oberfläche usf. dürften schon auch "cachen".

Bei Beispiel PC ( 4 x 486 ) und dem Wissen, wie sich so eine 486er
generell anfühlt, würde ich sagen, daß da keine 12 Leute mit einer
grafischen Oberfläche vernünftig auf dem Gerät arbeiten können.

Bei den SPARCs ist es zumindest auf den Workstations und kleinen Servern
anscheinend so, daß die immer unglaublich viel Bandbreite zum RAM haben.
Deshalb steckt man dort ja oft RAMs auch in 4er Grüppchen ein. Das sollte
man ziemlich gut dann merken, wenn der Mechanismus von oben "abgesättigt"
ist und Daten ständig auch mit dem RAM getauscht werden müssen. Eine SUN
bleibt dann halt irgendwie halbwegs lauffähig, einen 486er legt es dann
komplett still. Wäre so meine Vermutung.


Gruß,
SBn

[Sebastian Barthel]

Das ist ziemlich genau der Rechner den man bei Commodore anscheinend
nicht bauen wollte. Der aber vmtl viele User ins untergehende Boot (aka
Kahn) geholt hätte.
Als 3 Boxen Gerät mit 68030 und optionaler Platte (d.h. mindestens
Steckplatz für SCSI oder IDE Controller oder wie gehabt on-board IDE (nur
eben dann nicht mit teurer 2.5" Platte)) wäre da bestimmt was gegangen.

Gruß, SBn

[Dennis Grevenstein]

Sebastian Barthel <nait...@freenet.de> wrote:
>
> Das ist ziemlich genau der Rechner den man bei Commodore anscheinend
> nicht bauen wollte. Der aber vmtl viele User ins untergehende Boot (aka
> Kahn) geholt hätte.
> Als 3 Boxen Gerät mit 68030 und optionaler Platte (d.h. mindestens
> Steckplatz für SCSI oder IDE Controller oder wie gehabt on-board IDE (nur
> eben dann nicht mit teurer 2.5" Platte)) wäre da bestimmt was gegangen.

Atari hat noch 68030 verbaut. Ist kolossal fehlgeschlagen.
Warum hätte es beim Amiga anders sein sollen?

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the

shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser

[Sebastian Barthel]

der aber momentan gerade massiv unter Druck gerät, durch den PiStorm.
Also ein Raspberry Pi, der in Emulation so tut, als sei er so ein 68x
Chip und dabei eher schneller ist und vergleichsweise kaum was kostet.

<https://www.raspberrypi.com/news/pistorm-keeping-the-amiga-alive/>

<https://www.youtube.com/watch?v=nlVTt_VeHJs>

<https://amigastore.eu/853-pistorm.html>


Kommt halt mit dem Haken, daß man dann plötzlich eine ARM CPU im Amiga
hat - da wäre ein 68080 schon stilechter.


Der 68080 ist auf alle Fälle ein wirklich bemerkenswertes Projekt. Und es
ist ja nicht nur eine CPU, sondern kommt gleich mit einem ganzen Satz an
verbesserten Chips wie z.B. dem SuperAGA.


Gruß,
SBn

[Sebastian Barthel]

Mögt ihr euch da bitte mal noch etwas genauer erinnern ? Zumindest
soweit, daß man mal - mit bißchen Aussicht auf Erfolg - anfangen kann im
Netz nach soetwas zu suchen. Also Zeitschrift oder DiscMag, wo das
vorgestellt worden ist ? Evtl ein Name von einem
"Hauptverantwortlichen" / "Creator" / "Maker" ? Oder sonstige Hinweise,
womit man gezielter nach sowas suchen kann. Klingt nämlich irgendwie SEHR
interessant.

Gruß,
SBn

[Sebastian Barthel]

Am Mon, 20 Mar 2023 21:49:36 +0000 schrieb Dennis Grevenstein:

> Sebastian Barthel <nait...@freenet.de> wrote:
>>
>> Das ist ziemlich genau der Rechner den man bei Commodore anscheinend
>> nicht bauen wollte. Der aber vmtl viele User ins untergehende Boot (aka
>> Kahn) geholt hätte.
>> Als 3 Boxen Gerät mit 68030 und optionaler Platte (d.h. mindestens
>> Steckplatz für SCSI oder IDE Controller oder wie gehabt on-board IDE
>> (nur eben dann nicht mit teurer 2.5" Platte)) wäre da bestimmt was
>> gegangen.
>
> Atari hat noch 68030 verbaut. Ist kolossal fehlgeschlagen.
> Warum hätte es beim Amiga anders sein sollen?

Vielleicht, weil es beim Atari doch erstmal gar nicht fehlgeschlagen
ist ? Prämissenfehler, sozusagen ? Der Atari TT war doch erstaunlich
erfolgreich und ist gern genommen worden, wenn denn noch jemand Atari für
solch eine Anwendung genommen hat (und nicht Mac).

Was nicht klappt, ist dann der Falcon. Zu spät, zuviel gewollt, viel zu
teuer, Firma pleit, als es mit dem Verkauf richtig hätte losgehen können.
Und dazu muß man doch auch sagen, daß gerade der Amiga 1200 im Gegensatz
zum Falcon genau das Feld "Multimedia" erstaunlich gut noch weiterführt,
obwohl es die Firma (C=) dann auch schon lange nicht mehr gibt
(1995,1996). Das hat doch also Super funktioniert - und wäre mit einem
68030 statt einem 68020 vermutlich noch bißchen besser gewesen.

Gerade die kreative Demo Ecke wäre doch ohne A1200 überhaupt nicht aus
der Sinusscroller und Sternenhimmel Ecke herausgekommen. Die haben damit
doch ein komplett neues Level an Effekten und "Multivisions"-Show
erreicht.


(Ich würde sogar noch weitergehen: eine Art preiswerter A4000 mit 68040
und der Option auf eine günstige "VGA Karte" ( > 1024x768 ohne Flimmeren),
wäre sicherlich auch hilfreich gewesen.)


Der Walker war m.E. ein schöner Versuch, aber ist auch versandet.

[p...@pocnet.net]

Sebastian Barthel <nait...@freenet.de> wrote:

>>> Mit der Pipeline kann man sehr schön eine Verlangsamung bei
>>> Taskwechseln begründen. Insebesondere dann, wenn die Pipeline sehr lang
>>> ist wird das auch meßbar
>>
>> Interessanter Einwand. Wie schätzt Du die Größenordnung dieser
>> potentiellen Verlangsamung ein, wenn man dem Vergleich vom Autor (486
>> vs. SPARC) folgen mag?
>
> Das wird von der Länge der Pipeline und dem Auftreten solcher Abbrüche
> abhängen. Wenn es für sowas Meßwerte gibt, dann wahrscheinlich am ehesten
> für MIPS und SPARC.

Ohne Vergleichszahlen zum 486 bleibt das müßig.

> Das sollte eigentlich nur heißen, daß ich mir einbilde mich da an
> entsprechende Benchmarks erinnern zu können.

> [...]

Danke für die Erläuterung. Interessant!

>>> Interessanter für User/Taskwechsel dürfte sein, wieviel und welches Cache-
>>> RAM vorhanden ist. Insbesondere L1-Cache. Wenn man da halbe Routinen
>>> parken kann und nicht zuviele "User" da sind, dürfte man das ziemlich
>>> deutlich merken.
>>
>> Auch hier, wie schätzt Du die Größenordnung dieser potentiellen
>> Verlangsamung ein, wenn man dem Vergleich vom Autor (486 vs. SPARC) folgen
>> mag?
>
> Das wird vermutlich so eine Kurve sein, wo man unterhalb einer gewissen
> Anzahl von Usern/Tasks gar keinen Unterschied sieht und dann aber bei
> Überschreiten einen gewaltigen Performanceeinbruch über alles sieht.

Klingt nach einem klassischen Thrashing-Szenario. Dieser Punkt müsste
eigentlich mit "heutigen" CPUs auch erreichbar sein, aber ich kann mich nicht
erinnern, einmal eine Kiste so massiv mit parallelen Tasks an die Wand
gefahren zu haben. Wenn klemmte es immer am RAM.

> Sagen wir mal, der Cache hat 8 kByte und 4 Gruppen (sets) und jede Cache-
> Line ist 16 Bytes lang, dann hat eine Gruppe Platz für 128 Cache-
> Einträge. Man kann die also mit 128 Tasks komplett "absättigen" und
> spätestens dann wird man Performanceverlust drastisch sehen können.
> Praktisch passiert das vermutlich schon viel früher. Also vielleicht
> (Schätzwert) bei aktiven 16 Tasks pro Gruppe, vielleicht auch nur 8. Das
> Ganze geht dann noch mal Zahl der Sets - also bei 4 x 8 = 32 Tasks sollte
> man "was merken". Das Beispiel ist zwar hypotetisch und komplett
> "vermutet", praktisch ließe sich das in der Form auf einem ARM710
> probieren, dort ist das so organisiert.

Danke, das ist eine sehr interessante Darlegung!

> Bei Beispiel PC ( 4 x 486 ) und dem Wissen, wie sich so eine 486er
> generell anfühlt, würde ich sagen, daß da keine 12 Leute mit einer
> grafischen Oberfläche vernünftig auf dem Gerät arbeiten können.

Deckt sich mit meinem Bauchgefühl. Andererseits ist das auch wiederum
abhängig davon, was die 12 X11-User genau machen.

> Bei den SPARCs ist es zumindest auf den Workstations und kleinen Servern
> anscheinend so, daß die immer unglaublich viel Bandbreite zum RAM haben.

Und im Vergleich zum Cache doch nicht genug. ;-)

> Deshalb steckt man dort ja oft RAMs auch in 4er Grüppchen ein.

Was für RAMs? Mit 30-Pin SIMMs bedeutet eine Vierergruppe 32 Bit, bei PS/2
schon 128. Ich kenne die Suns nicht gut genug um zu wissen, was die für
RAM-Bausteine nutz(t)en. Ich weiss aber dass die 486er teilweise 30-Pin SIMMs
benutzten und teilweise auch schon PS/2. Erstere musste man in Vierergruppen
tauschen, letztere durfte man einzeln. Also ziemlich eindeutig ein 32-Bit Bus.
:-)

> Das sollte man ziemlich gut dann merken, wenn der Mechanismus von oben
> "abgesättigt" ist und Daten ständig auch mit dem RAM getauscht werden
> müssen. Eine SUN bleibt dann halt irgendwie halbwegs lauffähig, einen 486er
> legt es dann komplett still. Wäre so meine Vermutung.

Klingt auf jeden Fall schlüssig. Ob in der Praxis so ein Punkt erreicht werden
kann, bevor ein handelsüblicher 486er sich über das damals übliche lahme
I/O-Interface (IDE) zu tode swappt, wäre noch festzustellen.

Ich muss mal schauen, was ich an Hardware einsatzbereit zu Verfügung habe.
Prinzipiell wäre z. B. das parallele Starten von mehreren gzip Prozessen
eigentlich eine gute Annäherung. Was meinst Du?

:wq! PoC

[p...@pocnet.net]

Dennis Grevenstein <dennis.gr...@gmail.com> wrote:

> Atari hat noch 68030 verbaut. Ist kolossal fehlgeschlagen.
> Warum hätte es beim Amiga anders sein sollen?

Vermutlich nicht.

So wie ich das aus den alten iXen rausgelesen habe scheint Motorola über
längere Zeit Probleme gehabt zu haben, den 040 in ausreichender Stückzahl zu
fertigen. Die Hersteller wollten aber verkaufen, also baute man mit dem was
verfügbar war. Kann man kaum den Herstellern anlasten. :-)

:wq! PoC

[p...@pocnet.net]

Sebastian Barthel <nait...@freenet.de> wrote:

> Ich würde sogar noch weitergehen: eine Art preiswerter A4000 mit 68040
> und der Option auf eine günstige "VGA Karte" ( > 1024x768 ohne Flimmeren),
> wäre sicherlich auch hilfreich gewesen.

Sicherlich. Das wäre dann sogar für mich eine potentiell interessante Kiste
gewesen, selbst mit einem 030. Was aus meiner Sicht aber überhaupt nicht ging
waren 50Hz (oder 60, wenn man auf amerikanische TV-Norm umgeschaltet hat).

So wie ich das verstanden habe waren die ganzen Helferchips im Amiga aber
genau auf das TV-Timing zugeschnitten, zusammen mit der Anbindung ans
Chip-RAM. Die tolle Amiga Grafik und flüssige Animation war m. E. *nur* mit
diesen Zusatzhelfern zu erreichen:

Ich hatte später mal die Möglichkeit an einem 4000er zu sitzen. Sobald man den
auf eine mit meinem SE/30 vergleichbare Auflösung (640x480 in 8 Bit)
umschaltete war vorbei mit der tollen, schnellen Grafik. Das Flimmern war mit
den ≥ 60 Hz besser als mit den hierzulande üblichen 50, man hatte endlich
Platz für Workbench-Fenster, aber die Kiste fühlte sich langsamer an als mein
SE/30. Ah, und natürlich lief die meiste Software nicht in diesem Modus.

:wq! PoC

[Kay Martinen]

Am 20.03.23 um 21:23 schrieb p...@pocnet.net:

> Michael Kraemer @ home <M.Kr...@gsi.de> wrote:

>> Es waere Verschwendung gewesen, die dezentralen Rechner
>> zB nachts einfach Daeumchen drehen zu lassen.
>
> Stimmt. Man hätte sie ausschalten können und damit Strom sparen. ;-)

Damals (TM) war Stromsparen noch nicht so
angesagt/sicher-armut-erzeugend wie heute. :-)

Ich hab früher auch den Classic-Client von Seti@Home nachts laufen
lassen - zu hause. Inzwischen geht der eher automatisch in den
Ruhezustand. Seitdem das funktioniert. ;)

Und in (Groß)Firmen/Institutionen könnte nicht vorhandenes oder
nicht-funktionierendes Wake On LAN dazu führen das die IT, das
Management bestimmt die Rechner hätten an zu bleiben. Damit die zu
Wartungs-zwecken erreicht werden können. Wenn nachts keiner am Gerät
sitzt kann man leichter Updates machen oder? Und wenn der Zoo eh schon
an bleibt dann kann er auch rechnen o.a. erledigen. 'AT midnight "Do
maintenance"'???

Wann kam anacron raus?

> Ich unterstelle AT&T dass sie sich irgendwas dabei gedacht haben, als sie das
> Ding entwickelten. Ob wir das heute noch nachvollziehen können, ist eine
> andere Sache. :-)

Was ich über die anderen (3B Serie) las hat man die vor allem zur
Steuerung von Vermittlungen eingesetzt. Und wollte u.a. (erfolglos) IBM
Paroli bieten. Naheliegend wäre das sie 486 als billigere Massen-CPU
genommen haben um kompatibles im Angebot zu haben und zugleich die
Vermittlungs-Rechner billiger zu produzieren. Hätte dann ja auch nicht
beim Unix bleiben müssen. Stelle dir ein OS/2 auf so einer Kiste mal
vor. ;-)

[Kay Martinen]

Am 20.03.23 um 23:06 schrieb Sebastian Barthel:

> Am Mon, 20 Mar 2023 14:49:35 +0000 schrieb Peter Heitzer:
>
>> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>>> Peter Heitzer wrote:
>>
>>>>> Ok, der 6502 ist eine frühe Form einer RISC-Architektur :-)
>>>> Wobei sich das Reduced auch auf die Anzahl der Register bezieht, quasi
>>>> ein Super-RISC ;-)
>>
>>> Der 6502 hat drei sehr schnelle Register und 256 schnelle Register (1
>>> Takt Zuschlag) ;-) Mit etwas externer Hardware ließe sich der externe
>>> "Registersatz" beim Kontextswitch in 4 Zyklen umschalten.

Und der Stack? Wenn schon "Kontextswitch" dann sollte man dessen
limitierung auch nicht vergessen.

>> Da gab es AFAIR mal eine Bauanleitung für "direct page" für den 6502,
>> womit man die ZP in eine beliebige Page legen konnte. Es gibt auch ein

Durch sinniges vertauschen von Adressleitungen vielleicht?

>> nettest Video von einem Vortrag über eine MMU für den 6502 (hatte ich
>> vor einiger Zeit hier gepostet).

War das zufällig ein C-128? Der hat eine MMU. Muß er ja weil er viel um
zu schalten hat. Z.b. konnte man das untere RAM auf die 2. Bank umschalten.

>> Die CMOS-Varianten hatten zumindest Push- und Pullbefehle für die
>> Indexregister. Das war für einen schnellen Kontextswitch schon sehr
>> nützlich.

Toll. Noch mehr Bytes auf dem Stack. Und dann?

> Mögt ihr euch da bitte mal noch etwas genauer erinnern ? Zumindest
> soweit, daß man mal - mit bißchen Aussicht auf Erfolg - anfangen kann im
> Netz nach soetwas zu suchen. Also Zeitschrift oder DiscMag, wo das
> vorgestellt worden ist ? Evtl ein Name von einem
> "Hauptverantwortlichen" / "Creator" / "Maker" ? Oder sonstige Hinweise,
> womit man gezielter nach sowas suchen kann. Klingt nämlich irgendwie SEHR
> interessant.

Ich weiß von den o.g. Quellen nix außer dem was ich oben kommentierte.

[Dennis Grevenstein]

p...@pocnet.net wrote:
>
> So wie ich das aus den alten iXen rausgelesen habe scheint Motorola über
> längere Zeit Probleme gehabt zu haben, den 040 in ausreichender Stückzahl zu
> fertigen. Die Hersteller wollten aber verkaufen, also baute man mit dem was
> verfügbar war. Kann man kaum den Herstellern anlasten. :-)

selbst wenn er verfügbar gewesen wäre, war er doch immer noch
deutlich langsamer als die RISC Konkurrenz. Es hatte wohl schon
seinen Grund, warum Sun, HP, SGI, Apple und Motorola selbst alle
von 68k zu einer RISC CPU gewechselt sind.
Da war einfach die Zeit um, wie bei der VAX. Nur dass der 68k
langfristig länger gelebt hat durch verschiedene andere Anwendungen.

[Hermann Riemann]

Am 20.03.23 um 16:41 schrieb Gerrit Heitsch:

> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
> bezahlbar? Immer her mit.

Mich nicht.
Der Amiga war anfangs ein flimmernder Spielcomputer
der Atari ST einer zu Programmieren.

[Hermann Riemann]

Am 20.03.23 um 22:49 schrieb Dennis Grevenstein:

> Atari hat noch 68030 verbaut. Ist kolossal fehlgeschlagen.
> Warum hätte es beim Amiga anders sein sollen?

Der Atari hinkte bei Grafik hinter dem PC mit Tseng Karte
hinterher.
Als dann noch Borland C++ nur für den PC gab,
bin ich umgestiegen.

Allerdings kam C++ und OS/2 bei mir nie
zur praktischen Anwendung.
Die kam erst mit Linux und C.

Hermann
dem ein PC kompatibel* mit Motorola CPU
statt intel CPU lieber gewesen wäre.

*:( PC mit ISA.. Bus und mit vielen Hersteller )

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 20.03.23 um 23:44 schrieb p...@pocnet.net:

Der 8088 war rechtzeitig verfügbar, der 68008 nicht.

[Gerrit Heitsch]

Der kam aber erst 1989 raus, da gab es den Amiga schon eine ganze Weile.
Was hast du bis dahin benutzt?

Und mit den 50Hz konnte man leben. Spätere Versionen waren zwischen PAL
und NTSC umschaltbar, wer wollte konnte also jederzeit 60 Hz haben.

Gerrit

[Gerrit Heitsch]

Da musste man aber alles per CPU machen. Mit dem SM124 konnte ich mich
auch nicht anfreunden. Ein kleiner Monitor und dann wird dessen Fläche
nicht einmal voll ausgenutzt?

Gerrit

[Hermann Riemann]

Am 21.03.23 um 06:45 schrieb Gerrit Heitsch:

> On 3/21/23 05:55, Hermann Riemann wrote:
>> Am 20.03.23 um 16:41 schrieb Gerrit Heitsch:
>>
>>> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
>>> bezahlbar? Immer her mit.
>>
>> Mich nicht.
>> Der Amiga war anfangs ein flimmernder Spielcomputer
>> der Atari ST einer zu Programmieren.
>
> Da musste man aber alles per CPU machen.

Der Grafikspeicher lag 32 kB vor dem Speicherende.
Damit konnte ich gut mit Pixel umgehen.

> Mit dem SM124 konnte ich mich auch nicht anfreunden.

Es war damals ausreichend.

> Ein kleiner Monitor und dann wird dessen Fläche
> nicht einmal voll ausgenutzt?

Später hatte ich den (14 oder 15)" Monitor Nec Multisync 3d.
Der konnte alle 3 Auflösungen.
Und funktionierte später auch am PC.
--
http://www.hermann-riemann.de

[Gerrit Heitsch]

On 3/21/23 07:02, Hermann Riemann wrote:
> Am 21.03.23 um 06:45 schrieb Gerrit Heitsch:
>> On 3/21/23 05:55, Hermann Riemann wrote:
>>> Am 20.03.23 um 16:41 schrieb Gerrit Heitsch:
>>>
>>>> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
>>>> bezahlbar? Immer her mit.
>>>
>>> Mich nicht.
>>> Der Amiga war anfangs ein flimmernder Spielcomputer
>>> der Atari ST einer zu Programmieren.
>>
>> Da musste man aber alles per CPU machen.
>
> Der Grafikspeicher lag 32 kB vor dem Speicherende.
> Damit konnte ich gut mit Pixel umgehen.

Konnte man den auch verlegen oder war er dort festgenagelt? Konnte man
zumindest zwischen zwei Framebuffern umschalten, so daß man nicht im
aktiven rumschreiben musste?

>> Mit dem SM124 konnte ich mich auch nicht anfreunden.
>
> Es war damals ausreichend.

Nicht wirklich, ich fand ihn viel zu klein.

>> Ein kleiner Monitor und dann wird dessen Fläche nicht einmal voll
>> ausgenutzt?
>
> Später hatte ich den (14 oder 15)" Monitor Nec Multisync 3d.
> Der konnte alle 3 Auflösungen.
> Und funktionierte später auch am PC.

Den hatte ich auch, am Linux-PC. Immerhin gingen damit 800 x 600 in lesbar.

Gerrit

[Dennis Grevenstein]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>
> Der Amiga war anfangs ein flimmernder Spielcomputer
> der Atari ST einer zu Programmieren.

Ich habe ja in der Zeit nicht programmiert. Wir hatten einen
Amiga 500 in der Verwandschaft und das Ding war schon echt toll.
Grafik und Sound waren deutlich besser als bei unserem Atari ST
zu Hause. Es gab eine riesige Box mit Disketten voller Spiele.
Einfach die Diskette einlegen, Amiga einschalten und los geht es.
Ich habe mir viele Jahre später von fans erzählen lassen wie
toll der Amiga und sein AmigaOS gewesen wären, aber ich habe
ehrlich nie mehr als kickstart gesehen und hunderte Stunden vor
einem Amiga verbracht.
Konsequenterweise erfolgte später in der Verwandschaft auch
ein "upgrade" vom Amiga 500 auf Super Nintendo. Das SNES konnte
den Amiga-Monitor verwenden und das gab ein sehr schönes Bild,
besser als bei einem kleinen Fernseher.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the

shoulder of Orion. I watched C-beams glitter in the dark near the Tannhaeuser

[Dennis Grevenstein]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>
> Da musste man aber alles per CPU machen. Mit dem SM124 konnte ich mich
> auch nicht anfreunden. Ein kleiner Monitor und dann wird dessen Fläche
> nicht einmal voll ausgenutzt?

Den fand ich tatsächlich ganz gut. Die Größe hat für den ST ausgereicht
und das Bild war gut. Hat halt ein bisschen nachgeglüht...
Ich habe so einige schlechtere s/w Monitore später gesehen, selbst bei
Systemen, die extrem viel teurer waren als ein ST.

[Gerrit Heitsch]

On 3/21/23 10:58, Dennis Grevenstein wrote:
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>>
>> Da musste man aber alles per CPU machen. Mit dem SM124 konnte ich mich
>> auch nicht anfreunden. Ein kleiner Monitor und dann wird dessen Fläche
>> nicht einmal voll ausgenutzt?
>
> Den fand ich tatsächlich ganz gut. Die Größe hat für den ST ausgereicht
> und das Bild war gut.

Wäre noch besser gewesen wenn das Bild vom Format her die Röhre voll
ausgenutzt hätte und nicht diesen breiten schwarzen Rahmen gelassen hätte.

> Ich habe so einige schlechtere s/w Monitore später gesehen, selbst bei
> Systemen, die extrem viel teurer waren als ein ST.

Schlechter geht immer.

Gerrit

[Gerrit Heitsch]

On 3/21/23 10:58, Stefan Ram wrote:

> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>> Und mit den 50Hz konnte man leben. Spätere Versionen waren zwischen PAL
>> und NTSC umschaltbar, wer wollte konnte also jederzeit 60 Hz haben.
>

> Für mich war zu meiner Amiga-Zeit das Unangenehmste an den
> Farbmonitoren, die ich damals dazu hatte, das große Lochraster.

Ich hatte am Ende einen A2320 Flickerfixer in meinem A2000 und dazu
einen passenden Multisync-Monitor.

Waren irgendwas in 700 x 580 oder ähnlich, eben 640 x 512 plus den
maximal möglichen Overscan.

Gerrit

[Michael Kraemer @ home]

Stefan Möding wrote:
> p...@pocnet.net writes:
>
>
>>Herausragende Eigenschaft: Komplett in Deutsch...

>
>
> Mit
>
> sort: Schreiben fehlgeschlagen: Standard Ausgabe: Pfeife gebrochen
>
> und anderen Klassikern? IBM AIX war damals auch so ein Ding, wo man sich
> als Unix-Kenner bei den deutschen Fehlermeldungen nur am Kopf kratzen
> konnte.
>

IBM war eben damals schon pc und inkludierte die indigenen Bewohner
Mitteleuropas ...

[Markus Elsken]

Moin!

Am 20.03.23 um 02:06 schrieb Michael Kraemer @ home:
> Kaum jemand ware damals auf die Idee gekommen, das mit 486/586 zu machen.

Kleine Anekdote dazu: wir haben im Oldenburger Computermuseum eine SGI
Onyx2. Mannshoher Serverschrank, untere Hälfte CPU und I/O, obere Hälfte
GPU. Vorne dran eine Leiste zur Steuerung anderer Rechner (man konnte
m.W. bis zu 255 zu einem Rechner zusammenschalten). Ein
postkartengrosses LCD mit ein paar Tasten. Dafür wurde ein 486er
ver(sch)wendet :D

mfg Markus

[Gerrit Heitsch]

On 3/21/23 12:34, Ralf Kiefer wrote:

> Gerrit Heitsch wrote:
>
>> Wäre noch besser gewesen wenn das Bild vom Format her die Röhre voll
>> ausgenutzt hätte und nicht diesen breiten schwarzen Rahmen gelassen hätte.
>

> Meine Kollegen aus dem Atari-Lager öffneten den SM124 und schraubten ein
> wenig an diversen Potis. Mit Erfolg :-)

Ja, das konnte man tun. Konnte allerdings die Lebensdauer reduzieren.

Gerrit

[Markus Elsken]

Moin!

Am 20.03.23 um 01:27 schrieb Michael Kraemer @ home:
> Die damaligen RISCs versaegten so ziemlich alles,
> was damals als CISC auf dem Markt war (x86,68k,VAX).

Wir haben im Oldenburger Computermuseum in der Abteilung "Mitte 80er"
eine Lisa2, einen Würfelmac, einen ST, eine Amiga, einen 386 und einen
Acorn Archimedes. Letzterer zieht lachend davon. Leider gab es damals zu
wenig Software (die man dezentral sichern konnte), daher blieb ihm der
Erfolg versagt.

mfg Markus

[Michael Kraemer @ home]

p...@pocnet.net wrote:

>
> Ich unterstelle AT&T dass sie sich irgendwas dabei gedacht haben, als sie das
> Ding entwickelten. Ob wir das heute noch nachvollziehen können, ist eine
> andere Sache. :-)

es gibt natuerlich auch kleinere Multiuserumgebungen als Grossrechenzentren.
Fuer einen Abteilungsserver zB mag das Teil passend gewesen sein.

[Dennis Grevenstein]

Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>
> Wäre noch besser gewesen wenn das Bild vom Format her die Röhre voll
> ausgenutzt hätte und nicht diesen breiten schwarzen Rahmen gelassen hätte.

bestimmt.

>> Ich habe so einige schlechtere s/w Monitore später gesehen, selbst bei
>> Systemen, die extrem viel teurer waren als ein ST.
>
> Schlechter geht immer.

ja, natürlich. Aber für mich war der SM124 halt immer so ein
Referenzpunkt und daher habe ich mich oft gefragt, warum ich
mir bei einer viel teureren Unix workstation manchmal so ein
matschiges, flimmerndes Bild angucken musste.

gruss,
Dennis

--
"I've seen things you people wouldn't believe. Attack ships on fire off the

shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser

[Markus Elsken]

Moin!

Am 20.03.23 um 02:28 schrieb Ralf Kiefer:
> Ganz so schlimm sah es mit der 68060-CPU nicht aus.

Sie hatte das gleiche Problem wie schon der 68040 und später der PPC G4.
Zu spät am Markt, zu langsame Entwicklung. Schon beim 040 mussten die
Hersteller tricksen, weil die CPU nicht lieferbar war: Emulatorboards
mit 68030/882 und Cache (aus so einem stammte meine Bestückung für die
PAK/3), welches dann später gegen die echte CPU getauscht wurde. Als
dann endlich der 060 kam war der Wechsel zu PPC vollzogen.
Beim PPC wiederholte sich das Elend, der G4 kam nicht in die Pötte, der
G5 kam gar nicht. Und nein, der G5 bei Apple ist keine
Weiterentwicklung, sondern eine aus der Not geborene
Einzelkern-Auskopplung vom Power4. Schnell rechnen konnte der, aber
Strom sparen irgendwie nicht. Deswegen gab es auch keine PowerBook G5.
Schon im iMac war das Ding ein Eiertanz. Riesige Kühlkörper aus
Vollkupfer und das halbe Mainboard als Spannungswandler.
Wer war da noch gleich für die Entwicklung zuständig? Ach ja, Motorola.

mfg Markus

[Michael Kraemer @ home]

Sebastian Barthel wrote:

> Der 68080 ist auf alle Fälle ein wirklich bemerkenswertes Projekt. Und es
> ist ja nicht nur eine CPU, sondern kommt gleich mit einem ganzen Satz an
> verbesserten Chips wie z.B. dem SuperAGA.

Ja, es hat schon einen gewissen Charme, da weiterzumachen,
wo C= und Motorola vor 30 Jahren den Loeffel abgegeben haben.

Problem duerfte werden (neben dem lieben Geld),
dass der Kopf dahinter eine ziemlicher Egomane mit
ungesundem Selbstbewusstsein ist.
Undiplomatisch und mit dem Talent gesegnet,
es mit jedem zu verkacken,
den man fuer die gute Sache eigentlich brauchen koennte.
Jetzt soll auch noch ein neues weiteres amigoides OS geschaffen werden,
als ob wir davon nicht schon genug haetten.

Irgendwie scheinen sich technische und soziale Intelligenz
genetisch auszuschliessen.

[Dennis Grevenstein]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>
> Ist's 'ne UL oder wahr, daß Apple im aktuellen Betrübssystem in der
> deutschen Fassung den ':' zuläßt, damit das Verzeichnis "Benutzer:Innen"
> heißen kann?

stimmt so.
Sind aber "Benutzer:innen" mit kleinem "i".
Man kann es wieder loswerden mit "sudo rm /Users/.localized".

[Markus Elsken]

Moin!

Am 21.03.23 um 06:45 schrieb Gerrit Heitsch:

> Da musste man aber alles per CPU machen. Mit dem SM124 konnte ich mich
> auch nicht anfreunden. Ein kleiner Monitor und dann wird dessen Fläche
> nicht einmal voll ausgenutzt?

Den Rand konnte man problemlos beseitigen. Der Monitor selbst war
Spitze, wenngleich ich den SM194 besser fand. Wenn da nur nicht das
Platzproblem Grafikkarte und PAK/ gewesen wäre... also Tower.

mfg Markus

[Gerrit Heitsch]

On 3/21/23 12:49, Markus Elsken wrote:
> Moin!
>
> Am 21.03.23 um 06:45 schrieb Gerrit Heitsch:
>> Da musste man aber alles per CPU machen. Mit dem SM124 konnte ich mich
>> auch nicht anfreunden. Ein kleiner Monitor und dann wird dessen Fläche
>> nicht einmal voll ausgenutzt?
>
> Den Rand konnte man problemlos beseitigen.

Nur wenn man sich traute den Monitor zu zerlegen. Nicht jeder ist dazu
in der Lage oder will in einem Gerät mit Hochspannung Einstellungen im
Betrieb vornehmen.

Gerrit

[Dennis Grevenstein]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>
> Es ging nicht um das Jahr 1980, sondern 1990.
>
> Das bekannteste Beispiel für die 040-Verzögerung ist der Mac IIfx, in
> den Apple alles reinpackte, was eine 68030-CPU schnell machte:
> Level-2-Cache, spezielles, schnelles RAM und einen Coprozessor für
> Seriell inkl. LocalTalk.

Ich will den IIfx sicher nicht schlechtreden, aber einzigartig
war das nicht. Die Sun 3/470 (ja, ist viel größer...) gab es
ein Jahr früher als den IIfx, auch mit 030, 64KB cache, 80ns
Speicher.
Noch beeindruckender finde ich die HP9000/400 (t oder s) mit
50MHz 030 in einem Adapterboard für einen 040 Sockel. Man konnte
die Maschine später auf einen 040 upgraden.
Das Problem hatten also alle.

[Dennis Grevenstein]

Markus Elsken <markus...@ewetel.net> wrote:
>
> Beim PPC wiederholte sich das Elend, der G4 kam nicht in die Pötte, der
> G5 kam gar nicht. Und nein, der G5 bei Apple ist keine
> Weiterentwicklung, sondern eine aus der Not geborene
> Einzelkern-Auskopplung vom Power4. Schnell rechnen konnte der, aber
> Strom sparen irgendwie nicht. Deswegen gab es auch keine PowerBook G5.
> Schon im iMac war das Ding ein Eiertanz. Riesige Kühlkörper aus
> Vollkupfer und das halbe Mainboard als Spannungswandler.
> Wer war da noch gleich für die Entwicklung zuständig? Ach ja, Motorola.

Der PPC970 = G5 war tatsächlich von IBM. Sie haben den auch in
ein paar wenigen RS/6000 verbaut.
siehe hier:
https://de.wikipedia.org/wiki/PowerPC_970

Wenn man sich die Daten anguckt, dann bringt der PPC970 eine
TDP, die im Bereich der üblichen x86-64 Desktop CPUs liegt.
Es wäre vermutlich möglich gewesen, den irgendwie in ein
Notebook zu packen, aber sicher nicht im Rahmen der Designs,
die Apple hätte verkaufen wollen. Und dass einzelne Varianten
mit hohem Takt so heiss wurden, dass Apple im Powermac eine
Flüssigkeitskühlung verbauen musste, war sicher auch kein
gutes Zeichen für die Zukunftsfähigkeit der CPU.

Ich weiss, dass ich damals auch auf ein G5 notebook gewartet
habe. Rückblickend habe ich mich allerdings auch gefragt, ob
man da nicht einfach irgendwelche Verträge noch erfüllen musste
und ein Adaptieren des Power4 einfach billiger war als eine
komplette Neuentwicklung. Apple hat ja aus dem Wechsel von
PPC auf x86 ein großes Geheimnis gemacht, aber vermutlich
waren die Pläne schon jahrelang vorhanden.

[Dennis Grevenstein]

In de.alt.folklore.computer Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>
> 2020 sollte ich dann erstmal einen Python-Programmierkurs in
> Englisch geben. Der fiel dann zwar wegen des Lockdowns aus,
> aber das war nochmal ein Motivationsschub, der dazu führte,
> daß ich heute weiterhin aktiv Englisch lerne, falls einmal
> wieder so etwas kommt. Der Kurs war für Doktoranden der
> Linguistik gedacht.

Ich dachte immer, das Leben an der Uni findet im Zweifelsfall
sowieso auf Englisch statt. Oder was macht Ihr mit Gastdozenten
und Wissenschaftlern aus dem Ausland?
In meiner Wahrnehmung ist das auch eher normal, dass Lehrveranstaltungen
im Zweifelsfall auch mal unangekündigt einfach auf Englisch
gegeben werden.

[Dennis Grevenstein]

Michael Kraemer @ home <M.Kr...@gsi.de> wrote:
>
> Irgendwie scheinen sich technische und soziale Intelligenz
> genetisch auszuschliessen.

Ich vermute eher, dass sich dieses Computer-Hobby bzw. solche
Projekte wie Du sie beschreibst, einfach als Nische für Leute
mit einer bestimmten Konfiguration von Eigenschaften gut eignen.
Du müsstest Dir angucken, wie diese Eigenschaften in der Allgemein-
bevölkerung und einer repräsentativen Stichprobe verteilt sind.

[Hermann Riemann]

Am 21.03.23 um 07:30 schrieb Gerrit Heitsch:

> On 3/21/23 07:02, Hermann Riemann wrote:
>> Am 21.03.23 um 06:45 schrieb Gerrit Heitsch:
>>> On 3/21/23 05:55, Hermann Riemann wrote:
>>>> Am 20.03.23 um 16:41 schrieb Gerrit Heitsch:
>>>>
>>>>> Mich hat der Amiga damals sehr gereizt. Echtes Multitasking in
>>>>> bezahlbar? Immer her mit.
>>>>
>>>> Mich nicht.
>>>> Der Amiga war anfangs ein flimmernder Spielcomputer
>>>> der Atari ST einer zu Programmieren.
>>>
>>> Da musste man aber alles per CPU machen.
>>
>> Der Grafikspeicher lag 32 kB vor dem Speicherende.
>> Damit konnte ich gut mit Pixel umgehen.
>
> Konnte man den auch verlegen oder war er dort festgenagelt?

bei meinem ersten 386 PC mit Linux gab es noch eine Funktion der Art:
liefere_Adresse_vom Bildschirm_Puffer.

> Konnte man zumindest zwischen zwei Framebuffern umschalten,

Nein aber der 68000 braucht nicht alle Speichertakte,
so dass der Grafikchip ohne Zeitverlust auf den Hauptspeicher zugreifen
konnte.

> so daß man nicht im aktiven rumschreiben musste?

De gab Bitblt oder so ähnlich,
mit der man ein Rechteck schnell verschieben konnte.
Erst per Maschinencode, dann per hardware.

>>> Mit dem SM124 konnte ich mich auch nicht anfreunden.

>> Es war damals ausreichend.

> Nicht wirklich, ich fand ihn viel zu klein.

Das ist auch eine Frage vom Abstand: Auge - Monitor.

>>> Ein kleiner Monitor und dann wird dessen Fläche nicht einmal voll
>>> ausgenutzt?
>>
>> Später hatte ich den (14 oder 15)" Monitor Nec Multisync 3d.
>> Der konnte alle 3 Auflösungen.
>> Und funktionierte später auch am PC.

> Den hatte ich auch, am Linux-PC. Immerhin gingen damit 800 x 600 in lesbar.

Und auch 1024x768 für die erste Tseng Grafikkarte mit 1 MB RAM
Da gab es noch Farbtabellen.

Hermann
der auch man 1600x1200 an einem 15" Monitor verwendet hat.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.03.23 um 12:43 schrieb Dennis Grevenstein:

> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>>
>> Wäre noch besser gewesen wenn das Bild vom Format her die Röhre voll
>> ausgenutzt hätte und nicht diesen breiten schwarzen Rahmen gelassen hätte.
>
> bestimmt.
>
>>> Ich habe so einige schlechtere s/w Monitore später gesehen, selbst bei
>>> Systemen, die extrem viel teurer waren als ein ST.
>>
>> Schlechter geht immer.
>
> ja, natürlich. Aber für mich war der SM124 halt immer so ein
> Referenzpunkt und daher habe ich mich oft gefragt, warum ich
> mir bei einer viel teureren Unix workstation manchmal so ein
> matschiges, flimmerndes Bild angucken musste.

Als Gegenstück habe ich mal CGA auf einen 21" Röhrenmonitor gesehen.
--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.03.23 um 10:54 schrieb Dennis Grevenstein:

> Hermann Riemann <nosp...@hermann-riemann.de> wrote:
>>
>> Der Amiga war anfangs ein flimmernder Spielcomputer
>> der Atari ST einer zu Programmieren.
>
> Ich habe ja in der Zeit nicht programmiert.

computer, die ich nicht programmieren kann,
haben oft Einschränkungen, die ch nicht ändern kann.

> Wir hatten einen
> Amiga 500 in der Verwandschaft und das Ding war schon echt toll.

Wegen dem computer Spiel Aquanoid habe ich meiner Mutter
einen Amiga 500 gekauft.

> Grafik und Sound waren deutlich besser als bei unserem Atari ST
> zu Hause.

Amiga ist ( wie PC mit windows ) ein computer zum spielen.
Wogegen Atari ST ( wie PC mit Linux ) ein computer
zum selber software entwickeln ist.

> Es gab eine riesige Box mit Disketten voller Spiele.

Ich habe noch viele CDs mit nicht mehr funktionierende
DOS und windows 9* Spiele.
Zu spielen verwende ich derzeit dosbox.

> Einfach die Diskette einlegen, Amiga einschalten und los geht es.

Mit dem Vorspiel..

> Ich habe mir viele Jahre später von fans erzählen lassen wie
> toll der Amiga und sein AmigaOS gewesen wären, aber ich habe
> ehrlich nie mehr als kickstart gesehen und hunderte Stunden vor
> einem Amiga verbracht.

Die gleichen Spiel gab es weitgehend auch für windows.
Vereinzelt für Atari ST und Mac. Und später playstation ..

> Konsequenterweise erfolgte später in der Verwandtschaft auch

> ein "upgrade" vom Amiga 500 auf Super Nintendo. Das SNES konnte
> den Amiga-Monitor verwenden und das gab ein sehr schönes Bild,
> besser als bei einem kleinen Fernseher.

Eindrucksvollere Bilder mag es mit beamer und Leinwand geben.

In 10 Jahre wird vielleicht virtuell reality mit Brille
überwiegen, wo der Inhalt den Kopfbewegungen angepasst ist.

3 D kommt wieder, allerdings in einer virtuellen Entfernung von <= 3m
weil sonst Winkel zwischen rechts und links zu klein ist.

Hermann
der bei 3D Avatar und 3D Jurassic Park 2D Figuren gesehen hat.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.03.23 um 12:44 schrieb Markus Elsken:

> Moin!
>
> Am 20.03.23 um 02:28 schrieb Ralf Kiefer:
>> Ganz so schlimm sah es mit der 68060-CPU nicht aus.
>
> Sie hatte das gleiche Problem wie schon der 68040 und später der PPC G4.
> Zu spät am Markt, zu langsame Entwicklung.

Dann war intel einfach bei hardware Technik Spitze:
Höhere Taktfrequenzen und dichtere Transistoren auf dem Chip.
Das brachte das Geld für Weiterentwicklung,
die sich außer AMD andere nicht leisten konnte.

Hermann
der sich an einen großen Gebäude Komplex
in München Südrand erinnert,
wo erst Force, dann Motorola, dann intel groß angezeigt wurde.

--
http://www.hermann-riemann.de

[Hermann Riemann]

Am 21.03.23 um 11:12 schrieb Stefan Ram:

> Ich arbeitete in der zweiten Hälfte der Achtziger als Dozent
> für C-Programmierung an der Bildo-Akademie.

Das erinnert ich an ein C-Vorführung,
wo ich den Vorführer überraschte, das "hello world"
auch ohne #include ( in K&R C) problemlos funktioniert.

--
http://www.hermann-riemann.de

[Markus Elsken]

Moin!

Am 21.03.23 um 12:53 schrieb Gerrit Heitsch:

> Nur wenn man sich traute den Monitor zu zerlegen. Nicht jeder ist dazu
> in der Lage oder will in einem Gerät mit Hochspannung Einstellungen im
> Betrieb vornehmen.

Es gab damals eigentlich immer jemanden, den man fragen konnte und der
gemacht hat. Was ich damals neben der normalen Arbeit an den Ataris so
alles auf- und umgerüstet habe war schon schrät. RAM hochgezogen,
Serielle beschleunigt oder eine zweite eingebaut, Turboboards, Monitore
justiert etc. etc.
War eine spannende Zeit.

mfg Markus

[Markus Elsken]

Moin!

Am 21.03.23 um 14:49 schrieb Hermann Riemann:

>
> Dann war intel einfach bei hardware Technik Spitze:
> Höhere Taktfrequenzen und dichtere Transistoren auf dem Chip.

Der Sprung vom letzten PowerBook zum MBP bzw. iBook zum MB war schon
drastisch. Aber auch hier, intel bekam das mit den 10nm jahrelang nicht
hin und die Retina-MBP waren schon auf die versprochenen CPUs ausgelegt
und wurden mit der alten Technik zu heiss und bremsten.
Es gibt ein YT-Video, wo das letzte 16" intel-MBP gegen eins mit M1 pro
oder max getestet wird. Kaum wird Cinebench gestartet laufen beide
Lüfter direkt hoch, weil der i9 so wild heizt und schon wird so weit
gedrosselt, dass max. 85W verheizt werden. Das Book röhrt wie eine
Turbine. Der M1 dagegen? Volle Rechenleistung bei 22W (!) und der Lüfter
rampt zwar messbar, aber nicht hörbar hoch.
Selbst ein Mac Stdio mit M1 ultra und 128GB RAM bleibt unter maximaler
Last unhörbar.

mfg Markus

[Michael Kraemer @ home]

Dennis Grevenstein wrote:
> In de.alt.folklore.computer Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>
>> 2020 sollte ich dann erstmal einen Python-Programmierkurs in
>> Englisch geben. Der fiel dann zwar wegen des Lockdowns aus,
>> aber das war nochmal ein Motivationsschub, der dazu führte,
>> daß ich heute weiterhin aktiv Englisch lerne, falls einmal
>> wieder so etwas kommt. Der Kurs war für Doktoranden der
>> Linguistik gedacht.
>
>
> Ich dachte immer, das Leben an der Uni findet im Zweifelsfall
> sowieso auf Englisch statt. Oder was macht Ihr mit Gastdozenten
> und Wissenschaftlern aus dem Ausland?

wenn sie weg sind spricht man wieder deutsh,

> In meiner Wahrnehmung ist das auch eher normal, dass Lehrveranstaltungen
> im Zweifelsfall auch mal unangekündigt einfach auf Englisch
> gegeben werden.

ich erlebe es eher, dass alle froh sind,
wenn die VL dann doch auf deutsch gehalten wird,
jedenfalls dann, wenn alle im Raum eh Deutsche sind.

[Sebastian Barthel]

Am Tue, 21 Mar 2023 12:47:20 +0100 schrieb Michael Kraemer @ home:

> Sebastian Barthel wrote:
>
>> Der 68080 ist auf alle Fälle ein wirklich bemerkenswertes Projekt. Und
>> es ist ja nicht nur eine CPU, sondern kommt gleich mit einem ganzen
>> Satz an verbesserten Chips wie z.B. dem SuperAGA.
>
> Ja, es hat schon einen gewissen Charme, da weiterzumachen,
> wo C= und Motorola vor 30 Jahren den Loeffel abgegeben haben.
>
> Problem duerfte werden (neben dem lieben Geld),
> dass der Kopf dahinter eine ziemlicher Egomane mit ungesundem
> Selbstbewusstsein ist.
> Undiplomatisch und mit dem Talent gesegnet,
> es mit jedem zu verkacken,
> den man fuer die gute Sache eigentlich brauchen koennte.

Das ist deutlich ... , aber wahrscheinlich ist es sogar eine
Voraussetzung dafür, sowas in der Form machen zu können. Es ist halt aber
schade, weil es eben letztlich das bißchen Amiga, was noch da ist immer
weiter "zerfasert". Und da scheinen ja einige Player in ähnlicher Form
unterwegs zu sein.

> Jetzt soll auch noch ein neues weiteres amigoides OS geschaffen werden,
> als ob wir davon nicht schon genug haetten.

Ist doch aber konsequent - daß man dann auch sein eigenes OS haben
will ... ;)

Vielleicht hat er sich ja aber auch bei den Wächtern des OS eine Abfuhr
geholt, als er mal angefragt hat, wie es denn mit Erweiterungen für
seinen neuen Chipsatz so aussieht. Das versteht man da sowieso nicht, wie
das genau abläuft.
Und es gibt mittlerweile mindestens ein Handvoll Amiga Nachfolger bzw.
(ehemalige) Anwärter. Mir hat ja bisher am Besten der X1000 gefallen.

> Irgendwie scheinen sich technische und soziale Intelligenz genetisch
> auszuschliessen.

Soweit würde ich nicht gehen - gibt in dem Bereich auch nette Leute.
Und je größer und erfolgreicher sowas als Firma ist, desto mehr wird das
technische "unwichtiger" (weil im Team verteilbar), es hat dann aber oft
nicht mehr so einen eigenständigen Charakter, weshalb ganz neue Lösungen,
dann evtl. auch nicht kommen sondern sich mehr am Mainstream orientiert
wird.

Gerade der Amiga ist ja am Anfang ein Paradebeispiel für extrem gutes
Teamwork. Und wenn man da heute Interviews mit diesen Leuten aus der
Ursprungsfirma anschaut, scheinen die trotz Nerdtum nicht total
"abgefahren" zu sein.


Gruß,
SBn

[Gerald E¡scher]

Dennis Grevenstein schrieb am 21/3/2023 13:20:

> Ich weiss, dass ich damals auch auf ein G5 notebook gewartet
> habe. Rückblickend habe ich mich allerdings auch gefragt, ob
> man da nicht einfach irgendwelche Verträge noch erfüllen musste
> und ein Adaptieren des Power4 einfach billiger war als eine
> komplette Neuentwicklung. Apple hat ja aus dem Wechsel von
> PPC auf x86 ein großes Geheimnis gemacht, aber vermutlich
> waren die Pläne schon jahrelang vorhanden.

Kürzlich irgendwo gelesen, Apple hat von Anfang an MacOS X parallel für
x86 entwickelt. Aber vielleicht auch nur ein Gerücht.

--
Gerald

[Michael Kraemer @ home]

Dennis Grevenstein wrote:

> Der PPC970 = G5 war tatsächlich von IBM. Sie haben den auch in
> ein paar wenigen RS/6000 verbaut.
> siehe hier:
> https://de.wikipedia.org/wiki/PowerPC_970

Ja, IntelliStation 185, letzte IBM workstation, habe eine auf der Arbeit.
Die HW ist eigentlich ganz flott, nicht besonders laut.
Dumm nur, dass man den CPU-Kuehlkoerper 1x im Jahr entflusen muss und man etwas
schwer ran kommt.

> Wenn man sich die Daten anguckt, dann bringt der PPC970 eine
> TDP, die im Bereich der üblichen x86-64 Desktop CPUs liegt.
> Es wäre vermutlich möglich gewesen, den irgendwie in ein
> Notebook zu packen, aber sicher nicht im Rahmen der Designs,
> die Apple hätte verkaufen wollen. Und dass einzelne Varianten
> mit hohem Takt so heiss wurden, dass Apple im Powermac eine
> Flüssigkeitskühlung verbauen musste, war sicher auch kein
> gutes Zeichen für die Zukunftsfähigkeit der CPU.

Naja, wenn es ein Startup schafft:
https://en.wikipedia.org/wiki/PWRficient
warum dann nicht IBM/Moto?

Apple hat den Laden sogar gekauft, den Prozessor aber gekillt.
Doppelt aergerlich:
der PA6T haette auch ein NextGen Amiga Prozessor werden sollen.

[Hermann Riemann]

Am 21.03.23 um 15:08 schrieb Markus Elsken:

> Moin!
>
> Am 21.03.23 um 14:49 schrieb Hermann Riemann:
>>
>> Dann war intel einfach bei hardware Technik Spitze:
>> Höhere Taktfrequenzen und dichtere Transistoren auf dem Chip.
>
> Der Sprung vom letzten PowerBook zum MBP bzw. iBook zum MB war schon
> drastisch.

..

> Selbst ein Mac Stdio mit M1 ultra und 128GB RAM bleibt unter maximaler
> Last unhörbar.

Das ist lange her seit Motorola.
Südkorea und Taiwan entwickeln und produzieren die dichtesten Chips.

--
http://www.hermann-riemann.de

[Michael Kraemer @ home]

Sebastian Barthel wrote:

> Vielleicht hat er sich ja aber auch bei den Wächtern des OS eine Abfuhr
> geholt, als er mal angefragt hat, wie es denn mit Erweiterungen für
> seinen neuen Chipsatz so aussieht.

Kommt halt auf den Ton der "Anfrage" an.
So wie er sich im Amiga News Forum gibt wundert es mich nicht,
dass er sich eine Abfuhr geholt hat.
"Kommunikation ist definitiv nicht Deine Staerke"
wurde er da mal beschieden.

[Sebastian Barthel]

Am Mon, 20 Mar 2023 22:41:03 +0000 schrieb poc:

> Sebastian Barthel <nait...@freenet.de> wrote:
> ...
>> Bei Beispiel PC ( 4 x 486 ) und dem Wissen, wie sich so eine 486er
>> generell anfühlt, würde ich sagen, daß da keine 12 Leute mit einer
>> grafischen Oberfläche vernünftig auf dem Gerät arbeiten können.
>
> Deckt sich mit meinem Bauchgefühl. Andererseits ist das auch wiederum
> abhängig davon, was die 12 X11-User genau machen.
>
>> Bei den SPARCs ist es zumindest auf den Workstations und kleinen
>> Servern anscheinend so, daß die immer unglaublich viel Bandbreite zum
>> RAM haben.
>
> Und im Vergleich zum Cache doch nicht genug. ;-)
>
>> Deshalb steckt man dort ja oft RAMs auch in 4er Grüppchen ein.
>
> Was für RAMs? Mit 30-Pin SIMMs bedeutet eine Vierergruppe 32 Bit, bei
> PS/2 schon 128. Ich kenne die Suns nicht gut genug um zu wissen, was die
> für RAM-Bausteine nutz(t)en. Ich weiss aber dass die 486er teilweise
> 30-Pin SIMMs benutzten und teilweise auch schon PS/2. Erstere musste man
> in Vierergruppen tauschen, letztere durfte man einzeln. Also ziemlich
> eindeutig ein 32-Bit Bus. :-)

Na, bei meiner Sun U60 z.B. sind das so sehr spezielle Sun RAMs, die man
immer zu viert einsteckt - das Handbuch sppricht dann von 576 Bit
Datenbreite (inkl. ECC). Da sit schon anders als bei einem vergleichbaren
PC aus der Zeit, der wahrscheinlich noch 72pol EDO oder 168pol DIMMs
hatte.

Bei den kleineren älteren Suns gibt es das evtl. in der Form auch nicht
(IPX, IPC), aber die "richtigen" Maschinen sollten es eigentlich auch
schon gehabt haben. Heute würde man das wahrscheinlich Dual-Channel Mode
nennen, nur daß es eben da ein Quad-Channel Mode ist.


>> Das sollte man ziemlich gut dann merken, wenn der Mechanismus von oben
>> "abgesättigt" ist und Daten ständig auch mit dem RAM getauscht werden
>> müssen. Eine SUN bleibt dann halt irgendwie halbwegs lauffähig, einen
>> 486er legt es dann komplett still. Wäre so meine Vermutung.
>
> Klingt auf jeden Fall schlüssig. Ob in der Praxis so ein Punkt erreicht
> werden kann, bevor ein handelsüblicher 486er sich über das damals
> übliche lahme I/O-Interface (IDE) zu tode swappt, wäre noch
> festzustellen.
>
> Ich muss mal schauen, was ich an Hardware einsatzbereit zu Verfügung
> habe. Prinzipiell wäre z. B. das parallele Starten von mehreren gzip
> Prozessen eigentlich eine gute Annäherung. Was meinst Du?


Das ist eine gute Frage.

gzip macht halt beides - es füllt Daten und Programmcache, auch wenn der
evtl. noch einheitlich ist.

Wenn man rein das Cachen testen will, wäre es evtl. gut, ein kleines
Routinchen zu nehmen, was rechnet; etwa einen nach oben hin offenen
Fibonacci / Primzahlengenerator oder vieleicht besser einen, der nur bis
z.B. zur 10000 zählt und dann wieder neu anfängt. Und diesen dann
beliebig oft zu starten und zu schauen, ob irgendwann bei allen die
benötigten Zeiten einbrechen.
Und getrennt davon, was, das eher nur den Datencache testet. Also etwa
sowas wie eine Routine, die ständig das gleiche Bild anzeigt und löscht,
immer im Wechsel. Und davon startet man dann beliebig viele und mißt die
Zeiten. Damit man nicht letztlich Plattenzugriffe mißt, wäre es evtl.
geschickt die Bilder aus eine RAM Disk zu laden.
GZip geht aber wahrscheinlich auch gut. Macht aber eben meist beides -
viel Rechnen und viele Daten bewegen.

Vielleicht findet man ja im Universum der SPEC performance Messungen
irgendwo was Erhellendes zum Thema "Cache"

<https://netlib.org/performance/html/PDStop.html>
<https://netlib.org/performance/html/spec.html>

und heute bei

<https://www.spec.org/>

oft haben die ja bei den Testbeschreibungen dabei, was es mißt und was
man beachten muß, bzw. warum manche Test einfach obsolet geworden sind.

Vielleicht ist es auch einfach der falsche Test"parkour", weil die ja
doch eher auf reine Rechenleistung abheben - und genau darum geht es ja
bei vielen Usern/Tasks nicht unbedingt allein(ig).

Gruß, SBn

[Kay Martinen]

Am 21.03.23 um 10:58 schrieb Stefan Ram:
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> writes:
>> Und mit den 50Hz konnte man leben. Spätere Versionen waren zwischen PAL
>> und NTSC umschaltbar, wer wollte konnte also jederzeit 60 Hz haben.
>
> Für mich war zu meiner Amiga-Zeit das Unangenehmste an den
> Farbmonitoren, die ich damals dazu hatte, das große Lochraster.

Wirklich oder kommt dir das nur in der Rückschau so vor?

Ich hab damals kein Problem im Lochraster gesehen. Aber ich hatte
Monitore von 12" 14" 15" bis zu 17" bevor ich dann irgendwann mal einen
LCD hatte. Und an Grafikkarten waren es anfangs eher Trident TVGA, Tseng
ET 4000, und dann Matrox. Erst später kamen Nvidia Geforce für Spiele
dazu. Der einfluß der Graka, deren RAM Ausbau und Bildqualität waren
m.E. viel größer als der Pixelabstand des Monitors - den man eh nicht
ändern konnte.

Und das sage ich als Besitzer eines Philips Grünmonitors der so schlecht
geschirmt war das ich den mit Alufolie beklebte damit der C-128 ein
einigermaßen flimmer- und störungs-freies Bild zeigen konnte.

Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Michael Kraemer @ home]

Dennis Grevenstein wrote:

> Noch beeindruckender finde ich die HP9000/400 (t oder s) mit
> 50MHz 030 in einem Adapterboard für einen 040 Sockel. Man konnte
> die Maschine später auf einen 040 upgraden.

Anno 1990 hatte unsere Zentral-IT eine Ausschreibung bzgl Workstations um den
befuerchteten Wildwuchs unter den potentiellen UNIX-Nutzern etwas zu kanalisieren.
HP hat das auf dem lahmen Fuss erwischt:
sie konnten nur 030er Maschinen anbieten und haben deshalb 040er
Leistungswerte (MIPS/Mflops) "hochgerechnet".
Die sahen garnicht mal schlecht aus, mit den Sparcs konnten die mithalten,
evtl sogar mit DECs Mipsen.
Da es aber Vapourware war, hatten sie halt das Nachsehen.

[Dennis Grevenstein]

Nein, den Port gab es seit den NEXTSTEP Tagen in den frühen 1990ern.
Die wären ja blöd gewesen, wenn sie einen vorhandenen port auf
die verkaufsstärkste Plattform weltweit nicht wenigstens intern
am Leben erhalten. Dass es das prinzipiell geben muss, konnte
man z.B. daran erahnen, dass es Rhapsody (OS X Beta) für x86
gab, ebenso wie das blanke Darwin, den OS X Unix Unterbau.
Aber sie hatten halt damals keinen x86-64 port fertig, während
OS X auf G5 ja schon in einer 64bit Variante existierte.