Trong java, sử dụng byte hoặc short thay vì int và float thay vì double có hiệu quả hơn không?

Tôi nhận thấy rằng tôi luôn sử dụng int và nhân đôi bất kể con số cần phải nhỏ hay lớn. Vậy trong java, sử dụng bytehay shortthay vì intvà floatthay vì hiệu quả hơn double?

Vì vậy, giả sử tôi có một chương trình với nhiều int và gấp đôi. Nó có đáng để đi qua và thay đổi int của tôi thành byte hoặc quần short nếu tôi biết số đó sẽ phù hợp không?

Tôi biết java không có loại không dấu nhưng tôi có thể làm gì thêm nếu tôi biết số sẽ chỉ là số dương?

Theo hiệu quả, tôi chủ yếu có nghĩa là xử lý. Tôi cho rằng bộ thu gom rác sẽ nhanh hơn rất nhiều nếu tất cả các biến có kích thước bằng một nửa và các phép tính đó có lẽ cũng sẽ nhanh hơn một chút. (Tôi đoán vì tôi đang làm việc trên Android, tôi cũng cần phải lo lắng về ram)

(Tôi cho rằng trình thu gom rác chỉ xử lý các Đối tượng chứ không phải nguyên thủy nhưng vẫn xóa tất cả các nguyên thủy trong các đối tượng bị bỏ rơi đúng không?)

Tôi đã thử nó với một ứng dụng Android nhỏ mà tôi có nhưng thực sự không nhận thấy sự khác biệt nào cả. (Mặc dù tôi đã không đo lường "một cách khoa học" bất cứ điều gì.)

Tôi có sai khi cho rằng nó phải nhanh hơn và hiệu quả hơn không? Tôi ghét phải trải qua và thay đổi mọi thứ trong một chương trình lớn để phát hiện ra rằng tôi đã lãng phí thời gian của mình.

Nó có đáng làm ngay từ đầu khi tôi bắt đầu một dự án mới không? (Ý tôi là tôi nghĩ rằng từng chút một sẽ giúp ích nhưng sau đó nếu có thì tại sao có vẻ như không ai làm điều đó.)

Tôi có sai khi cho rằng nó phải nhanh hơn và hiệu quả hơn không? Tôi ghét phải trải qua và thay đổi mọi thứ trong một chương trình lớn để phát hiện ra rằng tôi đã lãng phí thời gian của mình.

Câu trả lời ngắn

Vâng, bạn đã sai. Trong hầu hết các trường hợp, nó tạo ra sự khác biệt nhỏ về không gian sử dụng.

Sẽ không đáng để cố gắng tối ưu hóa điều này ... trừ khi bạn có bằng chứng rõ ràng rằng việc tối ưu hóa là cần thiết. Và nếu bạn cần tối ưu hóa việc sử dụng bộ nhớ của các trường đối tượng, có thể bạn sẽ cần phải thực hiện các biện pháp khác (hiệu quả hơn).

Câu trả lời dài hơn

Máy ảo Java lập mô hình ngăn xếp và trường đối tượng bằng cách sử dụng hiệu số (trên thực tế) là bội số của kích thước ô nguyên thủy 32 bit. Vì vậy, khi bạn khai báo một biến cục bộ hoặc trường đối tượng là (giả sử) a byte, biến / trường sẽ được lưu trữ trong một ô 32 bit, giống như một int.

Có hai ngoại lệ cho điều này:

• longvà doublegiá trị yêu cầu 2 ô 32 bit nguyên thủy
• mảng của kiểu nguyên thủy được biểu diễn ở dạng đóng gói, để (ví dụ) một mảng byte chứa 4 byte cho mỗi từ 32 bit.

Vì vậy, nó có thể đáng để tối ưu hóa việc sử dụng longvà double... và các mảng lớn các nguyên thủy. Nhưng nói chung là không.

