Java'da, int ve float yerine double yerine byte veya short kullanmak daha mı verimli?

Sayı ne kadar küçük veya büyük olursa olsun her zaman int ve double kullandığımı fark ettim. Java Yani, kullanmak daha verimlidir byteveya shortyerine intve floatyerine double?

Öyleyse, bol miktarda ints ve double içeren bir programım olduğunu varsayalım. Sayının uygun olacağını bilseydim, derinliklerimi bayt veya kısa olarak değiştirmeye değer mi?

Java'nın işaretsiz türleri olmadığını biliyorum, ancak sayının yalnızca pozitif olacağını bilseydim yapabileceğim fazladan bir şey var mı?

Verimli derken çoğunlukla işlemeyi kastediyorum. Tüm değişkenler yarım boyutta olsaydı ve hesaplamaların da muhtemelen biraz daha hızlı olacağını düşünürdüm, çöp toplayıcı çok daha hızlı olurdu. (Sanırım android üzerinde çalıştığım için ram konusunda da biraz endişelenmem gerekiyor)

(Çöp toplayıcının yalnızca Nesnelerle uğraştığını ve ilkel olmadığını, ancak yine de terk edilmiş nesnelerdeki tüm ilkelleri sildiğini varsayıyorum, değil mi?)

Sahip olduğum küçük bir android uygulamasıyla denedim ama gerçekten bir fark görmedim. (Hiçbir şeyi "bilimsel olarak" ölçmemiş olsam da.)

Daha hızlı ve daha verimli olması gerektiğini varsaymakta yanlış mıyım? Zamanımı boşa harcadığımı anlamak için büyük bir programda her şeyi değiştirmekten nefret ederim.

Yeni bir projeye başladığımda baştan yapmaya değer mi? (Demek istediğim, her küçük parçanın yardımcı olacağını düşünüyorum ama öyleyse yine neden kimse yapmıyor gibi görünüyor?)

Daha hızlı ve daha verimli olması gerektiğini varsaymakta yanlış mıyım? Zamanımı boşa harcadığımı anlamak için büyük bir programda her şeyi değiştirmekten nefret ederim.

Kısa cevap

Evet yanılıyorsunuz. Çoğu durumda, kullanılan alan açısından çok az fark yaratır.

Öyle değmez optimizasyon gerekli olduğunu açık kanıtlar olmadığı sürece ... Bu duruma getirmek için çalışıyoruz. Eğer yoksa Ve gerek özellikle nesne alanlarının optimize bellek kullanımına, muhtemelen diğer (daha etkili) önlemler almak gerekir.

Daha uzun cevap

Java Sanal Makinesi, 32 bitlik ilkel hücre boyutunun (gerçekte) katları olan ofsetleri kullanarak yığınları ve nesne alanlarını modeller. Dolayısıyla, yerel bir değişkeni veya nesne alanını (diyelim ki) a olarak ilan ettiğinizde byte, değişken / alan, tıpkı int.

Bunun iki istisnası vardır:

• longve doubledeğerler 2 ilkel 32 bit hücre gerektirir
• İlkel tür dizileri, (örneğin) bir bayt dizisi 32 bit kelime başına 4 bayt tutacak şekilde paketlenmiş biçimde temsil edilir.

Bu yüzden ve ... ve büyük ilkel dizilerin kullanımını optimize etmeye değer olabilir . Ama genel olarak hayır.longdouble

^{Teorik olarak, bir JIT olabilir bu optimize edebilmek, ama pratikte ben yapan bir JIT duymadım. Bir engel, JIT'in tipik olarak, derlenen sınıfın örnekleri yaratılıncaya kadar çalışamayacağıdır. JIT bellek düzenini optimize ettiyse, aynı sınıftaki nesnenin iki (veya daha fazla) "çeşidine" sahip olabilirsiniz ... ve bu büyük zorluklara neden olur.}

Yeniden ziyaret

@ Meriton'ın cevabındaki kıyaslama sonuçlarına bakıldığında, çarpma için shortve byteyerine kullanmak intbir performans cezasına neden olur. Nitekim, operasyonları tek başına ele alırsanız, ceza önemlidir. (Onları tek başına düşünmemelisiniz ... ama bu başka bir konu.)

Sanırım açıklama, JIT'in muhtemelen çarpmaları her durumda 32bit çarpma talimatlarını kullanarak yapıyor olmasıdır. Ancak byteve shortdurumunda, ara 32 bit değerini a veya her döngü yinelemesinde dönüştürmek için ekstra talimatlar yürütür . (Teoride, bu dönüşüm döngünün sonunda bir kez yapılabilir ... ancak optimize edicinin bunu çözebileceğinden şüpheliyim.)byteshort

Neyse, bu geçiş ile başka soruna noktayı yapar shortve bytebir optimizasyon olarak. Aritmetik ve yoğun işlem gerektiren bir algoritmada performansı daha da kötüleştirebilir .

Bu, JVM'nin uygulanmasına ve temeldeki donanıma bağlıdır. Çoğu modern donanım, tek baytları bellekten (veya hatta birinci seviye önbellekten) almayacaktır, yani daha küçük ilkel türlerin kullanılması genellikle bellek bant genişliği tüketimini azaltmaz. Aynı şekilde, modern CPU'nun kelime boyutu 64 bittir. İşlemleri daha az bit üzerinde gerçekleştirebilirler, ancak bu da daha hızlı olmayan ekstra bitleri atarak çalışır.

Tek faydası, daha küçük ilkel türlerin, özellikle dizileri kullanırken, daha kompakt bir bellek düzeniyle sonuçlanabilmesidir. Bu, bellekten tasarruf sağlayarak referansın yerelliğini iyileştirebilir (böylece önbellek kayıplarının sayısını azaltabilir) ve çöp toplama ek yükünü azaltabilir.

Ancak genel olarak konuşursak, daha küçük ilkel türleri kullanmak daha hızlı değildir.

Bunu göstermek için aşağıdaki karşılaştırmaya bakın:

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

biraz eski defterime yazdırılan (sütunları ayarlamak için boşluk ekleyerek):

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

Gördüğünüz gibi, performans farklılıkları oldukça küçük. Algoritmaları optimize etmek, ilkel tür seçiminden çok daha önemlidir.

byteBunun yerine kullanmak int, büyük miktarda kullanıyorsanız performansı artırabilir. İşte bir deney:

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


}

}

