In Java, è più efficiente usare byte o short invece di int e float invece di double?

Ho notato che ho sempre usato int e double, non importa quanto piccolo o grande debba essere il numero. Quindi, in Java, è più efficiente da usare byteo shortinvece di inte floatinvece di double?

Quindi supponi di avere un programma con molti int e doppi. Varrebbe la pena passare attraverso e cambiare i miei int in byte o corti se sapessi che il numero si adatterebbe?

So che java non ha tipi non firmati, ma c'è qualcosa in più che potrei fare se sapessi che il numero sarebbe solo positivo?

Per efficiente intendo principalmente elaborazione. Presumo che il garbage collector sarebbe molto più veloce se tutte le variabili fossero di dimensioni dimezzate e che anche i calcoli sarebbero probabilmente un po 'più veloci. (Immagino che dal momento che sto lavorando su Android devo preoccuparmi un po 'anche della ram)

(Presumo che il garbage collector si occupi solo di oggetti e non primitivo ma cancella comunque tutte le primitive negli oggetti abbandonati, giusto?)

L'ho provato con una piccola app per Android che ho ma non ho notato alcuna differenza. (Anche se non ho misurato "scientificamente" nulla.)

Sbaglio nel ritenere che dovrebbe essere più veloce ed efficiente? Non vorrei passare attraverso e cambiare tutto in un programma enorme per scoprire che ho perso il mio tempo.

Varrebbe la pena farlo dall'inizio quando inizio un nuovo progetto? (Voglio dire, penso che ogni piccola cosa aiuterebbe, ma poi di nuovo se è così, perché non sembra che qualcuno lo faccia.)

Sbaglio nel ritenere che dovrebbe essere più veloce ed efficiente? Non vorrei passare attraverso e cambiare tutto in un programma enorme per scoprire che ho perso il mio tempo.

Risposta breve

Sì, ti sbagli. Nella maggior parte dei casi, fa poca differenza in termini di spazio utilizzato.

Non vale la pena tentare di ottimizzarlo ... a meno che non si disponga di prove chiare che è necessaria l'ottimizzazione. E se è necessario ottimizzare l'utilizzo della memoria in particolare dei campi oggetto, sarà probabilmente necessario adottare altre misure (più efficaci).

Risposta più lunga

La Java Virtual Machine modella stack e campi oggetto utilizzando offset che sono (in effetti) multipli di una dimensione di cella primitiva a 32 bit. Quindi, quando dichiari una variabile locale o un campo oggetto come (diciamo) a byte, la variabile / campo verrà archiviata in una cella a 32 bit, proprio come un file int.

Ci sono due eccezioni a questo:

• longe i doublevalori richiedono 2 celle primitive a 32 bit
• array di tipi primitivi sono rappresentati in forma compressa, in modo che (per esempio) un array di byte contenga 4 byte per parola a 32 bit.

Quindi potrebbe valere la pena ottimizzare l'uso di longe double... e grandi array di primitive. Ma in generale no.

^{In teoria, un JIT potrebbe essere in grado di ottimizzarlo, ma in pratica non ho mai sentito parlare di un JIT che lo fa. Un ostacolo è che il JIT in genere non può essere eseguito fino a quando non sono state create istanze della classe da compilare. Se il JIT ottimizzasse il layout della memoria, si potrebbero avere due (o più) "versioni" di oggetto della stessa classe ... e ciò presenterebbe enormi difficoltà.}

Rivisitazione

Guardando i risultati del benchmark nella risposta di @ meriton, sembra che l'utilizzo di shorte byteinvece di intincorrere in una penalizzazione delle prestazioni per la moltiplicazione. Infatti, se si considerano le operazioni isolatamente, la sanzione è significativa. (Non dovresti considerarli isolatamente ... ma questo è un altro argomento.)

Penso che la spiegazione sia che JIT sta probabilmente facendo le moltiplicazioni usando istruzioni di moltiplicazione a 32 bit in ogni caso. Ma nel caso bytee short, esegue istruzioni aggiuntive per convertire il valore intermedio a 32 bit in a byteo shortin ciascuna iterazione del ciclo. (In teoria, quella conversione potrebbe essere eseguita una volta alla fine del ciclo ... ma dubito che l'ottimizzatore sarebbe in grado di capirlo.)

Ad ogni modo, questo indica un altro problema con il passaggio a shorte bytecome ottimizzazione. Potrebbe peggiorare le prestazioni ... in un algoritmo aritmetico e ad alta intensità di calcolo.

Dipende dall'implementazione della JVM e dall'hardware sottostante. La maggior parte dell'hardware moderno non preleverà singoli byte dalla memoria (o anche dalla cache di primo livello), cioè l'uso di tipi primitivi più piccoli generalmente non riduce il consumo di larghezza di banda della memoria. Allo stesso modo, le moderne CPU hanno una dimensione della parola di 64 bit. Possono eseguire operazioni con meno bit, ma questo funziona scartando i bit extra, che non è neanche più veloce.

L'unico vantaggio è che tipi primitivi più piccoli possono dare come risultato un layout di memoria più compatto, in particolare quando si utilizzano array. Ciò consente di risparmiare memoria, che può migliorare la località di riferimento (riducendo così il numero di cache miss) e ridurre il sovraccarico di raccolta dei rifiuti.

In generale, tuttavia, l'utilizzo dei tipi primitivi più piccoli non è più veloce.

Per dimostrarlo, osserva il seguente benchmark:

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);
        }
    }
}

