Ist es in Java effizienter, Byte oder Short anstelle von int und float anstelle von double zu verwenden?

Mir ist aufgefallen, dass ich immer int und double verwendet habe, egal wie klein oder groß die Zahl sein muss. Ist es in Java effizienter, byteoder shortanstelle von intund floatanstelle von zu verwenden double?

Nehmen wir also an, ich habe ein Programm mit vielen Ints und Doubles. Wäre es wert, meine Ints in Bytes oder Shorts zu ändern, wenn ich wüsste, dass die Nummer passen würde?

Ich weiß, dass Java keine vorzeichenlosen Typen hat, aber kann ich noch etwas tun, wenn ich wüsste, dass die Zahl nur positiv ist?

Mit effizient meine ich meistens die Verarbeitung. Ich würde annehmen, dass der Garbage Collector viel schneller wäre, wenn alle Variablen halb so groß wären und dass die Berechnungen wahrscheinlich auch etwas schneller wären. (Ich denke, da ich an Android arbeite, muss ich mir auch etwas Sorgen um RAM machen)

(Ich würde annehmen, dass der Garbage Collector nur Objekte und keine Grundelemente behandelt, aber dennoch alle Grundelemente in verlassenen Objekten löscht, oder?)

Ich habe es mit einer kleinen Android-App versucht, aber ich habe überhaupt keinen Unterschied bemerkt. (Obwohl ich nichts "wissenschaftlich" gemessen habe.)

Bin ich falsch in der Annahme, dass es schneller und effizienter sein sollte? Ich würde es hassen, alles in einem riesigen Programm zu ändern, um herauszufinden, dass ich meine Zeit verschwendet habe.

Wäre es von Anfang an wert, wenn ich ein neues Projekt starte? (Ich meine, ich denke, jedes kleine bisschen würde helfen, aber wenn ja, warum scheint es nicht so, als ob es jemand tut.)

Bin ich falsch in der Annahme, dass es schneller und effizienter sein sollte? Ich würde es hassen, alles in einem riesigen Programm zu ändern, um herauszufinden, dass ich meine Zeit verschwendet habe.

Kurze Antwort

Ja, du liegst falsch. In den meisten Fällen macht es wenig Platz.

Es lohnt sich nicht , dies zu optimieren ... es sei denn, Sie haben eindeutige Beweise dafür, dass eine Optimierung erforderlich ist. Und wenn Sie insbesondere die Speichernutzung von Objektfeldern optimieren müssen, müssen Sie wahrscheinlich andere (effektivere) Maßnahmen ergreifen.

Längere Antwort

Die Java Virtual Machine modelliert Stapel und Objektfelder mithilfe von Offsets, die (tatsächlich) ein Vielfaches einer primitiven 32-Bit-Zellengröße sind. Wenn Sie also eine lokale Variable oder ein Objektfeld als (sagen wir) a deklarieren byte, wird die Variable / das Feld genau wie eine in einer 32-Bit-Zelle gespeichert int.

Hiervon gibt es zwei Ausnahmen:

• longund doubleWerte erfordern 2 primitive 32-Bit-Zellen
• Arrays primitiver Typen werden in gepackter Form dargestellt, so dass (zum Beispiel) ein Array von Bytes 4 Bytes pro 32-Bit-Wort enthält.

Es könnte sich also lohnen, die Verwendung von longund double... und große Anordnungen von Grundelementen zu optimieren . Aber im Allgemeinen nein.

^{Theoretisch könnte eine JIT dies optimieren, aber in der Praxis habe ich noch nie von einer JIT gehört, die dies tut. Ein Hindernis besteht darin, dass die JIT normalerweise erst ausgeführt werden kann, nachdem Instanzen der zu kompilierenden Klasse erstellt wurden. Wenn die JIT das Speicherlayout optimieren würde, könnten Sie zwei (oder mehr) "Geschmacksrichtungen" von Objekten derselben Klasse haben ... und das würde große Schwierigkeiten bereiten.}

Wiederholung

