Die Frage „Wozu überhaupt 64-Bit“ lässt sich am besten aus der geschichtlichen Retrospektive heraus erklären. Die alte 8-Bit-Welt ist nicht mehr sehr vielen von uns geläufig, dafür aber die 16-Bit-Welt aus den Zeiten von Windows 3.1 usw. Das Problem des 16-Bit-Adressraumes ist sehr schnell ausgemacht: Gerade mal 65 KByte Speicher standen z.B. einer DOS-Anwendung zur Verfügung! Mehr war – wenn überhaupt – nur auf Umwegen zu haben; wir erinnern uns an so was wie XMS, EMS etc.
Der Einzug von 32-Bit’ern würde uns schier unbegrenzte Adressräume eröffnen – dachten wir uns vor ca. 15 Jahren, als wir unseren 286’ern beim Abzählen von teuer angeschafften ein paar MB’s RAM zuschauten. Dass in nicht allzu ferner Zukunft eine gute Vertausendfachung dieser Kapazität stattfinden wird, war zum einen nicht unbedingt zu erwarten und zum anderen haben wir uns nicht so sehr Gedanken darüber gemacht, wie das 32-Bit-Windows den Adressraum von Schwindel erregenden 4 GB aufteilt (vgl. z.B. /3GB-Switch).
Bleiben wir noch einen Moment bei der Geschichte des Wachstums von Adressräumen. Eine der Fragen, die manchmal an dieser Stelle gestellt wird, ist die, ob man mit den 64 Bits nicht schon wieder zu kurz springt. Hier kann man wenigstens einmal ruhigen Gewissens eine Antwort geben, die man ganz sicher nicht schon ein paar Jahren wieder einsammeln kann: Die Millionen TB (Terabyte), die vom 64-Bit-Adressraum erfasst werden, werden nicht mehr zu unseren Lebenszeiten gesprengt. Denn immerhin bedeutet es die Kapazität der Erde, würde man pro nur ein paar Tonnen Erdmasse je ein Bit speichern!.
Die schier unbegrenzten Adressräume sind schön und gut, aber die Frage lautet abermals, wozu das ganze?Brauche ich denn wirklich so viel Speicher? Was bringt mir das als TransObjects®-Anwender ganz konkret?
Nun, hier ist die Antwort sicherlich nicht monokausal. Zunächst hat sich schon mal jeder, der die CPU-Belastung eines Servers angeschaut hat, gefragt, ob er ihm denn mit höherer Taktung resp. mit weiteren Prozessoren wirklich auf die Sprünge helfen kann, wo doch die bereits vorhandenen CPU’s offensichtlich z.B. über 90% der Rechenzeit damit zubringen, auf andere langsamere Komponenten zu warten. Eine solch langsame Komponente ist schnell ausgemacht: Disk-I/O. Würde man hier weitaus mehr von häufig benötigten Daten im RAM halten können – z.B. Active Directory, Postfächer, Datenbanken, Suchindizes – sähe die Sache ganz bestimmt anders aus. Gleiche Asymmetrie ist aber auch zwischen RAM und der CPU, dem CPU-Cache und den CPU-Registern feststellbar; letztere wiederum sind leistungsfähiger, wenn sie länger sind – etc. Das alles greift ineinander und ergibt per Saldo einen Vorteil für „64″.
Anders ausgedrückt heißt das, mit der 64-Bit-Technik können vor allem die Unternehmensserver weitaus effektiver beschleunigt bzw. von der Kapazität her erweitert werden, als mit noch so vielen und noch so „hochtourigen“ Prozessoren. Stark ausgelasteten TransObjects®-Servern kann dadurch weitaus mehr geholfen werden, als etwa mit den sündhaft teuren „Mehrzylindern“ (Mehrprozessor-Rechnern, auch „Multiprocessing“-Maschinen genannt), jedoch mit nur 32-Bit-Technik.
Hingegen erschließt sich einem die Sinnhaftigkeit einer 64-Bit-Workstation für einen TransObjects®-Anwender nicht sofort, schließlich haben wir hier keine Serveraufgaben zu bewältigen und die TransObjects®-Clients konsumieren noch lange keine GBytes an Speicher.
Nun, es trifft zwar zu, dass eine auf einem 64-Bit’er isoliert ausgeführte TransObjects®-Anwendung keine weltbewegenden Performancevorteile gegenüber einer hinlänglich dimensionierten 32-Bit-Umgebung aufweist, denn diese Vorteile rühren – wie bereits ausgeführt – lediglich von dem, was mit dem Prädikat „enhanced memory“ in Intel’s „EM64T“ bezeichnet wird und das ist bei einer schwach ausgelasteten Workstation weiß Gott nicht dramatisch. Kommt jedoch der Anwender auf die Idee, eine der modernen Streaming-Software parallel zu TransObjects® mit auszuführen, sieht es natürlich ganz anders aus. Und solch hungrige Applikationen sind bereits im Anrollen – dafür hat diejenige Branche, in der auch wir tätig sind, J entsprechend gesorgt.
Trotz dieser sich klar abzeichnenden Entwicklung lautet das häufigste Verkaufsargument in denjenigen Teilen der Softwarebranche, die das Neue nicht beherrschen, gegenüber der Zeit vor 15 Jahren nahezu unverändert: „64-Bit? (früher 32-Bit?) Das brauchen Sie nicht. Unsere Logistik- und/oder Verzollungsanwendung läuft bestens auf den jetzigen Systemen…“ usw. Ja, wortwörtlich genommen stimmt es sogar: So etwas brauchen Sie als TransObjects®-Anwender wirklich nicht.
Viele haben noch die Turbulenzen des Übergangs von 16- auf 32-Bit in den frühen 90’ern gut in Erinnerung. Nun steht unweigerlich etwas Ähnliches ins Haus und zwar mit den offensichtlich unaufhaltsam aufkommenden „64-Bit“-ern. Diese Entwicklung betrifft die Hardware, die Betriebssysteme und schlussendlich auch die Anwendungs-Software.
Obwohl die K&S Informatik und deren TransObjects® weite Teile der neuen 64-Bit-Welt längst erschlossen haben, z.B. durch die Inbetriebnahme von 64-Bit Itanium-Servern im TransObjects® Message Clearing Center, häufen sich die Fragen zu diesem Thema erst jetzt so richtig, wo viele Anwender eine Migration auf die neuen Plattformen ganz konkret für sich erwägen und sich z.B. mit der Frage Itanium oder EM64 konfrontiert sehen. Diese aber auch andere Fragen zu diesem Thema, was die neue Welt mit sich bringt, was zu beachten ist und was das für uns als TransObjects®-Anwender bedeutet, versuchen wir vorliegend zu klären