En java, est-il plus efficace d'utiliser byte ou short au lieu de int et float au lieu de double?

J'ai remarqué que j'ai toujours utilisé int et double, peu importe la taille du nombre. Donc, en Java, est-il plus efficace d'utiliser byteou à la shortplace de intet à la floatplace de double?

Supposons donc que j'ai un programme avec beaucoup d'entiers et de doubles. Cela vaudrait-il la peine de passer en revue et de changer mes entiers en octets ou en short si je savais que le nombre conviendrait?

Je sais que java n'a pas de types non signés, mais y a-t-il quelque chose de plus que je pourrais faire si je savais que le nombre serait uniquement positif?

Par efficace, j'entends principalement le traitement. Je suppose que le ramasse-miettes serait beaucoup plus rapide si toutes les variables avaient la moitié de la taille et que les calculs seraient probablement un peu plus rapides aussi. (Je suppose que depuis que je travaille sur Android, je dois aussi m'inquiéter pour la RAM)

(Je suppose que le garbage collector ne traite que des objets et non des primitifs, mais supprime toujours toutes les primitives des objets abandonnés, n'est-ce pas?)

Je l'ai essayé avec une petite application Android que j'ai mais je n'ai pas vraiment remarqué de différence. (Bien que je n'ai rien mesuré "scientifiquement".)

Ai-je tort de supposer que cela devrait être plus rapide et plus efficace? Je détesterais tout changer dans un programme massif pour découvrir que j'ai perdu mon temps.

Cela vaudrait-il la peine de le faire dès le début lorsque je démarre un nouveau projet? (Je veux dire, je pense que chaque petit geste aiderait, mais encore une fois, si c'est le cas, pourquoi ne semble-t-il pas que quelqu'un le fasse.)

Ai-je tort de supposer que cela devrait être plus rapide et plus efficace? Je détesterais tout changer dans un programme massif pour découvrir que j'ai perdu mon temps.

Réponse courte

Oui, vous vous trompez. Dans la plupart des cas, cela fait peu de différence en termes d'espace utilisé.

Cela ne vaut pas la peine d' essayer d'optimiser cela ... sauf si vous avez des preuves claires qu'une optimisation est nécessaire. Et si vous avez besoin d'optimiser l'utilisation de la mémoire des champs d'objets en particulier, vous devrez probablement prendre d'autres mesures (plus efficaces).

Réponse plus longue

La machine virtuelle Java modélise les piles et les champs d'objet à l'aide de décalages qui sont (en fait) des multiples d'une taille de cellule primitive de 32 bits. Ainsi, lorsque vous déclarez une variable locale ou un champ objet comme (disons) a byte, la variable / champ sera stocké dans une cellule de 32 bits, tout comme un int.

Il y a deux exceptions à cela:

• longet les doublevaleurs nécessitent 2 cellules 32 bits primitives
• les tableaux de types primitifs sont représentés sous forme condensée, de sorte que (par exemple) un tableau d'octets contienne 4 octets par mot de 32 bits.

Il pourrait donc être intéressant d'optimiser l'utilisation de longet double... et de grands tableaux de primitives. Mais en général non.

^{En théorie, un JIT pourrait être en mesure d'optimiser cela, mais en pratique, je n'ai jamais entendu parler d'un JIT qui le fasse. Un obstacle est que le JIT ne peut généralement pas s'exécuter tant que les instances de la classe en cours de compilation n'ont pas été créées. Si le JIT optimisait la disposition de la mémoire, vous pourriez avoir deux (ou plus) "saveurs" d'objets de la même classe ... et cela présenterait d'énormes difficultés.}

Revisitation

En regardant les résultats de référence dans la réponse de @ meriton, il semble que l'utilisation de shortet byteau lieu de intentraîne une pénalité de performance pour la multiplication. En effet, si vous considérez les opérations isolément, la pénalité est importante. (Vous ne devriez pas les considérer isolément ... mais c'est un autre sujet.)

Je pense que l'explication est que JIT fait probablement les multiplications en utilisant des instructions de multiplication 32 bits dans chaque cas. Mais dans le cas byteet short, il exécute des instructions supplémentaires pour convertir la valeur intermédiaire de 32 bits en une byteou shortà chaque itération de boucle. (En théorie, cette conversion pourrait être effectuée une fois à la fin de la boucle ... mais je doute que l'optimiseur soit capable de le comprendre.)

Quoi qu'il en soit, cela indique un autre problème avec le passage à shortet byteen tant qu'optimisation. Il pourrait faire des performances pire ... dans un algorithme qui est arithmétique et calcul intensif.

