Irgendwie, schreiben die blauen Experten, verhalte es sich mit dem 64-Bit-Computing wie mit dem Weihnachtsmann: Jeder redet über ihn, keiner aber hat ihn jemals bei der Arbeit gesehen. Das Problem mit der neuen Architektur sei, daß sie in den kommenden Jahren zwar wohl einige Bedeutung erlangen wird. Voraussetzung hierfür sei aber, daß auch 64-Bit-Betriebssysteme und -Anwendungen geschrieben werden. Die Hardware, also die Prozessoren allein, seien maximal die halbe Miete. Nicht unerheblich sei zudem, daß der Preis für Speicher-Chips seit geraumer Zeit zwar falle. Um die Möglichkeiten eines bei 64-Bit-Architekturen praktisch unbegrenzt adressierbaren Speichers aber sinnvoll nutzen zu können, müsse dieser schon deutlich über 4 GB groß sein. Spätestens dann würden die Kosten zum Ausschlußkriterium.
Grundsätzlich, sagen die IBM-Fachleute, gebe es heutzutage nur recht wenige Probleme in DV-Abteilungen, die sich mit 32-Bit- Rechnern nicht zufriedenstellend lösen ließen. Allein aus diesem Grund gibt es bis zum heutigen Tag auch nur sehr wenige 64-Bit- Installationen. Unter anderem durch die Verfügbarkeit von Software, die auf 64-Bit-Architekturen zugeschnitten ist, werde sich hier in Zukunft allerdings einiges ändern.
Grundsätzlich gilt: Computer verarbeiten Daten in definierten Portionen. Früher richteten sich dabei im Prinzip alle Komponenten eines Rechnersystems gleichermaßen an der sogenannten Wortlänge aus. Sie stellte das Wesensmerkmal der jeweiligen Computer dar, weswegen Maschinen als 8-, 16- oder 32-Bit-Systeme bezeichnet wurden. Diesen Rechnertypen gemein war, daß höhere Bit-Auslegung gleichbedeutend war mit besserer Rechenleistung.
Beispielhaft läßt sich das an der Prozessor-Chronologie von Intel aufzeigen: Der 4004, der Vorgänger aller modernen CPUs, war in 4- Bit-Technologie ausgelegt. Ihm folgten die 8-Bit-Variante 8008, der 16-Bit-Chip 8086 und schließlich Intels erster 32-Bit- Prozessor, der 80386. Einmal vorausgesetzt, daß die Software die Fähigkeiten der jeweiligen Architektur auch entsprechend unterstützte, konnten die Prozessorgenerationen immer größere Anwendungen und Datenstrukturen verarbeiten.
Die meiste Software war für 8- oder auch 16-Bit-Architekturen zu groß, was unweigerlich zu sogenannten System-Overheads führte, also einer Belastung von Rechenressourcen. Mit der Evolution der Prozessorarchitekturen erübrigte sich dieses Problem. Heutzutage, so die IBM-Experten, gibt es kaum noch Schwierigkeiten, die sich nicht durch eine 32-Bit-Architektur erledigen ließen. Aus diesem Grund sind auch die Leistungssteigerungen, die Anwender bei Architekturen jenseits der 32-Bit-Marke erwarten können, nicht so klar erkennbar.
Zudem lassen sich die Leistungscharakteristika heutiger Rechner nicht mehr im Sinne eines Gesamtsystems definieren. Vielmehr sind die Subkomponenten von Computern heutzutage unterschiedlich ausgelegt: So kann ein Rechner eine 32-Bit-Integer- aber eine 64- Bit-Fließkommaeinheit besitzen. Der virtuelle Adressierraum könnte 52 Bit groß sein, der Speicher-Bus hingegen 256 Bit breit. Als was würde man, wollte man ein System über seine Leistung definieren, solch einen Rechner bezeichnen? Als 32-Bit- oder als 64-Bit- Maschine?
Das wesentliche Unterscheidungsmerkmal einer 64- und einer 32-Bit- Maschine ist, daß erstere größere Integer-Datenvolumen verarbeitet. Allerdings gibt es heute - mit Ausnahme etwa von Lösungen für den Kryptographie-, Bildverarbeitungs- und auch Spielebereich - keine Anwendungen, die sich diese Eigenschaft zunutze machen können.
Allerdings müssen Daten auch adressiert werden. Diese Aufgabe wird ebenfalls durch Integer-Einheiten erledigt: Je größer diese aber sind, desto größer ist der adressierbare Raum. In dem Vermögen, große Datenblöcke zu verarbeiten, dürfte denn auch der wesentlichste Vorteil von 64-Bit-Maschinen liegen.
Schnellstmöglicher Zugriff auf alle Daten
Genau hierin liegen die Zukunftschancen von 64-Bit-Architekturen begründet: Heutige Applikationen greifen auf immer größere Datensatzstrukturen zurück. Moderne Anwendungen etwa für Data- Mining-Aufgaben leben vom schnellstmöglichen Zugriff auf alle verfügbaren Daten. Neue Applikationen etwa für die Bild- und Videoverarbeitung oder die Stimmerkennung brauchen und produzieren riesige Datenmengen. Um sie schnell zu verarbeiten, braucht es sicherlich Hardwarekonzepte wie die 64-Bit-Architektur.
Ein Beispiel zur Verdeutlichung. Mit einer 8-Bit-Architektur lassen sich 256, mit einem 16-Bit-System schon 65536 Adressen ansprechen. Heutzutage übliche 32-Bit-Rechner adressieren vier Milliarden Adressen. Eine 64-Bit-Architektur schließlich spricht 18000000000000000000 Adressen an. Umgerechnet auf adressierbare Bytes bedeutet dies 64 KB bei einem 16-Bit-, 4 GB bei einem 32- Bit- und über 18000000 TB bei einem 64-Bit-System.
In der Theorie liest sich dies sehr beeindruckend, scheinen sich dahinter doch erhebliche Vorteile zu verbergen. In der Praxis aber gibt es bereits standardisierte Methoden, um Daten beziehungsweise Dateien in kleinere Teile aufzusplitten und so auch große Datenstrukturen zu handhaben - ohne 64-Bit-Maschine.
Liegen Daten komplett im Arbeitsspeicher eines Rechners, kommt dem effizienten Datenzugriff eine hohe Bedeutung zu. Große Datenblöcke in Speichern schnell zu verarbeiten ist die wesentliche Eigenschaft von 64-Bit-Systemen, die übrigens auch das zugrundeliegende Betriebssystem verarbeiten können muß. Anzumerken ist an dieser Stelle, daß 32-Bit-Maschinen auf eine maximale Speichergröße von 4 GB beschränkt sind, 64-Bit-Maschinen unterstützen wesentlich größere Speicher.
Von 64-Bit-Architekturen profitieren insbesondere Datenbanksysteme. Dies gilt vor allem dann, wenn sie für Entscheidungsfindungs- oder Data-Mining-Aufgaben eingesetzt werden. Hier finden nämlich nur Lesezugriffe statt. Ganz anders sieht es etwa bei Transaktionsjobs aus: Hier müssen Daten auf den neuesten Stand, also auch in Massenspeicher wie Platten geschrieben werden, damit die Informationen immer konsistent bleiben. Dies erfordert I/O-Zugriffe und erzeugt die bekannte Flaschenhalsproblematik.
Nach elf Jahren noch nicht auf dem Stand der Dinge
64-Bit-Architekturen sind dabei nur eine Möglichkeit, um einen schnellen Zugriff auf große Datenmengen zu gewährleisten. Bei massiv-parallelen Rechnern etwa nutzt man mehrere voneinander unabhängige, aber parallel arbeitende Speicher.
Es gibt ein weiteres Problem bei der Diskussion um 64-Bit- Architekturen - die Software. Auch hier sei auf das Beispiel der PC-Intel-Welt verwiesen. Der in 32-Bit-Technologie ausgelegte 80386-Prozessor kam 1985 auf den Markt. Noch heute aber, elf Jahre nach der Markteinführung der Intel-CPU, mangelt es vielen PC- Applikationen an der notwendigen 32-Bit-Unterstützung. Generell gilt: Um die Stärken einer 64-Bit-Hardware auszunutzen, braucht es sowohl ein 64-Bit-Betriebssystem als auch 64-Bit-Middleware und - Applikationen.
Software-Entwicklung ist die Herausforderung
An 64-Bit-Hardware wird es in naher Zukunft nicht mangeln. Praktisch alle RISC-Anbieter werden mit entsprechenden CPUs aufwarten. Eine größere Herausforderung ist es da schon, ein 64- Bit-Betriebssystem zu entwikkeln. Dies gilt besonders, wenn dieses für ein sogenanntes offenes System gestrickt werden muß, bei dem Portabilitätsaspekte zwischen verschiedenen Implementierungen entscheidend sind.
Datenbanken und andere Middleware spielen bei 64-Bit-Konzepten insofern eine wichtige Rolle, als sie die Software-Applikationen im Prinzip von den Veränderungen, die bei 64-Bit-Strukturen nötig sind, abschirmen. Das heißt konkret, daß sich Anwendungen im besten Fall völlig unverändert nutzen lassen. Um allerdings die neue Hardwarestruktur optimal zu unterstützen, müssen Anwendungen auf sie abgestimmt werden. Ganz gewöhnlicher C-Code beispielsweise muß relativ aufwendig umgestrickt werden, um in 64-Bit-Umgebungen zu laufen. Entsprechende Umstellungsanstrengungen lassen Applikationsentwickler aber noch vermissen.
Angeklickt
64 Bit ist zwar ein In-Wort, aber deshalb noch nicht die Lösung aller Probleme. Theoretisch läßt sich mit einer solchermaßen ausgelegten Architektur ein praktisch unbegrenzter Speicherbereich adressieren. Es gibt aber bereits Methoden, Daten in kleinere Teile aufzusplitten und so auch große Datenstrukturen zu handhaben. Für die Akzeptanz von 64-Bit-Architekturen ist ferner wichtig, wann Middleware- und Applikations-Software verfügbar sein wird.