Wenn man sich die Benchmark-Ergebnisse in der Antwort von @ meriton ansieht, scheint es, dass die Verwendung von shortund byteanstelle von inteine Leistungsstrafe für die Multiplikation verursacht. Wenn Sie die Operationen isoliert betrachten, ist die Strafe in der Tat erheblich. (Sie sollten sie nicht isoliert betrachten ... aber das ist ein anderes Thema.)

Ich denke, die Erklärung ist, dass JIT die Multiplikationen wahrscheinlich mit jeweils 32-Bit-Multiplikationsbefehlen durchführt. Aber in dem byteund shortFall, führt er zusätzliche Anweisungen , um das Zwischenprodukt 32 - Bit - Wert in einem zu überführen byteoder shortin jeder Schleifeniteration. (Theoretisch könnte diese Konvertierung einmal am Ende der Schleife durchgeführt werden ... aber ich bezweifle, dass der Optimierer dies herausfinden kann.)

Dies deutet jedoch auf ein weiteres Problem beim Umschalten auf shortund byteals Optimierung hin. Dies könnte die Leistung beeinträchtigen ... in einem Algorithmus, der arithmetisch und rechenintensiv ist.

Dies hängt von der Implementierung der JVM sowie der zugrunde liegenden Hardware ab. Die meiste moderne Hardware ruft keine einzelnen Bytes aus dem Speicher (oder sogar aus dem Cache der ersten Ebene) ab, dh die Verwendung der kleineren primitiven Typen reduziert im Allgemeinen den Speicherbandbreitenverbrauch nicht. Ebenso haben moderne CPUs eine Wortgröße von 64 Bit. Sie können Operationen mit weniger Bits ausführen, aber das funktioniert, indem die zusätzlichen Bits verworfen werden, was auch nicht schneller ist.

Der einzige Vorteil besteht darin, dass kleinere primitive Typen zu einem kompakteren Speicherlayout führen können, insbesondere bei Verwendung von Arrays. Dies spart Speicherplatz, wodurch die Referenzlokalität verbessert werden kann (wodurch die Anzahl der Cache-Fehler verringert wird) und der Aufwand für die Speicherbereinigung verringert wird.

Im Allgemeinen ist die Verwendung der kleineren primitiven Typen jedoch nicht schneller.

Um dies zu demonstrieren, sehen Sie sich den folgenden Benchmark an:

package tools.bench;

import java.math.BigDecimal;

public abstract class Benchmark {

    final String name;

    public Benchmark(String name) {
        this.name = name;
    }

    abstract int run(int iterations) throws Throwable;

    private BigDecimal time() {
        try {
            int nextI = 1;
            int i;
            long duration;
            do {
                i = nextI;
                long start = System.nanoTime();
                run(i);
                duration = System.nanoTime() - start;
                nextI = (i << 1) | 1; 
            } while (duration < 100000000 && nextI > 0);
            return new BigDecimal((duration) * 1000 / i).movePointLeft(3);
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }   

    @Override
    public String toString() {
        return name + "\t" + time() + " ns";
    }

    public static void main(String[] args) throws Exception {
        Benchmark[] benchmarks = {
            new Benchmark("int multiplication") {
                @Override int run(int iterations) throws Throwable {
                    int x = 1;
                    for (int i = 0; i < iterations; i++) {
                        x *= 3;
                    }
                    return x;
                }
            },
            new Benchmark("short multiplication") {                   
                @Override int run(int iterations) throws Throwable {
                    short x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x *= 3;
                    }
                    return x;
                }
            },
            new Benchmark("byte multiplication") {                   
                @Override int run(int iterations) throws Throwable {
                    byte x = 0;
                    for (int i = 0; i < iterations; i++) {
                        x *= 3;
                    }
                    return x;
                }
            },
            new Benchmark("int[] traversal") {                   
                @Override int run(int iterations) throws Throwable {
                    int[] x = new int[iterations];
                    for (int i = 0; i < iterations; i++) {
                        x[i] = i;
                    }
                    return x[x[0]];
                }
            },
            new Benchmark("short[] traversal") {                   
                @Override int run(int iterations) throws Throwable {
                    short[] x = new short[iterations];
                    for (int i = 0; i < iterations; i++) {
                        x[i] = (short) i;
                    }
                    return x[x[0]];
                }
            },
            new Benchmark("byte[] traversal") {                   
                @Override int run(int iterations) throws Throwable {
                    byte[] x = new byte[iterations];
                    for (int i = 0; i < iterations; i++) {
                        x[i] = (byte) i;
                    }
                    return x[x[0]];
                }
            },
        };
        for (Benchmark bm : benchmarks) {
            System.out.println(bm);
        }
    }
}

