2013-09-11 11 views
9

Jetzt gibt es ein iPhone mit 64-Bit-Architektur. long wird 64 Bit (während int bleibt 32-Bit), und überall wo NSInteger verwendet wurde, ist jetzt ein long und so 64-Bit nicht 32. Und twitter hat ziemlich viele Leute sagen: "Ich bin froh, dass ich NSInteger überall verwendet habe nicht int ".Soll NSInteger wirklich überall verwendet werden?

Wenn Sie einen Wert speichern müssen, der 32 Bits nicht überschreitet (zum Beispiel in einer Schleife, die nur 25-mal eine Schleife ausführt), sollte eine lange verwendet werden, weil die 32 (mindestens) oberen Bits gehen sei leer.

Wenn das Programm mit 32-Bit-Ganzzahlen gearbeitet hat, welchen Nutzen bietet dann die Verwendung von 64-Bit für Ganzzahlen, wenn es mehr Speicher verbraucht?

Es gibt auch Situationen, in denen die Verwendung einer 64-Bit-Ganzzahl ein anderes Ergebnis ergibt als die Verwendung einer 32-Bit-Ganzzahl. Wenn Sie NSInteger verwenden, funktioniert etwas auf einem iPhone 5S, aber nicht auf einem älteren Gerät, während bei Verwendung von int oder long das Ergebnis auf jedem Gerät gleich ist.

Antwort

-1

Der interne Speicher für NSInteger kann einer von vielen verschiedenen Trägertypen sein, weshalb Sie ihn überall verwenden können und sich nicht darum kümmern müssen, was den Kern des Ganzen darstellt.

1

Wenn Sie einen Wert speichern müssen, der 32 Bit nicht überschreitet ... warum sollte ein Long verwendet werden?

Wenn Sie wirklich diese Garantie geben können, gibt es absolut keinen Grund, einen 64-Bit-Typ über einen 32-Bit-Typ zu bewerten. Für einfache Operationen wie gebundene Schleifen, Zähler und allgemeine Arithmetik genügen 32-Bit-Ganzzahlen. Aber für komplexere Operationen, insbesondere solche, die für Hochleistungsanwendungen erforderlich sind - beispielsweise solche, die Audio- oder Bildverarbeitung durchführen - ist die Zunahme der Datenmenge, die der Prozessor in 64-Bit-Modi handhaben kann, signifikant.

Wenn das Programm an 32-Bit-Ganzzahlen gearbeitet hat, welchen Nutzen bietet dann die Verwendung von 64-Bit für Integer, wenn es mehr Speicher verbraucht?

Sie machen die Verwendung von mehr Speicher scheint wie eine schlechte Sache. Durch die Verdopplung der Größe einiger Datentypen können sie an mehr Speicherorte adressiert werden, und je mehr Speicher adressiert werden kann, desto weniger Zeit benötigt das Betriebssystem zum Laden von Code. Darüber hinaus entspricht das Doppelte der Menge an Spuren für Daten in einem Prozessorbus einer Größenordnung von mehr Werten, die in einem einzigen Durchgang verarbeitet werden können, und die Zunahme der Registergröße bedeutet, dass eine Größenordnung von mehr Daten in der Umgebung gehalten werden kann ein Register. Dies entspricht, vereinfacht gesagt, einer fast automatischen Verdopplung der Geschwindigkeit der meisten Anwendungen.

Auch gibt es Situationen, in denen die Verwendung einer 64-Bit-Ganzzahl ein anderes Ergebnis ergibt als die Verwendung einer 32-Bit-Ganzzahl? ...

Ja, aber nicht in der Art, wie Sie denken würden. 32-Bit-Datentypen und -Operationen sowie 64-Bit-Operationen (die meisten in Software simuliert oder durch spezielle Hardware oder Opcodes in 32-Bit-Hosts) sind in Bezug auf ihre Größe "relativ stabil". Sie können nicht annähernd so viele Garantien für eine 64-Bit-Architektur geben, da verschiedene Compiler verschiedene Versionen von 64-Bit-Datentypen implementieren (siehe LP64, SILP64, and LLP64). Praktisch bedeutet dies, einen 64-Bit-Typ auf einen 32-Bit-Typ zu übertragen - etwa einen Zeiger auf einen Int -, was garantiert zu Informationsverlust führt, aber zwischen zwei Datentypen, die garantiert 64 Bit sind - ein Pointer und ein Long auf LP64 - ist akzeptabel. ARM wird normalerweise mit LP64 kompiliert (alle Eingänge sind 32-Bit, alle langen 64-Bit).Auch hier sollten die meisten Entwickler nicht von der Umstellung betroffen sein. Wenn Sie jedoch mit beliebig großen Zahlen arbeiten, die Sie in Ganzzahlen speichern möchten, wird die Genauigkeit zum Problem.

