Wo geht die Leistung moderner Hardware hin?

Computer: Hardware Hardware allgemein
#1

Hallo Experten,

ich habe kein spezielles Hardware- Problem das es zu lösen gilt, sondern möchte mit Euch diskutieren. Heute habe ich bei einem Freund auf seinem ca. 6 Jahre alten PC (Pentium900- Prozessor) WIN2000 installiert, das System läuft angenehm schnell.
Dabei habe ich mich gefragt, wie es möglich war auf einem Amiga oder Atari St eine schöne Benutzeroberfläche aufzubauen und bei heutigen Systemen die geschätzte 100 mal leistungsfähiger sind, gibt es mit „modernen“ Betriebssystemen Geschwindigkeitsprobleme.
Eine These von mir ist dass durch das Schreiben der Software in Programmiersprachen und das anschließende Kompilieren die Programme sich immer weiter aufblähen und dadurch langsamer werden. Hingegen war man bei den älteren leistungsschwächeren Rechnern gezwungen in Maschinensprache zu schreiben, das ergab dann einen straffen Programmcode.
Entschuldigt bitte wenn ich jetzt etwas falsches gesagt habe, ich kenn mich auf diesem Gebiet nicht so gut aus.

Was ist Eure Meinung zu dem Thema

#2

Moien

ich habe kein spezielles Hardware- Problem das es zu lösen
gilt, sondern möchte mit Euch diskutieren. Heute habe ich bei
einem Freund auf seinem ca. 6 Jahre alten PC (Pentium900-
Prozessor) WIN2000 installiert, das System läuft angenehm
schnell.

Blanke, sauber konfigurierte Systeme laufen fast immer schnell. Sogar windows XP (etwas ausgemistet und mit genug RAM) läuft auf Rechner aus der Klasse OK.

Dabei habe ich mich gefragt, wie es möglich war auf einem
Amiga oder Atari St eine schöne Benutzeroberfläche aufzubauen
und bei heutigen Systemen die geschätzte 100 mal
leistungsfähiger sind, gibt es mit „modernen“ Betriebssystemen
Geschwindigkeitsprobleme.

Da vergleichst du etwas Birnen und Äpfel. Die Varianz der Hardware (also die möglichen Kombinationen aus CPU, RAM, Graka, Soundkarte, Netzwerk,…) war zu Amigazeiten sehr übersichtlich. Heute gibts alleine dutzende aktuelle und hunderte noch lebende Grakamodelle. D.h. die modernen Teile müssen mit sehr viel mehr Situationen klarkommen, also flexibler arbeiten. Flexibel arbeiten bringt immer Geschwindigkeitsverluste. Kuck dir doch mal die superflexiblen Sprachen wie PHP und Perl an…

Dann können die heutigen Systeme viel mehr als die alten. OK, der Nutzer bekommt davon herzlich wenig mit. Aber an sich kann z.B. windows XP (fast) alle vorherigen windows versionen und grössere Teil von DOS nachmachen. Das musste windows 3.0 in dem Umfang nicht können (weils noch nicht soviele Vorgänger gab), Amiga & co auch nicht. Der legacy-support frist an manchen Stellen sehr viel Leistung.

(Der Legacy support ist auch der Grund weshalb wir immernoch x86’er benutzen. Der x86 war eigentlich als Festplattencontroller für Grossrechner ausgelegt und sollte nie mehr machen als Daten zwischen Platten und RAM hin und her schaufeln. Um Performance ging es nicht und das Ding im Nachhinein auf Performance trimmen war extrem aufwendig. Man hätte sich viele Man-jahre Arbeit sparen können wenn zu Pentium-I Zeiten ein von Grund auf neues System eingeführt worden wäre.)

Der nächste, ganze grosse Leistungsvernichter sind die kleinen Helferlein und Spyware. Es ist sehr nett mit 2 Mausklick die Auflösung zu ändern und das Wetter von Südostasien auf dem Desktop zu haben. Aber es kostet halt RAM (normaler, reiner Verbrauch und Platz der Pagetabelle), Internetbandbreite, Registry-grösse (auch so eine legacy-sünde), Startzeit, Zeit in der Prozessverwaltung, Platz auf der Platte,… usw. Und in letzter Zeit kommen immer mehr Helferlei auf: Virenscanner (kostet Plattenperformance), Firewalls (bringt den Netzwerkstack durcheinander), Spyware aller Art. Und auch Dinge wie das NX-Bit fallen für mich da drunter.

Eine These von mir ist dass durch das Schreiben der Software
in Programmiersprachen und das anschließende Kompilieren die
Programme sich immer weiter aufblähen und dadurch langsamer
werden.