Bu sınıf, yeni bir TestClass. Her test bunu 20 milyon kez yapıyor ve 50 test var.

İşte 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; 
 }

SpeedTestSınıfı yönetiyorum ve sonunda şunu anladım:

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

Şimdi TestClass'ta ints'i bayta dönüştürüp tekrar çalıştırıyorum. İşte sonuç:

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

İnanıyorum ki bu deney, çok miktarda değişken örnekliyorsanız, int yerine bayt kullanmanın verimliliği artırabileceğini

bayt genellikle 8 bit olarak kabul edilir. kısa, genellikle 16 bit olarak kabul edilir.

Baytların, uzunların ve kısa ve diğer eğlenceli şeylerin tüm uygulamaları gibi java olmayan "saf" bir ortamda, bayt, alanı daha iyi kullanır.

Bununla birlikte, bilgisayarınız muhtemelen 8 bit değildir ve muhtemelen 16 bit değildir. bu, özellikle 16 veya 8 bit elde etmek için, gerektiğinde bu türlere erişme yeteneğine sahipmiş gibi davranmak için zaman harcayan "hileye" başvurması gerektiği anlamına gelir.

Bu noktada, donanımın nasıl uygulandığına bağlıdır. Bununla birlikte, öğrendiğim kadarıyla, en iyi hız, CPU'nuzun kullanımı için rahat olan şeyleri yığınlar halinde depolayarak elde edilir. 64 bitlik bir işlemci, 64 bit öğelerle uğraşmaktan hoşlanır ve bundan daha azı, onlarla uğraşmayı seviyormuş gibi davranmak için genellikle "mühendislik sihri" gerektirir.

Short / byte / char'ın daha az performanslı olmasının nedenlerinden biri, bu veri türleri için doğrudan destek eksikliğidir. Doğrudan destekle, JVM spesifikasyonlarının bu veri türleri için herhangi bir komut setinden bahsetmediği anlamına gelir. Depola, yükle, ekle vb. Talimatların int veri türü için sürümleri vardır. Ancak kısa / bayt / karakter için sürümleri yoktur. Örneğin, aşağıdaki java kodunu düşünün:

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

Aynısı aşağıdaki gibi makine koduna dönüştürülür.

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

Şimdi, aşağıdaki gibi int'i kısa olarak değiştirmeyi düşünün.

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

İlgili makine kodu aşağıdaki şekilde değişecektir:

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

Gördüğünüz gibi, kısa veri tipini değiştirmek için, hala int veri tipi komut versiyonunu kullanıyor ve gerektiğinde int'i açıkça kısaca dönüştürüyor. Artık bundan dolayı performans düşüyor.

Şimdi, doğrudan destek vermemenin gerekçesi şu şekildedir:

Java Sanal Makinesi, int türündeki veriler için en doğrudan desteği sağlar. Bu kısmen Java Sanal Makinesi'nin işlenen yığınlarının ve yerel değişken dizilerinin verimli uygulamalarının öngörülmesidir. Ayrıca tipik programlarda int verilerinin sıklığı ile motive edilir. Diğer integral türleri daha az doğrudan desteğe sahiptir. Örneğin, mağaza, yükleme veya ekleme talimatlarının bayt, karakter veya kısa sürümleri yoktur.

Burada bulunan JVM spesifikasyonundan alıntılanmıştır (Sayfa 58).

Fark neredeyse hiç fark edilmiyor! Daha çok bir tasarım, uygunluk, tekdüzelik, alışkanlık vb. Meseleler ... Bazen bu sadece bir zevk meselesi. Önemsediğiniz tüm program ve koşma ve bir ikame ayağa kalkar o olduğunda floatbir için intdoğruluğunu zarar vermeyecek, ben biri için gidiş herhangi bir avantaj ya da başka sen kanıtlayamazlarsa bu da tip değişiklikler gösterirse performansını kullanarak. Performansın 2 veya 3 bayt cinsinden farklı türlere göre ayarlanması gerçekten önemsemeniz gereken son şeydir; Donald Knuth bir keresinde şöyle demişti: "Erken optimizasyon tüm kötülüklerin köküdür" (onun olduğundan emin değilim, cevabınız varsa düzenleyin).