Tại sao GCC không tối ưu hóa a * a * a * a * a * a thành (a * a * a) * (a * a * a)?

Tôi đang thực hiện một số tối ưu hóa số trên một ứng dụng khoa học. Một điều tôi nhận thấy là GCC sẽ tối ưu hóa cuộc gọi pow(a,2)bằng cách biên dịch nó a*a, nhưng cuộc gọi pow(a,6)không được tối ưu hóa và thực sự sẽ gọi chức năng thư viện pow, điều này làm chậm hiệu suất rất nhiều. (Ngược lại, Trình biên dịch Intel C ++ , có thể thực thi được icc, sẽ loại bỏ lệnh gọi thư viện pow(a,6).)

Điều tôi tò mò là khi tôi thay thế pow(a,6)bằng a*a*a*a*a*acách sử dụng GCC 4.5.1 và các tùy chọn " -O3 -lm -funroll-loops -msse4", nó sử dụng 5 mulsdhướng dẫn:

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13

trong khi nếu tôi viết (a*a*a)*(a*a*a), nó sẽ tạo ra

movapd  %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm14, %xmm13
mulsd   %xmm13, %xmm13

làm giảm số lượng hướng dẫn nhân lên 3. icccó hành vi tương tự.

Tại sao trình biên dịch không nhận ra thủ thuật tối ưu hóa này?

Bởi vì Toán học dấu phẩy động không liên kết . Cách bạn nhóm các toán hạng trong phép nhân dấu phẩy động có ảnh hưởng đến độ chính xác của câu trả lời.

Do đó, hầu hết các trình biên dịch đều rất thận trọng về việc sắp xếp lại các phép tính dấu phẩy động trừ khi chúng có thể chắc chắn rằng câu trả lời sẽ giữ nguyên hoặc trừ khi bạn nói với chúng rằng bạn không quan tâm đến độ chính xác của số. Ví dụ: các -fassociative-mathtùy chọn của gcc gcc cho phép để hoạt động điểm nổi reassociate, hoặc thậm chí các -ffast-mathtùy chọn cho phép thậm chí cân bằng tích cực hơn về tính chính xác đối với tốc độ.

Lambdageek một cách chính xác chỉ ra rằng vì associativity không giữ cho số dấu chấm động, các "tối ưu hóa" củaa*a*a*a*a*ađể(a*a*a)*(a*a*a)có thể thay đổi giá trị. Đây là lý do tại sao nó không được phép bởi C99 (trừ khi được người dùng cho phép cụ thể, thông qua cờ trình biên dịch hoặc pragma). Nói chung, giả định là lập trình viên đã viết những gì cô ấy đã làm vì một lý do và trình biên dịch nên tôn trọng điều đó. Nếu bạn muốn(a*a*a)*(a*a*a), viết nó.

Đó có thể là một nỗi đau để viết, mặc dù; tại sao trình biên dịch không thể làm [những gì bạn cho là] đúng khi bạn sử dụng pow(a,6)? Bởi vì nó sẽ là điều sai trái để làm. Trên một nền tảng với một thư viện toán học tốt, pow(a,6)chính xác hơn đáng kể so với a*a*a*a*a*ahoặc (a*a*a)*(a*a*a). Chỉ để cung cấp một số dữ liệu, tôi đã chạy một thử nghiệm nhỏ trên Mac Pro của mình, đo lường lỗi tồi tệ nhất khi đánh giá ^ 6 cho tất cả các số nổi chính xác đơn giữa [1,2):

worst relative error using    powf(a, 6.f): 5.96e-08
worst relative error using (a*a*a)*(a*a*a): 2.94e-07
worst relative error using     a*a*a*a*a*a: 2.58e-07

Sử dụng powthay cho cây nhân sẽ giảm lỗi bị ràng buộc bởi hệ số 4 . Trình biên dịch không nên (và nói chung là không) thực hiện "tối ưu hóa" làm tăng lỗi trừ khi người dùng được cấp phép làm như vậy (ví dụ: thông qua -ffast-math).