Das gilt nur teilweise. Es gibt immer mehr „mobile“, flexible Systeme wie online Officesysteme oder gar lokale Programme erstellt in Flash, .NET oder java. Die sind langsamer als klassisch programmierte Programme. Alles was nicht auf der untersten Ebene (derzeit MFC bei windows, soll irgendwann gegen .NET ausgetauscht werden) aufsetzt und Frameworks, virtuelle Systeme oder ähnliches braucht ist langsam.

Allerdings sind im Gegenzug die Compiler viel besser geworden. Der Intel Compiler produziert heute Code der effizenter ist als alles was man vor 6 Jahren kannte. An eine solche Effizenz kommen weltweit höchstens eine Handvoll ASM-Programmierer ran. Mit Handgeschriebenem Machinencode ist heute auf dem x86 kein Blumentopf mehr zu gewinnen. Von diesen extrem guten Compilern profitiert alles und jeder, auch java, php, perl & co.

cu

#3

Hallo Pumpkin

Dabei habe ich mich gefragt, wie es möglich war auf einem
Amiga oder Atari St eine schöne Benutzeroberfläche aufzubauen
und bei heutigen Systemen die geschätzte 100 mal
leistungsfähiger sind, gibt es mit „modernen“ Betriebssystemen
Geschwindigkeitsprobleme.

Da vergleichst du etwas Birnen und Äpfel. Die Varianz der
Hardware (also die möglichen Kombinationen aus CPU, RAM,
Graka, Soundkarte, Netzwerk,…) war zu Amigazeiten sehr
übersichtlich.

Vor allem: Beim Amiga war die Situation ähnlich wie bei Apple, die Hardware und das OS stammten aus einer Hand. Zur selben Zeit war im Lager der IBM-kompatiblen bereits ein deutlich grösseres Wirrwarr an Hard- und Software vorhanden, welches einerseits zwar eine grössere Auswahl ergab und wodurch auch die Preise immer unter Druck waren, aber auch viel mehr Möglichkeiten für Probleme vorkamen.

Dann können die heutigen Systeme viel mehr als die alten.

Die Komplexität hat zugenommen. Weil die Hardware mehr Leistung bringt, ergeben sich mehr Möglichkeiten, diese zu nutzen. Wer möchte heutzutage noch mit 640x480 in 16 Farben und bei 60Hz (ok, bei TFTs sind wir ja wieder bei 60Hz…) arbeiten? Ist doch viel angenehmer, wenn man das grössere Display mit höherer Auflösung und höherer Farbtiefe nutzen kann. Und ist doch angenehm, wenn man die jeweilige ‚Arbeitsoberfläche‘ mit einem Hintergrundbild verschönern kann…

Und wo man sich in den Anfangszeiten der IBM-kompatiblen mit der 640kB-Grenze rumärgern musste oder mit der IRQ-Verwaltung, so ist das heutzutage doch deutlich angenehmer geworden. Windows verwaltet die IRQs in aller Regel sehr gut, so dass sich sogar mehrere Geräte den selben IRQ teilen können, was ja früher nicht oder nur schwer ging…

Der legacy-support frist an manchen Stellen sehr viel Leistung.

Stimmt. Apple hat das schon mehrere Male anders gelöst. Da war der Wechsel von der 68k- auf die PowerPC-Plattform, dann kam der Schritt vom alten OS zu OS X mit UNIX-artigem Unterbau. Und der Wechsel von der PowerPC- auf die Intel-Plattform. Da wurde und wird zwangsläufig der Legacy-Support in Grenzen gehalten.

Ob aber bei der x86-Plattform ein solch einschneidender Schritt wirklich machbar wäre?

CU
Peter

#4

Hallo Fragewurm,

(Der Legacy support ist auch der Grund weshalb wir immernoch
x86’er benutzen. Der x86 war eigentlich als
Festplattencontroller für Grossrechner ausgelegt und sollte
nie mehr machen als Daten zwischen Platten und RAM hin und her
schaufeln. Um Performance ging es nicht und das Ding im
Nachhinein auf Performance trimmen war extrem aufwendig. Man
hätte sich viele Man-jahre Arbeit sparen können wenn zu
Pentium-I Zeiten ein von Grund auf neues System eingeführt
worden wäre.)

Wie kommst du auf dieses schmale Brett ?

Ein paar Belege für deine Aussage fände ich ganz nett.

MfG Peter(TOO)

#5

Hallo,

also die reine Benutzeroberfläche eines Amiga war alles andere als schön.

Vielleicht waren wir heute nicht so verwöhnt ? Vor allem bei der Grafik ?

Wenn ich Turrican ansehe, dann finde ich das noch heute optisch schön. Wenn ich dagegen Battle Isle 1 und 2 spiele, dann ist das grafisch einfach „gähn“.