Cela dépend de l'implémentation de la JVM, ainsi que du matériel sous-jacent. La plupart du matériel moderne n'extraira pas un octet de la mémoire (ou même du cache de premier niveau), c'est-à-dire que l'utilisation de types primitifs plus petits ne réduit généralement pas la consommation de bande passante mémoire. De même, les processeurs modernes ont une taille de mot de 64 bits. Ils peuvent effectuer des opérations sur moins de bits, mais cela fonctionne en supprimant les bits supplémentaires, ce qui n'est pas plus rapide non plus.

Le seul avantage est que les types primitifs plus petits peuvent entraîner une disposition de la mémoire plus compacte, notamment lors de l'utilisation de tableaux. Cela économise de la mémoire, ce qui peut améliorer la localité de référence (réduisant ainsi le nombre d'erreurs de cache) et réduire la surcharge du garbage collection.

Cependant, de manière générale, l'utilisation des types primitifs plus petits n'est pas plus rapide.

Pour le démontrer, voici le repère suivant:

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

qui imprime sur mon cahier un peu vieux (en ajoutant des espaces pour ajuster les colonnes):

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

Comme vous pouvez le voir, les différences de performances sont assez mineures. L'optimisation des algorithmes est bien plus importante que le choix du type primitif.

L'utilisation byteau lieu de intpeut augmenter les performances si vous les utilisez en grande quantité. Voici une expérience:

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


}

}

Cette classe teste la vitesse de création d'un nouveau fichier TestClass. Chaque test le fait 20 millions de fois et il y a 50 tests.

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

J'ai dirigé la SpeedTestclasse et à la fin j'ai ceci:

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

Maintenant, je change les entiers en octets dans TestClass et je l'exécute à nouveau. Voici le résultat:

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

Je crois que cette expérience montre que si vous instanciez une énorme quantité de variables, utiliser byte au lieu de int peut augmenter l'efficacité

byte est généralement considéré comme 8 bits. short est généralement considéré comme 16 bits.

Dans un environnement "pur", qui n'est pas java car toutes les implémentations d'octets et de longs, et les courts-circuits et autres choses amusantes vous sont généralement cachés, byte fait un meilleur usage de l'espace.

Cependant, votre ordinateur n'est probablement pas 8 bits, et probablement pas 16 bits. cela signifie que pour obtenir 16 ou 8 bits en particulier, il lui faudrait recourir à la «supercherie» qui fait perdre du temps pour prétendre avoir la capacité d'accéder à ces types en cas de besoin.

À ce stade, cela dépend de la façon dont le matériel est mis en œuvre. Cependant, d'après ce que j'ai appris, la meilleure vitesse est obtenue en stockant des choses en morceaux qui sont confortables pour votre CPU à utiliser. Un processeur 64 bits aime traiter des éléments 64 bits, et rien de moins que cela nécessite souvent de la "magie d'ingénierie" pour faire semblant de les aimer.

L'une des raisons pour lesquelles short / byte / char est moins performant est le manque de prise en charge directe de ces types de données. Par support direct, cela signifie que les spécifications JVM ne mentionnent aucun jeu d'instructions pour ces types de données. Les instructions telles que stocker, charger, ajouter, etc. ont des versions pour le type de données int. Mais ils n'ont pas de versions pour short / byte / char. Par exemple, considérez ci-dessous le code java:

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

La même chose est convertie en code machine comme ci-dessous.

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

Maintenant, envisagez de changer int en short comme ci-dessous.

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

Le code machine correspondant change comme suit:

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

Comme vous pouvez le constater, pour manipuler un type de données court, il utilise toujours la version d'instruction de type de données int et convertit explicitement int en short lorsque cela est nécessaire. Maintenant, à cause de cela, les performances sont réduites.

Maintenant, la raison invoquée pour ne pas donner de soutien direct est la suivante:

La machine virtuelle Java fournit la prise en charge la plus directe des données de type int. Ceci est en partie en prévision d'implémentations efficaces des piles d'opérandes et des tableaux de variables locales de la machine virtuelle Java. Il est également motivé par la fréquence des données int dans les programmes typiques. D'autres types intégraux ont un support moins direct. Il n'y a pas de version octet, char ou courte des instructions de stockage, de chargement ou d'ajout, par exemple.

Extrait de la spécification JVM présente ici (Page 58).

La différence est à peine perceptible! C'est plus une question de design, de pertinence, d'uniformité, d'habitude, etc ... Parfois c'est juste une question de goût. Lorsque tout ce qui vous importe, c'est que votre programme soit opérationnel et que le remplacement d'un floatpar un intne nuirait pas à l'exactitude, je ne vois aucun avantage à opter pour l'un ou l'autre à moins que vous ne puissiez démontrer que l'utilisation de l'un ou l'autre type altère les performances. L'optimisation des performances en fonction de types différents sur 2 ou 3 octets est vraiment la dernière chose dont vous devriez vous soucier; Donald Knuth a dit un jour: "L'optimisation prématurée est la racine de tout mal" (pas sûr que ce soit lui, éditez si vous avez la réponse).