Lưu ý rằng GCC cung cấp __builtin_powi(x,n)như là một thay thế pow( ), sẽ tạo ra một cây nhân nội tuyến. Sử dụng nếu bạn muốn đánh đổi độ chính xác để thực hiện, nhưng không muốn kích hoạt tính toán nhanh.

Một trường hợp tương tự: hầu hết các trình biên dịch sẽ không tối ưu hóa a + b + c + dđể (a + b) + (c + d)(đây là một tối ưu hóa từ biểu thức thứ hai có thể được pipelined tốt hơn) và đánh giá nó như được đưa ra (ví dụ như (((a + b) + c) + d)). Điều này cũng là vì các trường hợp góc:

float a = 1e35, b = 1e-5, c = -1e35, d = 1e-5;
printf("%e %e\n", a + b + c + d, (a + b) + (c + d));

Đầu ra này 1.000000e-05 0.000000e+00

Fortran (được thiết kế cho máy tính khoa học) có một nhà điều hành năng lượng tích hợp và theo như tôi biết, trình biên dịch Fortran thường sẽ tối ưu hóa việc nâng lên các số nguyên theo cách tương tự như những gì bạn mô tả. Thật không may, C / C ++ không có toán tử nguồn, chỉ có chức năng thư viện pow(). Điều này không ngăn các trình biên dịch thông minh xử lý powđặc biệt và tính toán nó theo cách nhanh hơn cho các trường hợp đặc biệt, nhưng có vẻ như chúng làm điều đó ít phổ biến hơn ...

Vài năm trước tôi đã cố gắng làm cho nó thuận tiện hơn để tính toán các số nguyên theo cách tối ưu, và đã đưa ra những điều sau đây. Đó là C ++, không phải C, và vẫn phụ thuộc vào trình biên dịch có phần thông minh về cách tối ưu hóa / nội tuyến. Dù sao, hy vọng bạn có thể thấy nó hữu ích trong thực tế:

template<unsigned N> struct power_impl;

template<unsigned N> struct power_impl {
    template<typename T>
    static T calc(const T &x) {
        if (N%2 == 0)
            return power_impl<N/2>::calc(x*x);
        else if (N%3 == 0)
            return power_impl<N/3>::calc(x*x*x);
        return power_impl<N-1>::calc(x)*x;
    }
};

template<> struct power_impl<0> {
    template<typename T>
    static T calc(const T &) { return 1; }
};

template<unsigned N, typename T>
inline T power(const T &x) {
    return power_impl<N>::calc(x);
}

_{Làm rõ cho người tò mò: điều này không tìm ra cách tối ưu để tính toán sức mạnh, nhưng vì việc tìm ra giải pháp tối ưu là một vấn đề hoàn chỉnh NP và điều này chỉ đáng làm đối với các quyền lực nhỏ (trái ngược với việc sử dụng pow), không có lý do gì để làm phiền với các chi tiết.}

Sau đó chỉ cần sử dụng nó như power<6>(a).

Điều này giúp bạn dễ dàng nhập các quyền hạn (không cần phải đánh vần 6 agiây bằng parens) và cho phép bạn có loại tối ưu hóa này mà không cần -ffast-mathtrong trường hợp bạn có thứ gì đó phụ thuộc chính xác như tổng bù (một ví dụ trong đó thứ tự hoạt động là cần thiết) .

Có lẽ bạn cũng có thể quên rằng đây là C ++ và chỉ sử dụng nó trong chương trình C (nếu nó biên dịch với trình biên dịch C ++).

Hy vọng điều này có thể hữu ích.

BIÊN TẬP:

Đây là những gì tôi nhận được từ trình biên dịch của mình:

Đối với a*a*a*a*a*a,

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0

Đối với (a*a*a)*(a*a*a),

    movapd  %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm1, %xmm0
    mulsd   %xmm0, %xmm0

Đối với power<6>(a),

    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm0, %xmm1

GCC không thực sự tối ưu hóa a*a*a*a*a*ađể (a*a*a)*(a*a*a)khi a là một số nguyên. Tôi đã thử với lệnh này:

$ echo 'int f(int x) { return x*x*x*x*x*x; }' | gcc -o - -O2 -S -masm=intel -x c -

Có rất nhiều cờ gcc nhưng không có gì lạ mắt. Chúng có nghĩa là: Đọc từ stdin; sử dụng mức tối ưu hóa O2; danh sách ngôn ngữ lắp ráp đầu ra thay vì nhị phân; danh sách nên sử dụng cú pháp ngôn ngữ lắp ráp Intel; đầu vào bằng ngôn ngữ C (thông thường ngôn ngữ được suy ra từ phần mở rộng tệp đầu vào, nhưng không có phần mở rộng tệp khi đọc từ stdin); và viết vào thiết bị xuất chuẩn.

Đây là phần quan trọng của đầu ra. Tôi đã chú thích nó với một số ý kiến ​​cho biết những gì đang diễn ra trong ngôn ngữ lắp ráp:

; x is in edi to begin with.  eax will be used as a temporary register.
mov  eax, edi  ; temp = x
imul eax, edi  ; temp = x * temp
imul eax, edi  ; temp = x * temp
imul eax, eax  ; temp = temp * temp

Tôi đang sử dụng hệ thống GCC trên Linux Mint 16 Petra, một công cụ phái sinh Ubuntu. Đây là phiên bản gcc:

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

Như các áp phích khác đã lưu ý, tùy chọn này là không thể trong dấu phẩy động, bởi vì số học dấu phẩy động không liên quan.

Bởi vì số dấu phẩy động 32 bit - chẳng hạn như 1.024 - không phải là 1.024. Trong máy tính, 1.024 là một khoảng: từ (1.024-e) đến (1.024 + e), trong đó "e" biểu thị một lỗi. Một số người không nhận ra điều này và cũng tin rằng * trong một * là viết tắt của phép nhân các số chính xác tùy ý mà không có bất kỳ lỗi nào được gắn vào các số đó. Lý do tại sao một số người không nhận ra điều này có lẽ là các tính toán toán học mà họ đã thực hiện ở các trường tiểu học: chỉ làm việc với các số lý tưởng mà không có lỗi kèm theo và tin rằng chỉ cần bỏ qua "e" trong khi thực hiện phép nhân. Họ không thấy "e" ẩn trong "float a = 1.2", "a * a * a" và các mã C tương tự.

Nếu phần lớn các lập trình viên nhận ra (và có thể thực thi) ý tưởng rằng C biểu hiện a * a * a * a * a * a không thực sự hoạt động với các số lý tưởng, thì trình biên dịch GCC sẽ MIỄN PHÍ để tối ưu hóa "a * a * a * a * a * a "thành" t = (a * a); t * t * t "đòi hỏi số lượng nhân nhỏ hơn. Nhưng thật không may, trình biên dịch GCC không biết liệu lập trình viên viết mã có nghĩ rằng "a" là một số có hoặc không có lỗi hay không. Và do đó, GCC sẽ chỉ làm những gì mã nguồn trông như thế - bởi vì đó là những gì GCC nhìn thấy bằng "mắt thường".

... khi bạn biết những gì loại lập trình bạn đang có, bạn có thể sử dụng công tắc "-ffast-math" nói với GCC rằng "Hey, GCC, tôi biết những gì tôi đang làm!". Điều này sẽ cho phép GCC chuyển đổi một * a * a * a * a * a thành một đoạn văn bản khác - nó trông khác với một * a * a * a * a * a - nhưng vẫn tính một số trong khoảng lỗi a * a * a * a * a * a. Điều này là ổn, vì bạn đã biết bạn đang làm việc với các khoảng, không phải là con số lý tưởng.

Chưa có áp phích nào đề cập đến sự co lại của các biểu thức nổi (tiêu chuẩn ISO C, 6.5p8 và 7.12.2). Nếu FP_CONTRACTpragma được đặt thành ON, trình biên dịch được phép xem xét một biểu thức, chẳng hạn a*a*a*a*a*anhư một thao tác đơn lẻ, như thể được đánh giá chính xác với một làm tròn đơn. Chẳng hạn, một trình biên dịch có thể thay thế nó bằng một hàm năng lượng bên trong vừa nhanh hơn và chính xác hơn. Điều này đặc biệt thú vị vì hành vi được điều khiển một phần bởi lập trình viên trực tiếp trong mã nguồn, trong khi các tùy chọn trình biên dịch được cung cấp bởi người dùng cuối đôi khi có thể được sử dụng không chính xác.