Soll es also die tollste Hardware sein, damit optisch alles super aussieht, dann ist das Ende der Fahnenstange noch längst nicht erreicht. Das ist nach meiner Meinung erst dann der Fall, wenn man optisch nicht mehr sagen kann, ob man einen Film mit echten Schauspielern oder einen computer-erzeugten sieht.

Gruss

Andreas

#6

Moien

Wie kommst du auf dieses schmale Brett ?

Ein paar Belege für deine Aussage fände ich ganz nett.

Mit dem Pentium I (und beim II’er noch viel stärker) wurde der eigentliche Kern vom äusseren stark abgetrennt. An sich emulieren die CPUs nur noch den x86, sie implementieren eigentlich einen reinen RISC-Kern. Da hätte man sich die Emulierung und Übersetzung in µOps gleich ganz sparen können.

OK, die µOps bringen auch Vorteile was out-of-order execution und ähnliche Spässe angeht. Aber sowas in Hardware zur Laufzeit machen ist wesentlich aufwendiger als das gleiche Spiel (zeitunkritisch und mit mehr Informationen was den Code davor und dahinter angeht) vom Compiler vorher machen zu lassen.

Alte Software hätte selbstverständlich gelitten. Aber Transmeta hat wenige Jahre später gezeigt dass es möglich ist x86’er Code zur Laufzeit in Software schnell in anderen Code zu übersetzen. Transmeta ist keine grosse Firma (damals nicht und heute schonmal gar nicht mehr) und hat das mit relativ wenig Aufwand, Geld und Zeit hinbekommen. Was hätte da Intel mit seinen µOp Übersetzleuten erst zustande gebracht.

Für mich persönlich wärs logischer gewesen den internen RISC-Kern von aussen zugänglich zu machen, die µOp Übersetzung in Software ins BIOS zu packen. Wer an x86 hängt hätte übersetzen lassen können, alle anderen hätten direkt den Kern angesprochen und heute würde niemand mehr x86 Code nutzen.

cu

#7

Moien

Ob aber bei der x86-Plattform ein solch einschneidender
Schritt wirklich machbar wäre?

Denk mal zurück an Transmeta und stell dir vor die hätten … 3x mehr Startkaptial gehabt. Es gäb heute 2 Arten von Software: die alten x86 Programme die erstmal (mit Geschwindigkeitsverlust) übersetzt werden müssen und die neuen, schnelleren die direkt mit dem Kern reden.

Stattdesen wird heute alles in x86 geschrieben und alles von der CPU in Hardware übersetzt.

cu

#8

Hallo,

Für mich persönlich wärs logischer gewesen den internen
RISC-Kern von aussen zugänglich zu machen, die µOp Übersetzung
in Software ins BIOS zu packen. Wer an x86 hängt hätte
übersetzen lassen können, alle anderen hätten direkt den Kern
angesprochen und heute würde niemand mehr x86 Code nutzen.

Das ist eine Intel-Krankheit !!

Genau genommen, steckt in einem heutigen Pentium immer noch ein Teil des 4004 !

Hier ein Auszug aus dem 1979-Datenbuch von Intel über den 8086:
_The Intel 8086, a new microcomputer, extends teh midrange 8080family into the 16-bit arena. the chip has attributes of both 8- and 16-bit processors. By executing the full set of 8080A/8085 8-bit instructions plus a powerful new set of 16-bit instructions, it enebles a system designer familiar with existing 8080 devices to boost performance by a factor of as much as 10 while using essentially the same 8080 software package ans development tools.

The goals of the 8086 architectural design were to extend existing 8080 features symmetrically across the board, and to add processing capabilities not to be found in the 8080 …_

Zum 8086 gab es auch ein Tool von Intel, welches 8080-Assembler-Sourcecode automatisch für den 8086 umgeschrieben hat. Damit wurden dann viele Applikationen von CP/M auf CP/M-86 und PC/MS-DOS portiert. Übrigens ist das .COM-Format von PC/MS-DOS kompatibel mit CP/M.

So ähnlich wurde auch der 8080 als Nachfolger des 4040 gepriesen. Und der 4040 war ja nur eine leicht verbesserte Version des 4004, welcher ja der erste Prozessor war.
Dabei muss man noch beachten, dass die Architektur des 4004 für ein CRT-Terminal ausgelegt war …

MfG Peter(TOO)

#9

Hallo

Software: die alten x86 Programme die erstmal (mit
Geschwindigkeitsverlust) übersetzt werden müssen und die
neuen, schnelleren die direkt mit dem Kern reden.
Stattdesen wird heute alles in x86 geschrieben und alles von
der CPU in Hardware übersetzt.

untschuldige mal, so einfach und trivial ist es doch nun wirklich
nicht. Es gibt doch nicht umsonst Betriebssysteme extra für
32-bit und 64bit Prozessoren.

