Wird es auf C# bald Integer 128 geben?

7 Antworten

Eher unwahrscheinlich. Es gibt relativ wenige Anwendungen, für die solche Wortbreiten als Standardtyp sinnvoll wäre, und dort, wo man sie benötigt, nimmt man gleich entsprechende Bibliotheken, die auch Wortbreiten mit sehr viel größerer Wortbreite unterstützen.

Es ist generell relativ einfach größere Wortbreiten mit kleineren zu berechnen.

Daß 64 Bit Primitivtypen eingeführt wurden, auf x86, war dem immer größeren Bedarf an Wortbreiten >32-Bit geschuldet und ging dann Hand in Hand mit der Erweiterung der Architektur (64-Bit Befehlssatz). Dieser kam 2003 (auf anderen Architekturen auch durchaus viel früher).

2^32 Bytes entsprechend 4 GiBiBytes, wenn Du mehr Speicher adressieren möchtest, macht es Dir ein 64-Bit Wert einfacher, ebenso bei Datenträgern und Dateigrößen.

Der Bedarf würde dann vorliegen, wenn Größen jenseits der 16 ExBiByte normal werden.

Im Übrigen sidn die SSE-Register 128-Bit, es bräuchte also nur geringfügige Anpassungen.

Das hat weniger mit C# (oder mit Programmiersprachen) zu tun als vielmehr mit der gerade dominanten Rechnerarchitektur:

So wie man 1975 nur 8-Bit-Rechner hatte, ab 1980 dann 16-Bit-Rechner, um 1990 dann schon 32-Bit-Rechner und seit etwa 2005 nun 64-Bit-Rechner, wird man (spätestens 2030) dann wohl 128-Bit-Rechner haben.

Wenn das so weit ist, wird — keineswegs nur in C#, sondern dann in allen Programmiersprachen — int = int128 sein (weil dann eben 128 die Bitbreite sein wird, mit der aritmetische Operation in Maschinensprache am einfachsten zu formulieren sein werden).

Kommt das wirklich auf die Architektur an? Weil ich mein damals haben sie mit 8 bit Computern sicher auch größere Zahlen als 255 verarbeitet. Sind eben mehr Zyklen oder?

0
@BlvckBytes

Natürlich kann man auch auf einem 8-Bit-Rechner größere Zahlen als 255 verarbeiten - man braucht dann aber statt nur eines Befehls für z.B. eine Multiplikation schon ein kleines Hilfsprogramm, welches weit mehr als nur einen Befehl an die CPU abzusetzen hat.

Ich selbst habe schon 1978 in Pascal ein Programm geschrieben, welches Gleitkommazahlen mit mehreren Hundert Dezimalstellen implementiert hat. Auf Lochkarten gestanzt ergab das einen Stapel von Lochkarten, der etwa 2 cm hoch war (1 Lochkarte = 1 Zeile Pascal-Code).

0
@grtgrt

Respekt! :). Da kann ich 17 jähriger, Hochsprachenverwöhnter Teenager garnicht mitreden :D. Ich persöhnlich finde die Computer von früher viel interessanter, weil man da richtig nah an der Hardware war und es bei weitem nicht so komplexe Kisten wie heute gab...

Den int128 könnte man ja auch jetzt schon implementieren, denke ich. Der wäre dann eben um ein vielfaches Langsamer, als der mit der Breite der aktuellen Architektur...

Interessantes Thema auf jeden Fall ^^

0

... sondern dann in allen Programmiersprachen — int = int128 sein ...

Bereits jetzt ist int in 64-Bit-C++ eben nicht int64 sondern int32. Das Chaos, was bei der Umstellung von 16 auf 32 Bit geherrscht hat wollte man wohl nicht noch einmal.

0
@Mikkey

Das Schöne an einer Programmiersprache ist ja, dass sie jeden Datentyp zu implementieren in der Lage ist. Sie kann also int64 ebenso wie int32 haben. Aber natürlich wird auf einer 64-Bit-CPU der Datentyp int64 effizienter arbeiten.

Auch in C hatte man ja schon immer short, int und long (bzw. float und double) nebeneinander zur Verfügung.

0

19-stellige Ganzzahlen reichen Dir also nicht, weswegen gerne permanent 38-stellige hättest, ohne den Typ ändern zu müssen?

Eine mögliche Erhöhung hat nichts mit der Programmiersprache zu tun, sondern mit der Speicherbreite, die aktuell 64 Bits beträgt. Mitte der 80er begann das Computern mit 8 Bits, was auch der Grund ist, das heute noch ein Byte acht Bits hat.

Ja warum mir 19-stellige Zahlen nicht ausreicht ist es wegen Zufallsgenerator.

0

Was möchtest Du wissen?