Trạng thái mặc định của FP_CONTRACTpragma được xác định theo triển khai, do đó trình biên dịch được phép thực hiện các tối ưu hóa đó theo mặc định. Do đó, mã di động cần tuân thủ nghiêm ngặt các quy tắc của IEEE 754 nên được đặt rõ ràng thành mã OFF.

Nếu một trình biên dịch không hỗ trợ pragma này, thì nó phải thận trọng bằng cách tránh bất kỳ tối ưu hóa nào như vậy, trong trường hợp nhà phát triển đã chọn đặt nó OFF.

GCC không hỗ trợ pragma này, nhưng với các tùy chọn mặc định, nó giả định là như vậy ON; do đó, đối với các mục tiêu có FMA phần cứng, nếu muốn ngăn chặn chuyển đổi a*b+cthành fma (a, b, c), người ta cần cung cấp một tùy chọn như -ffp-contract=off(để đặt pragma thành OFF) hoặc -std=c99(để nói với GCC tuân thủ một số Phiên bản tiêu chuẩn C, ở đây là C99, do đó, theo đoạn văn trên). Trước đây, tùy chọn thứ hai không ngăn cản chuyển đổi, có nghĩa là GCC không tuân thủ điểm này: https://gcc.gnu.org/ormszilla/show_orms.cgi?id=37845

Như Lambdageek đã chỉ ra phép nhân float không liên quan và bạn có thể có độ chính xác thấp hơn, nhưng khi có độ chính xác tốt hơn, bạn có thể lập luận chống lại tối ưu hóa, vì bạn muốn có một ứng dụng xác định. Ví dụ: trong máy khách / máy chủ mô phỏng trò chơi, trong đó mọi máy khách phải mô phỏng cùng một thế giới mà bạn muốn tính toán dấu phẩy động có tính xác định.

Các chức năng thư viện như "pow" thường được chế tạo cẩn thận để mang lại sai số tối thiểu có thể (trong trường hợp chung). Điều này thường đạt được các hàm xấp xỉ bằng spline (theo nhận xét của Pascal, việc triển khai phổ biến nhất dường như là sử dụng thuật toán Remez )

về cơ bản các hoạt động sau đây:

pow(x,y);

có một lỗi cố hữu có độ lớn xấp xỉ bằng sai số trong bất kỳ phép nhân hoặc phép chia nào .

Trong khi các hoạt động sau đây:

float a=someValue;
float b=a*a*a*a*a*a;

có một lỗi cố hữu lớn hơn 5 lần lỗi của một phép nhân hoặc phép chia đơn (vì bạn đang kết hợp 5 phép nhân).

Trình biên dịch nên thực sự cẩn thận với loại tối ưu hóa mà nó đang thực hiện:

1. nếu tối ưu hóa pow(a,6)để a*a*a*a*a*anó có thể cải thiện hiệu suất, nhưng làm giảm đáng kể độ chính xác cho số dấu chấm động.
2. nếu tối ưu hóa a*a*a*a*a*a để pow(a,6)nó thực sự có thể làm giảm độ chính xác vì "a" là một số giá trị đặc biệt cho phép nhân mà không có lỗi (một sức mạnh của 2 hoặc một số số nguyên nhỏ)
3. nếu tối ưu hóa pow(a,6)đến (a*a*a)*(a*a*a)hoặc (a*a)*(a*a)*(a*a)vẫn có thể mất độ chính xác so với powchức năng.

Nói chung, bạn biết rằng đối với các giá trị dấu phẩy động tùy ý, "pow" có độ chính xác tốt hơn bất kỳ chức năng nào bạn có thể viết, nhưng trong một số trường hợp đặc biệt, phép nhân có thể có độ chính xác và hiệu suất tốt hơn, tùy thuộc vào nhà phát triển chọn cách nào phù hợp hơn, cuối cùng bình luận mã để không ai khác sẽ "tối ưu hóa" mã đó.

