Also ein 64-Bit Instruction Set, wo die Pointer trotzdem nur 32 Bit breit sind.
Viele Leute denken ja dass 64 Bit automatisch besser sein muss weil es eben eine größere Zahl als 32 ist. Die psychologische Macht der Zahlen eben.
Aber sie vergessen, dass ein 64-Bit Pointer auch doppelt so viel RAM braucht wie ein 32-Bit Pointer, und dasselbe gilt auch fĂĽr jedes size_t.
Innerhalb der CPU und ihrer Caches mag das egal sein, weil die sind schnell genug.
Aber sobald diese ganzen Pointers und size_t-s zwischen CPU und RAM ausgetauscht werden mĂĽssen, bedeutet dies dass auch die doppelte Speicherbandbreite dafĂĽr benutzt werden muss. Und die ist, anders als das was sich innerhalb der CPU abspielt, ein limitierender Faktor aller moderner Hardware.
Und ganz egal ist es auch innerhalb der Caches nicht, da diese bekanntlich nur eine begrenzte Größe haben: Wenn sie doppelt so breite Pointer oder size_t-s cachen müssen, sind sie schneller voll und können daher weniger viel cachen. Daher gibt es dann rascher Cache-Misses, und teure RAM-Zugriffe werden eher nötig.
Besonders sinnlos ist ein 64-Bit-Speichermodell in solchen Fällen, wo man nur minimal mehr RAM hat als man mit 32 Bit pro Prozess adressieren kann.
Den ganzen Speicher nutzen kann man dabei trotzdem noch, da es in der Regel ja mehr als einen Prozess gibt, und die CPUs zudem meist Erweiterungen wie PAE unter x86 haben, so dass auch unter 32 Bit der gesamte RAM nutzbar bleibt - nur eben nicht in einem einzigen Prozess.
Aber letztendlich ist es ohnehin egal - sehen wir uns einfach die Benchmarks an.
Dann wird man ja sehen, ob das durch den größerem RAM-Verbrauch erforderliche Swappen nicht die Vorteile der 64-Bit-Architektur zunichte macht - zumindest bei Anwendungen welche die 64 Bit nicht nur zum Spaß benutzen, sondern auch tatsächlich viel RAM benötigen.
Und was die verdoppelte Registerzahl bei ARM64 angeht: Das sollte man nicht ĂĽberbewerten.
NatĂĽrlich sind mehr Register nie ein Fehler. Aber im Gegensatz zu x86 hat schon ARM32 ausreichend Register gehabt, so dass dort kein solcher Vorteil der 64-Bit-Version besteht wie es bei x86 mit seiner kĂĽmmerlichen Hand voll Registern unter 32 Bit ist.
Und was die oft zitierte AES-Erweiterung angeht: Ist es wirklich wünschenswert, in Situationen wo es auf Sicherheit angeht alle vertraulichen Schlüssel durch eine Hand voll Hardware-Register zu schaufeln, wo jeder der ein Backdoor ins CPU-Design einbaut auf die Idee kommen könnte sie dort abzufangen oder in einen nicht-dokumentierten Cache zu schreiben den ein Angriffs-Programm dann über einen Seitenkanal-Zugriff auslesen kann?
Zumal die Beschleunigung durch diese Instruktionen ohnehin nur eine eher bescheidene ist - ca. Faktor 2 bei INTEL, las ich einmal. Also kein Faktor 10 oder 100 wie man vielleicht glauben sollte da dies doch "in Hardware" geschieht.
Oder anders herum gesagt: Wenn man diese Instruktionen nicht verwendet, etwa wegen SIcherheitsbedenken dem CPU-Hersteller gegenüber, hält sich der Performance-Verlust in Grenzen und ist keinesfalls katastrophal.