^{Về lý thuyết, một JIT có thể tối ưu hóa điều này, nhưng trong thực tế, tôi chưa bao giờ nghe nói về một JIT làm được điều này. Một trở ngại là JIT thường không thể chạy cho đến khi các phiên bản của lớp đang được biên dịch được tạo ra. Nếu JIT tối ưu hóa bố cục bộ nhớ, bạn có thể có hai (hoặc nhiều hơn) "hương vị" của đối tượng cùng lớp ... và điều đó sẽ gây ra khó khăn lớn.}

Revisitation

Nhìn vào kết quả điểm chuẩn trong câu trả lời của @ Meriton, có vẻ như việc sử dụng shortvà bytethay vì intphải chịu một hình phạt về hiệu suất cho phép nhân. Thật vậy, nếu bạn xem xét các hoạt động một cách cô lập, hình phạt là đáng kể. (Bạn không nên xem xét chúng một cách cô lập ... nhưng đó là một chủ đề khác.)

Tôi nghĩ rằng lời giải thích là JIT có thể đang thực hiện các phép nhân bằng cách sử dụng các lệnh nhân 32bit trong mỗi trường hợp. Nhưng trong trường hợp bytevà shorttrường hợp, nó thực hiện các lệnh bổ sung để chuyển đổi giá trị 32 bit trung gian thành a bytehoặc shorttrong mỗi lần lặp vòng lặp. (Về lý thuyết, chuyển đổi đó có thể được thực hiện một lần khi kết thúc vòng lặp ... nhưng tôi nghi ngờ rằng trình tối ưu hóa có thể tìm ra điều đó.)

Dù sao, điều này chỉ ra một vấn đề khác với việc chuyển đổi sang shortvà bytetối ưu hóa. Nó có thể làm cho hiệu suất kém hơn ... trong một thuật toán chuyên sâu về số học và tính toán.

Điều đó phụ thuộc vào việc triển khai JVM, cũng như phần cứng bên dưới. Hầu hết phần cứng hiện đại sẽ không tìm nạp các byte đơn lẻ từ bộ nhớ (hoặc thậm chí từ bộ đệm cấp đầu tiên), tức là việc sử dụng các loại nguyên thủy nhỏ hơn thường không làm giảm mức tiêu thụ băng thông bộ nhớ. Tương tự như vậy, CPU hiện đại có kích thước từ là 64 bit. Chúng có thể thực hiện các hoạt động trên ít bit hơn, nhưng điều đó hoạt động bằng cách loại bỏ các bit thừa, điều này cũng không nhanh hơn.

Lợi ích duy nhất là các kiểu nguyên thủy nhỏ hơn có thể dẫn đến bố cục bộ nhớ nhỏ gọn hơn, đáng chú ý nhất là khi sử dụng mảng. Điều này tiết kiệm bộ nhớ, có thể cải thiện vị trí của tham chiếu (do đó giảm số lần bỏ lỡ bộ nhớ cache) và giảm chi phí thu gom rác.

Nói chung, tuy nhiên, sử dụng các kiểu nguyên thủy nhỏ hơn không nhanh hơn.

Để chứng minh điều đó, hãy xem điểm chuẩn sau:

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

mà in trên sổ tay hơi cũ của tôi (thêm khoảng trắng để điều chỉnh cột):

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

Như bạn có thể thấy, sự khác biệt về hiệu suất là khá nhỏ. Việc tối ưu hóa các thuật toán quan trọng hơn nhiều so với việc lựa chọn kiểu nguyên thủy.

Sử dụng bytethay vì intcó thể tăng hiệu suất nếu bạn đang sử dụng chúng với số lượng lớn. Đây là một thử nghiệm:

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


}

}

Lớp này kiểm tra tốc độ tạo mới TestClass. Mỗi bài kiểm tra thực hiện nó 20 triệu lần và có 50 bài kiểm tra.

Đây là 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; 
 }

Tôi đã điều hành SpeedTestlớp học và cuối cùng nhận được điều này:

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

Bây giờ tôi đang thay đổi int thành byte trong TestClass và chạy lại. Đây là kết quả:

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

Tôi tin rằng thử nghiệm này cho thấy rằng nếu bạn đang cài đặt một lượng lớn các biến, việc sử dụng byte thay vì int có thể tăng hiệu quả