Điều duy nhất có ý nghĩa (ý kiến ​​cá nhân và rõ ràng là một lựa chọn trong GCC không có bất kỳ cờ tối ưu hóa hoặc trình biên dịch cụ thể nào) để tối ưu hóa nên thay thế "pow (a, 2)" bằng "a * a". Đó sẽ là điều duy nhất mà một nhà cung cấp trình biên dịch nên làm.

Tôi sẽ không mong đợi trường hợp này sẽ được tối ưu hóa cả. Không thể rất thường xuyên khi một biểu thức có chứa các biểu thức con có thể được nhóm lại để loại bỏ toàn bộ hoạt động. Tôi hy vọng các nhà văn trình biên dịch sẽ đầu tư thời gian của họ vào các lĩnh vực có nhiều khả năng dẫn đến các cải tiến đáng chú ý, thay vì bao gồm một trường hợp cạnh hiếm khi gặp phải.

Tôi đã rất ngạc nhiên khi biết được từ các câu trả lời khác rằng biểu thức này thực sự có thể được tối ưu hóa với các trình chuyển đổi trình biên dịch phù hợp. Tối ưu hóa là không đáng kể, hoặc đó là một trường hợp cạnh của tối ưu hóa phổ biến hơn nhiều, hoặc các trình soạn thảo trình biên dịch cực kỳ kỹ lưỡng.

Không có gì sai khi cung cấp gợi ý cho trình biên dịch như bạn đã làm ở đây. Đó là một phần bình thường và được mong đợi của quá trình tối ưu hóa vi mô để sắp xếp lại các tuyên bố và biểu thức để xem chúng sẽ mang lại sự khác biệt nào.

Mặc dù trình biên dịch có thể được chứng minh bằng cách xem xét hai biểu thức để cung cấp kết quả không nhất quán (không có các công tắc phù hợp), nhưng bạn không cần phải bị ràng buộc bởi hạn chế đó. Sự khác biệt sẽ cực kỳ nhỏ - đến mức nếu sự khác biệt quan trọng với bạn, bạn không nên sử dụng số học dấu phẩy động tiêu chuẩn ở vị trí đầu tiên.

Đã có một vài câu trả lời hay cho câu hỏi này, nhưng để hoàn thiện tôi muốn chỉ ra rằng phần áp dụng của tiêu chuẩn C là 5.1.2.2.3 / 15 (giống như mục 1.9 / 9 trong phần Tiêu chuẩn C ++ 11). Phần này nói rằng các nhà khai thác chỉ có thể được tập hợp lại nếu họ thực sự liên kết hoặc giao hoán.

gcc thực sự có thể thực hiện tối ưu hóa này, ngay cả đối với các số dấu phẩy động. Ví dụ,

double foo(double a) {
  return a*a*a*a*a*a;
}

trở thành

foo(double):
    mulsd   %xmm0, %xmm0
    movapd  %xmm0, %xmm1
    mulsd   %xmm0, %xmm1
    mulsd   %xmm1, %xmm0
    ret

với -O -funsafe-math-optimizations . Tuy nhiên, việc sắp xếp lại này vi phạm IEEE-754, do đó, nó yêu cầu cờ.

Các số nguyên đã ký, như Peter Cordes đã chỉ ra trong một nhận xét, có thể thực hiện tối ưu hóa này mà không cần -funsafe-math-optimizationsgiữ chính xác khi không có tràn và nếu có tràn bạn sẽ nhận được hành vi không xác định. Vì vậy, bạn nhận được

foo(long):
    movq    %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rdi, %rax
    imulq   %rax, %rax
    ret

chỉ với -O. Đối với các số nguyên không dấu, điều đó thậm chí còn dễ dàng hơn vì chúng hoạt động với quyền hạn mod 2 và do đó có thể được sắp xếp lại một cách tự do ngay cả khi đối mặt với tràn.