welches auf meinem etwas alten Notizbuch gedruckt wird (Leerzeichen hinzufügen, um Spalten anzupassen):

int       multiplication    1.530 ns
short     multiplication    2.105 ns
byte      multiplication    2.483 ns
int[]     traversal         5.347 ns
short[]   traversal         4.760 ns
byte[]    traversal         2.064 ns

Wie Sie sehen können, sind die Leistungsunterschiede recht gering. Die Optimierung von Algorithmen ist weitaus wichtiger als die Wahl des primitiven Typs.

Die Verwendung von byteanstelle von intkann die Leistung steigern, wenn Sie sie in großer Menge verwenden. Hier ist ein Experiment:

import java.lang.management.*;

public class SpeedTest {

/** Get CPU time in nanoseconds. */
public static long getCpuTime() {
    ThreadMXBean bean = ManagementFactory.getThreadMXBean();
    return bean.isCurrentThreadCpuTimeSupported() ? bean
            .getCurrentThreadCpuTime() : 0L;
}

public static void main(String[] args) {
    long durationTotal = 0;
    int numberOfTests=0;

    for (int j = 1; j < 51; j++) {
        long beforeTask = getCpuTime();
        // MEASURES THIS AREA------------------------------------------
        long x = 20000000;// 20 millions
        for (long i = 0; i < x; i++) {
                           TestClass s = new TestClass(); 

        }
        // MEASURES THIS AREA------------------------------------------
        long duration = getCpuTime() - beforeTask;
        System.out.println("TEST " + j + ": duration = " + duration + "ns = "
                + (int) duration / 1000000);
        durationTotal += duration;
        numberOfTests++;
    }
    double average = durationTotal/numberOfTests;
    System.out.println("-----------------------------------");
    System.out.println("Average Duration = " + average + " ns = "
            + (int)average / 1000000 +" ms (Approximately)");


}

}}

Diese Klasse testet die Geschwindigkeit beim Erstellen eines neuen TestClass. Jeder Test macht es 20 Millionen Mal und es gibt 50 Tests.

Hier ist die Testklasse:

 public class TestClass {
     int a1= 5;
     int a2= 5; 
     int a3= 5;
     int a4= 5; 
     int a5= 5;
     int a6= 5; 
     int a7= 5;
     int a8= 5; 
     int a9= 5;
     int a10= 5; 
     int a11= 5;
     int a12=5; 
     int a13= 5;
     int a14= 5; 
 }

Ich habe die SpeedTestKlasse geleitet und am Ende Folgendes bekommen:

 Average Duration = 8.9625E8 ns = 896 ms (Approximately)

Jetzt ändere ich die Ints in der TestClass in Bytes und führe sie erneut aus. Hier ist das Ergebnis:

 Average Duration = 6.94375E8 ns = 694 ms (Approximately)

Ich glaube, dieses Experiment zeigt, dass die Verwendung von Byte anstelle von int die Effizienz steigern kann, wenn Sie eine große Anzahl von Variablen instanziieren

Byte wird im Allgemeinen als 8 Bit betrachtet. kurz wird allgemein als 16 Bit angesehen.

In einer "reinen" Umgebung, die nicht Java ist, da die gesamte Implementierung von Bytes und Longs, Shorts und anderen lustigen Dingen im Allgemeinen vor Ihnen verborgen ist, nutzt Byte den Speicherplatz besser aus.

Ihr Computer ist jedoch wahrscheinlich nicht 8-Bit und wahrscheinlich nicht 16-Bit. Dies bedeutet, dass, um insbesondere 16 oder 8 Bits zu erhalten, auf "Tricks" zurückgegriffen werden muss, die Zeit verschwenden, um vorzutäuschen, dass es bei Bedarf auf diese Typen zugreifen kann.

