Em java, é mais eficiente usar byte ou short em vez de int e float em vez de double?

Percebi que sempre usei int e doubles, não importa o quão pequeno ou grande o número precise ser. Portanto, em java, é mais eficiente usar byteou em shortvez de inte em floatvez de double?

Portanto, suponha que tenho um programa com muitos ints e duplos. Valeria a pena examinar e mudar meus ints para bytes ou shorts se eu soubesse que o número caberia?

Eu sei que o java não tem tipos não assinados, mas há algo extra que eu pudesse fazer se soubesse que o número seria positivo apenas?

Por eficiente, quero dizer principalmente processamento. Eu presumiria que o coletor de lixo seria muito mais rápido se todas as variáveis ​​tivessem metade do tamanho e que os cálculos provavelmente seriam um pouco mais rápidos também. (Acho que, já que estou trabalhando no Android, preciso me preocupar um pouco com a memória RAM também)

(Eu presumo que o coletor de lixo lida apenas com objetos e não primitivos, mas ainda exclui todos os primitivos em objetos abandonados, certo?)

Eu tentei com um pequeno aplicativo Android que tenho, mas realmente não notei nenhuma diferença. (Embora eu não tenha medido nada "cientificamente".)

Estou errado em presumir que deveria ser mais rápido e eficiente? Eu odiaria mudar tudo em um programa enorme para descobrir que perdi meu tempo.

Valeria a pena fazer desde o início quando eu começar um novo projeto? (Quer dizer, acho que qualquer pequena parte ajudaria, mas então, novamente, se sim, por que não parece que alguém faz isso.)

Estou errado em presumir que deveria ser mais rápido e eficiente? Eu odiaria mudar tudo em um programa enorme para descobrir que perdi meu tempo.

Resposta curta

Sim, você está errado. Na maioria dos casos, faz pouca diferença em termos de espaço usado.

Não vale a pena tentar otimizar isso ... a menos que você tenha evidências claras de que a otimização é necessária. E se você precisar otimizar o uso de memória de campos de objeto em particular, provavelmente precisará tomar outras medidas (mais eficazes).

Resposta mais longa

A Java Virtual Machine modela pilhas e campos de objeto usando deslocamentos que são (na verdade) múltiplos de um tamanho de célula primitiva de 32 bits. Portanto, quando você declara uma variável local ou campo de objeto como (digamos) a byte, a variável / campo será armazenado em uma célula de 32 bits, assim como um int.

Existem duas exceções a isso:

• longe os doublevalores requerem 2 células primitivas de 32 bits
• arrays de tipos primitivos são representados na forma compactada, de forma que (por exemplo) um array de bytes mantenha 4 bytes por palavra de 32 bits.

Portanto, pode valer a pena otimizar o uso de longe double... e grandes matrizes de primitivas. Mas em geral não.

^{Em teoria, um JIT pode ser capaz de otimizar isso, mas na prática nunca ouvi falar de um JIT que o fizesse. Um impedimento é que o JIT normalmente não pode ser executado até que as instâncias da classe que está sendo compilada tenham sido criadas. Se o JIT otimizasse o layout da memória, você poderia ter dois (ou mais) "sabores" de objeto da mesma classe ... e isso apresentaria enormes dificuldades.}

Revisão

Olhando para os resultados do benchmark na resposta de @meriton, parece que usar shorte em bytevez de intincorre em uma penalidade de desempenho para a multiplicação. Na verdade, se você considerar as operações isoladamente, a penalidade é significativa. (Você não deve considerá-los isoladamente ... mas isso é outro tópico.)

Acho que a explicação é que o JIT provavelmente está fazendo as multiplicações usando instruções de multiplicação de 32 bits em cada caso. Mas no caso bytee short, ele executa instruções extras para converter o valor intermediário de 32 bits em um byteou shortem cada iteração do loop. (Em teoria, essa conversão poderia ser feita uma vez no final do loop ... mas duvido que o otimizador consiga descobrir isso.)

De qualquer forma, isso aponta para outro problema com a mudança para shorte bytecomo uma otimização. Poderia fazer desempenho pior ... em um algoritmo que é aritmética e computação intensiva.

Isso depende da implementação da JVM, bem como do hardware subjacente. A maioria dos hardwares modernos não busca bytes únicos da memória (ou mesmo do cache de primeiro nível), ou seja, usar os tipos primitivos menores geralmente não reduz o consumo de largura de banda da memória. Da mesma forma, a CPU moderna tem um tamanho de palavra de 64 bits. Eles podem realizar operações em menos bits, mas isso funciona descartando os bits extras, o que também não é mais rápido.