byte thường được coi là 8 bit. ngắn thường được coi là 16 bit.

Trong một môi trường "thuần túy", không phải là java vì tất cả việc triển khai byte và long, và short, và những thứ thú vị khác thường bị ẩn khỏi bạn, byte tận dụng không gian tốt hơn.

Tuy nhiên, máy tính của bạn có thể không phải là 8 bit và có thể không phải là 16 bit. điều này có nghĩa là để có được 16 hoặc 8 bit cụ thể, nó sẽ cần phải dùng đến "thủ thuật" lãng phí thời gian để giả vờ rằng nó có khả năng truy cập các loại đó khi cần thiết.

Tại thời điểm này, nó phụ thuộc vào cách phần cứng được thực hiện. Tuy nhiên, theo suy nghĩ của tôi, tốc độ tốt nhất đạt được khi lưu trữ mọi thứ theo khối mà CPU của bạn có thể thoải mái sử dụng. Bộ xử lý 64 bit thích xử lý các phần tử 64 bit và bất cứ thứ gì ít hơn thế thường yêu cầu "phép thuật kỹ thuật" để giả vờ rằng nó thích xử lý chúng.

Một trong những lý do khiến short / byte / char kém hiệu quả hơn là do thiếu hỗ trợ trực tiếp cho các kiểu dữ liệu này. Bằng sự hỗ trợ trực tiếp, có nghĩa là, các đặc tả JVM không đề cập đến bất kỳ tập lệnh nào cho các kiểu dữ liệu này. Các hướng dẫn như lưu trữ, tải, thêm, v.v. có phiên bản cho kiểu dữ liệu int. Nhưng chúng không có phiên bản cho short / byte / char. Ví dụ: xem xét mã java dưới đây:

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

Tương tự được chuyển đổi thành mã máy như bên dưới.

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

Bây giờ, hãy xem xét việc thay đổi int thành short như bên dưới.

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

Mã máy tương ứng sẽ thay đổi như sau:

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

Như bạn có thể quan sát, để thao tác với kiểu dữ liệu ngắn, nó vẫn đang sử dụng phiên bản hướng dẫn kiểu dữ liệu int và chuyển đổi rõ ràng int thành short khi được yêu cầu. Bây giờ, do điều này, hiệu suất bị giảm.

Bây giờ, lý do được viện dẫn để không hỗ trợ trực tiếp như sau:

Máy ảo Java cung cấp hỗ trợ trực tiếp nhất cho dữ liệu kiểu int. Điều này một phần dự đoán việc triển khai hiệu quả các ngăn xếp toán hạng của Máy ảo Java và mảng biến cục bộ. Nó cũng được thúc đẩy bởi tần suất của dữ liệu int trong các chương trình điển hình. Các loại tích phân khác có ít hỗ trợ trực tiếp hơn. Ví dụ: không có byte, ký tự hoặc phiên bản ngắn của cửa hàng, tải hoặc thêm hướng dẫn.

Trích dẫn từ thông số kỹ thuật JVM có ở đây (Trang 58).

Sự khác biệt là khó nhận thấy! Đó là vấn đề nhiều hơn về thiết kế, sự phù hợp, tính đồng nhất, thói quen, v.v. Đôi khi nó chỉ là vấn đề về sở thích. Khi tất cả những gì bạn quan tâm là chương trình của bạn được khởi động và chạy và việc thay thế a floatcho một intsẽ không gây hại cho tính đúng đắn, tôi thấy không có lợi khi sử dụng cái này hay cái khác trừ khi bạn có thể chứng minh rằng việc sử dụng một trong hai loại sẽ thay đổi hiệu suất. Điều chỉnh hiệu suất dựa trên các loại khác nhau trong 2 hoặc 3 byte thực sự là điều cuối cùng bạn nên quan tâm; Donald Knuth từng nói: "Tối ưu hóa sớm là gốc rễ của mọi điều xấu xa" (chưa chắc đã là anh ta, hãy chỉnh sửa nếu bạn có câu trả lời).