Aus diesem Grund empfehle ich NSUInteger und NSInteger in öffentlichen Schnittstellen und APIs, wo es keine inhärenten Grenzen Überprüfung oder Überlaufschutz gibt. Ein TableView fordert beispielsweise eine NSUInteger-Datenmenge an, nicht weil es sich um 32- und 64-Bit-Datenstrukturen sorgt, sondern weil es keine Garantien für die Architektur geben kann, auf der es kompiliert wird. Apples Versuch, architekturunabhängige Datentypen zu erstellen, ist ein bisschen Luxus, wenn man bedenkt, wie wenig Arbeit man dafür braucht, um den Code kompilieren zu lassen und in beiden Architekturen "einfach zu funktionieren".

+1

Ihre zweite Antwort "Sie machen mit mehr Speicher scheint eine schlechte Sache" ist genau die Art von Antwort, die ich gesucht habe. Leider, da ich keinen Informatik-Hintergrund habe, segelte es komplett über meinen Kopf. Gibt es ein Beispiel, das Sie zeigen können, wie das Speichern der Nummer "3" in einem 64-Bit-Speicherplatz tatsächlich die App beschleunigt? Ich stimme Jonathan zu, dass es wie eine riesige Raumverschwendung und furchtbar ineffizient erscheint. –

+0

Es ist alles die gleiche 'MOV' Anweisung. Es sind nicht beliebig kleine Operationen, die die Beschleunigung verursachen, sondern die Menge an Daten, die entlang der Busse des Prozessors fließen kann. Es ist vergleichbar mit einem 4-spurigen Highway statt nur 2, dann versuchen, eine Monster-Truck-Rallye zu halten. Sie können mehr von den kleineren Daten (wie normale Autos) anpassen und diese großen Lastwagen hineinquetschen, ohne darauf zu achten, die Daten zu zerhacken und sie nacheinander ablaufen zu lassen. – CodaFi

+1

Ah gut, Analogien. Ich mag es. Also, mit Ihrer Analogie, ist nicht eine "lange" für eine kleine Zahl ein bisschen wie ein riesiger Bus mit nur einem verlassenen kleinen Kind in den Rücken fahren? Es nimmt den gleichen Platz ein wie ein gepackter Bus, aber zusätzlicher Platz wird verschwendet. (Auf den zweiten Gedanken, vielleicht verwirrt mich die Metapher.) Ich habe das Gefühl, dass ich nicht etwas wirklich Grundlegendes verstehe, aber es scheint, dass, selbst wenn es sich um den MOV-Befehl handelt, MOV ein Wert ist, der in einem 64 gespeichert ist -Bit Speicherplatz würde doppelt so lange dauern wie einer in einem 32-Bit-Speicherplatz? –

-1

Apple kümmert sich um die Abwärtskompatibilität, wenn Ihre App auf einer 32- oder 64-Bit-Engine ausgeführt wird und Ihre Variable im Hintergrund unter Verwendung des Makros __LP64__ in den richtigen Datentyp konvertiert.

+2

das ist der springende Punkt meiner Frage ... –

+0

NSInteger gibt Ihnen immer den "größten" möglichen Integer-Datentyp in Ihrem Betriebssystem zugänglich - vor und nach iOS7. Und dieses Makro kümmert sich nur um Ihre OS-Version. Sie sollten immer den "kleinsten" Datentyp verwenden, der für Ihr spezifisches Problem sinnvoll ist. Sie können sicher einen Boolean in einer 32-Bit-Ganzzahl speichern, in einem 64-Bit - vor und nach iOS7. – XcodeJunkie

Verwandte Themen