Zu diesem Zeitpunkt hängt es davon ab, wie die Hardware implementiert ist. Wie ich jedoch gelernt habe, wird die beste Geschwindigkeit erreicht, wenn Dinge in Blöcken gespeichert werden, die für Ihre CPU bequem zu verwenden sind. Ein 64-Bit-Prozessor beschäftigt sich gerne mit 64-Bit-Elementen, und alles andere erfordert oft "technische Magie", um so zu tun, als würde er sich gerne mit ihnen befassen.

Einer der Gründe für die geringere Leistung von Short / Byte / Char ist der Mangel an direkter Unterstützung für diese Datentypen. Durch direkte Unterstützung bedeutet dies, dass in den JVM-Spezifikationen kein Befehlssatz für diese Datentypen erwähnt wird. Anweisungen wie Speichern, Laden, Hinzufügen usw. haben Versionen für den Datentyp int. Sie haben jedoch keine Versionen für short / byte / char. Betrachten Sie zB den folgenden Java-Code:

void spin() {
 int i;
 for (i = 0; i < 100; i++) {
 ; // Loop body is empty
 }
}

Gleiches wird wie unten in Maschinencode umgewandelt.

0 iconst_0 // Push int constant 0
1 istore_1 // Store into local variable 1 (i=0)
2 goto 8 // First time through don't increment
5 iinc 1 1 // Increment local variable 1 by 1 (i++)
8 iload_1 // Push local variable 1 (i)
9 bipush 100 // Push int constant 100
11 if_icmplt 5 // Compare and loop if less than (i < 100)
14 return // Return void when done

Erwägen Sie nun, int wie unten in short zu ändern.

void sspin() {
 short i;
 for (i = 0; i < 100; i++) {
 ; // Loop body is empty
 }
}

Der entsprechende Maschinencode ändert sich wie folgt:

0 iconst_0
1 istore_1
2 goto 10
5 iload_1 // The short is treated as though an int
6 iconst_1
7 iadd
8 i2s // Truncate int to short
9 istore_1
10 iload_1
11 bipush 100
13 if_icmplt 5
16 return

Wie Sie sehen können, wird zur Manipulation des kurzen Datentyps weiterhin die Anweisungsversion des Datentyps int verwendet und bei Bedarf explizit in den Datentyp int konvertiert. Aufgrund dessen wird die Leistung jetzt reduziert.

Als Grund für die Nichtunterstützung wird nun folgender Grund angeführt:

Die Java Virtual Machine bietet die direkteste Unterstützung für Daten vom Typ int. Dies ist teilweise im Vorgriff auf effiziente Implementierungen der Operandenstapel und lokalen Variablenarrays der Java Virtual Machine. Es wird auch durch die Häufigkeit von int-Daten in typischen Programmen motiviert. Andere integrale Typen haben weniger direkte Unterstützung. Es gibt beispielsweise keine Byte-, Zeichen- oder Kurzversionen zum Speichern, Laden oder Hinzufügen von Anweisungen.

Zitiert aus der hier vorhandenen JVM-Spezifikation (Seite 58).

Der Unterschied ist kaum spürbar! Es ist eher eine Frage des Designs, der Angemessenheit, der Einheitlichkeit, der Gewohnheit usw. Manchmal ist es nur eine Frage des Geschmacks. Wenn Sie sich nur darum kümmern, dass Ihr Programm in Betrieb genommen wird und das Ersetzen eines floatdurch ein Programm ersetzt, intwürde dies die Korrektheit nicht beeinträchtigen. Ich sehe keinen Vorteil darin, das eine oder andere zu wählen, es sei denn, Sie können nachweisen, dass die Verwendung eines der beiden Typen die Leistung verändert. Das Optimieren der Leistung basierend auf Typen, die sich in 2 oder 3 Bytes unterscheiden, ist wirklich das Letzte, was Sie beachten sollten. Donald Knuth hat einmal gesagt: "Vorzeitige Optimierung ist die Wurzel allen Übels" (nicht sicher, ob er es war, bearbeiten Sie, wenn Sie die Antwort haben).