Und auch das in x86 geschrieben stimmt so schon lange nicht mehr.
Daß neue Prozessoren noch einen Anteil an Befehlen aus Gründen
der Abwärtskompatibilität haben, zwingt doch Programmierer nicht
diese zu nutzen. Vielmehr wird gerade bei recourcenintensiven
Projekten gerade darauf verzichtet, was dann eben genau den
Effekt hat, daß die Kunden nur mit der neuesten Hardware die
entsprechenden Programme zum laufen bringt.

Ansonsten würde ich wie Peter auch mal wissen wollen, wie du
auf diese Info zur Entw. des x86 als Festplattenkontroller
gekommen bist.

Gruß Uwi

#10

Hallo,

Dabei habe ich mich gefragt, wie es möglich war auf einem
Amiga oder Atari St eine schöne Benutzeroberfläche aufzubauen
und bei heutigen Systemen die geschätzte 100 mal
leistungsfähiger sind, gibt es mit „modernen“ Betriebssystemen
Geschwindigkeitsprobleme.

Die Ursachen sind vielfältig.

Zum einen läuft unter modernen OS auch eine schier unendliche
Vielzahl von Diensten und programmen parallel.
Wir haben uns schon sehr daran gewöht, daß immer alle quasi
gleichzeitig zur Verfügung steht.

Dann sind die Bildschirmauflösungen (Pixelzahl und Farben)
deutlich gestiegen (con z.B. 640x480 mit 16 bit auf z.B. heute
1600x1200 mit 32bit Color und mehr). Das ist aber zum großen
Teil auch ein Problem der GraKa-Entwicklung.

Der wichtigste Grund liegt aber natürlich in der Art der
Programmierung.
Während früher eher mit direkten Zugriff auf die Hardware unter
Nutzung laufzeitoptimierter Compiler oder tatsächlich sogar auf
Basis vom Assembler programmiert wurde, ist es heute so,
daß fast nur Softwareschnittstellen des OS benutzt werden.

Statt einzelne Befehle zu programmieren wird auf komplexe
Unterprogramme (Objekte, Dienste, Treiber) zurückgegriffen.

Beispiel sind die sogenannten Visual-Sprachen wie C++, Delphi
und VisualBasic, die als sogenannte Objektorientierte Sprachen
ganz anders an die Programmierung herangehen.

Eine These von mir ist dass durch das Schreiben der Software
in Programmiersprachen und das anschließende Kompilieren die
Programme sich immer weiter aufblähen und dadurch langsamer
werden.

Nein, das war früher auch schon so.
Aber während früher jedes Detail mühselig programmiert werden
mußte, werden heute oft nur grafische Objekte per drag and Drop
auf den Desktop geholt. Das dahinter tauende Zeilen Quelltext
stehen, muß man gar nicht wissen.

Man zieht z.B. einfach ein Objekt „Botton“ auf seinen Desktop
in ein Programmfenster und dahinter steht eine große Zahl
von Funktionen und Eigenschaften fix und fertig zur Verfügung
wie z.B. die grafische Anzeige mit Rändern,Schatten, Farben,
und Funktionen (Bottom passiv,aktiv, selektiert, gedrücht usw.)
Bedienung mit der Mause, Hotkeys, beschriftung, Hilfefunktion,
Taborder usw. ist alles komplett fertig schon vorprogrammiert.

Hingegen war man bei den älteren leistungsschwächeren
Rechnern gezwungen in Maschinensprache zu schreiben, das ergab
dann einen straffen Programmcode.

Auch früher gab’s schon Hochsprachen, wie z.B. Pascal, Cobol,
Fortran. Nur Objektorientierte Programmierung gab’s noch nicht.
Jeder Programmierer hat sich nach und nach seine eigenen
Programmbibliotheken zusammengestellt.
Grafische Obeflächen haben sich auch erst nach und nach entwickelt.

Gruß Uwi

#11

Hallo,

meiner Meinung nach sind vor allem die gesteigerten Ansprueche und die riesigen Datenmengen Schuld daran.

Heutzutage muss ein PC nicht mehr eine Aufgabe bewaeltigen, sondern 100.

Ein und derselbe PC muss heute Texte schreiben, Videos schneiden, Bilder Scannen, CDs brennen, Spiele spielen, Musik mischen, Internet surfen und noch vieles mehr koennen.

Und das Ganze auch noch mit unvorstellbaren Datenmengen. Hatte man frueher einige 100 MB an Daten (wenn ueberhaupt) sind es heute oft das 1000fache!!!

Und huebsch aussehen muss das dann auch noch. Wenn ich schon „Aero“ hoere krieg ich Schreikraempfe!

Ich habe immer noch Rechner mit 500 Mhz in Betrieb. Die haben eine Aufgabe und die erfuellen sie auch. Fertig =:wink:

Ciao! Bjoern