O único benefício é que tipos primitivos menores podem resultar em um layout de memória mais compacto, principalmente ao usar arrays. Isso economiza memória, o que pode melhorar a localidade de referência (reduzindo assim o número de perdas de cache) e reduzir a sobrecarga da coleta de lixo.

De modo geral, entretanto, usar os tipos primitivos menores não é mais rápido.

Para demonstrar isso, observe a seguinte referência:

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

que imprime em meu caderno um tanto antigo (adicionando espaços para ajustar colunas):

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

Como você pode ver, as diferenças de desempenho são mínimas. Otimizar algoritmos é muito mais importante do que a escolha do tipo primitivo.

Usar em bytevez de intpode aumentar o desempenho se você os usar em grande quantidade. Aqui está uma experiência:

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


}

}

Esta aula testa a velocidade de criação de um novo TestClass. Cada teste faz isso 20 milhões de vezes e há 50 testes.

Aqui está o 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; 
 }

Eu dirigi a SpeedTestaula e no final consegui isso:

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

Agora estou transformando os ints em bytes no TestClass e executando-o novamente. Aqui está o resultado:

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

Eu acredito que este experimento mostra que se você está criando uma instância de uma grande quantidade de variáveis, usar byte em vez de int pode aumentar a eficiência

byte é geralmente considerado como 8 bits. curto é geralmente considerado como 16 bits.

Em um ambiente "puro", que não é java, já que todas as implementações de bytes e longs, shorts e outras coisas divertidas geralmente ficam escondidas de você, o byte faz melhor uso do espaço.

No entanto, seu computador provavelmente não é de 8 bits e provavelmente não é de 16 bits. isso significa que, para obter 16 ou 8 bits em particular, seria necessário recorrer a "artifícios" que perdem tempo para fingir que tem a capacidade de acessar esses tipos quando necessário.

Neste ponto, depende de como o hardware é implementado. No entanto, pelo que fui ensinado, a melhor velocidade é obtida armazenando coisas em blocos que sejam confortáveis ​​para o uso da CPU. Um processador de 64 bits gosta de lidar com elementos de 64 bits e qualquer coisa menos do que isso geralmente requer "mágica de engenharia" para fingir que gosta de lidar com eles.

Uma das razões para short / byte / char ter menos desempenho é a falta de suporte direto para esses tipos de dados. Por suporte direto, isso significa que as especificações JVM não mencionam nenhum conjunto de instruções para esses tipos de dados. Instruções como armazenar, carregar, adicionar etc. têm versões para o tipo de dados int. Mas eles não têm versões para short / byte / char. Por exemplo, considere o código java abaixo:

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

O mesmo é convertido em código de máquina conforme abaixo.

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

Agora, considere alterar int para short conforme abaixo.

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

O código de máquina correspondente mudará da seguinte forma:

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

Como você pode observar, para manipular o tipo de dados curto, ele ainda está usando a versão de instrução do tipo de dados int e explicitamente convertendo int em curto quando necessário. Agora, devido a isso, o desempenho fica reduzido.

Agora, o motivo citado para não dar suporte direto como segue:

A Java Virtual Machine fornece o suporte mais direto para dados do tipo int. Isso ocorre em parte em antecipação às implementações eficientes das pilhas de operandos e matrizes de variáveis ​​locais da Java Virtual Machine. Também é motivado pela frequência de dados internos em programas típicos. Outros tipos integrais têm menos suporte direto. Não há byte, char ou versões curtas das instruções de armazenamento, carregamento ou adição, por exemplo.

Citado da especificação JVM presente aqui (Página 58).

A diferença é quase imperceptível! É mais uma questão de design, adequação, uniformidade, hábito, etc ... Às vezes é só uma questão de gosto. Quando tudo o que você importa é que seu programa comece a funcionar e substituir um floatpor um intnão prejudicaria a correção, não vejo nenhuma vantagem em escolher um ou outro, a menos que você possa demonstrar que o uso de qualquer um dos tipos altera o desempenho. Ajustar o desempenho com base em tipos que são diferentes em 2 ou 3 bytes é realmente a última coisa com a qual você deve se preocupar; Donald Knuth disse uma vez: "A otimização prematura é a raiz de todos os males" (não tenho certeza se foi ele, edite se você tiver a resposta).