che viene stampato sul mio taccuino un po 'vecchio (aggiungendo spazi per regolare le colonne):

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

Come puoi vedere, le differenze di prestazioni sono piuttosto minori. L'ottimizzazione degli algoritmi è molto più importante della scelta del tipo primitivo.

L'utilizzo al byteposto di intpuò aumentare le prestazioni se vengono utilizzati in quantità enormi. Ecco un esperimento:

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)");


}

}

Questa classe verifica la velocità di creazione di un nuovo file TestClass. Ogni test lo fa 20 milioni di volte e ci sono 50 test.

Ecco il TestClass:

 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; 
 }

Ho condotto la SpeedTestlezione e alla fine ho ottenuto questo:

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

Ora sto cambiando gli int in byte nella TestClass e lo sto eseguendo di nuovo. Ecco il risultato:

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

Credo che questo esperimento dimostri che se installi un'enorme quantità di variabili, l'utilizzo di byte invece di int può aumentare l'efficienza

byte è generalmente considerato essere 8 bit. short è generalmente considerato di 16 bit.

In un ambiente "puro", che non è java poiché tutte le implementazioni di byte e long e short e altre cose divertenti sono generalmente nascoste, byte fa un uso migliore dello spazio.

Tuttavia, il tuo computer probabilmente non è a 8 bit e probabilmente non è a 16 bit. questo significa che per ottenere 16 o 8 bit in particolare, bisognerebbe ricorrere ad un "trucco" che fa perdere tempo per fingere di avere la capacità di accedere a quei tipi quando necessario.

A questo punto, dipende da come viene implementato l'hardware. Tuttavia, da quanto ho pensato, la migliore velocità si ottiene memorizzando le cose in blocchi che sono comodi da usare per la tua CPU. A un processore a 64 bit piace trattare con elementi a 64 bit, e qualsiasi cosa meno spesso richiede "magia ingegneristica" per fingere che gli piaccia occuparsene.

Uno dei motivi per cui short / byte / char è meno performante è la mancanza di supporto diretto per questi tipi di dati. Per supporto diretto, significa che le specifiche JVM non menzionano alcun set di istruzioni per questi tipi di dati. Istruzioni come store, load, add ecc. Hanno versioni per il tipo di dati int. Ma non hanno versioni per short / byte / char. Ad esempio, considera di seguito il codice Java:

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

Lo stesso viene convertito in codice macchina come di seguito.

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

Ora, considera di cambiare int in short come di seguito.

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

Il codice macchina corrispondente cambierà come segue:

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

Come puoi osservare, per manipolare il tipo di dati short, utilizza ancora la versione dell'istruzione del tipo di dati int e converte esplicitamente int in short quando richiesto. Ora, a causa di ciò, le prestazioni vengono ridotte.

Ora, motivo addotto per non fornire supporto diretto come segue:

La Java Virtual Machine fornisce il supporto più diretto per i dati di tipo int. Ciò è in parte in previsione di implementazioni efficienti degli stack di operandi e degli array di variabili locali della Java Virtual Machine. È anche motivato dalla frequenza dei dati int nei programmi tipici. Altri tipi integrali hanno un supporto meno diretto. Ad esempio, non ci sono byte, char o versioni brevi delle istruzioni per memorizzare, caricare o aggiungere.

Citato dalla specifica JVM presente qui (pagina 58).

La differenza è appena percettibile! È più una questione di design, adeguatezza, uniformità, abitudine, ecc ... A volte è solo una questione di gusti. Quando tutto ciò che ti interessa è che il tuo programma sia attivo e funzionante e sostituire una floatcon una intnon danneggerebbe la correttezza, non vedo alcun vantaggio nell'usare l'uno o l'altro a meno che tu non possa dimostrare che l'uso di entrambi i tipi altera le prestazioni. L'ottimizzazione delle prestazioni in base a tipi diversi in 2 o 3 byte è davvero l'ultima cosa di cui dovresti preoccuparti; Donald Knuth una volta disse: "L'ottimizzazione prematura è la radice di tutti i mali" (non sono sicuro che fosse lui, modifica se hai la risposta).