Dưới đây là một số phát hiện cập nhật mặc dù phát hiện hẹp của tôi với GCC 4.7.2 và Clang 3.2 cho C ++.
CẬP NHẬT: So sánh GCC 4.8.1 v clang 3.3 dưới đây.
CẬP NHẬT: So sánh GCC 4.8.2 v clang 3.4 được thêm vào đó.
Tôi duy trì một công cụ OSS được xây dựng cho Linux với cả GCC và Clang và với trình biên dịch của Microsoft cho Windows. Công cụ, coan, là một bộ tiền xử lý và phân tích các tệp nguồn C / C ++ và các bộ mã như vậy: chuyên ngành hồ sơ tính toán của nó về phân tích cú pháp gốc đệ quy và xử lý tệp. Chi nhánh phát triển (mà các kết quả này liên quan) hiện tại bao gồm khoảng 11K LỘC trong khoảng 90 tệp. Hiện tại, nó được mã hóa trong C ++, có tính đa hình và khuôn mẫu phong phú, nhưng vẫn bị sa lầy trong nhiều bản vá bởi quá khứ không quá xa vời của nó trong C. ngữ nghĩa di chuyển không được khai thác rõ ràng. Nó là đơn luồng. Tôi đã không dành nỗ lực nghiêm túc nào để tối ưu hóa nó, trong khi "kiến trúc" vẫn chủ yếu là ToDo.
Tôi đã sử dụng Clang trước 3.2 chỉ như một trình biên dịch thử nghiệm bởi vì, mặc dù tốc độ biên dịch và chẩn đoán vượt trội, nhưng hỗ trợ tiêu chuẩn C ++ 11 của nó đã làm chậm phiên bản GCC đương đại trong các khía cạnh được thực hiện bởi coan. Với 3,2, khoảng cách này đã được đóng lại.
Khai thác kiểm tra Linux của tôi cho quá trình phát triển coan hiện tại xử lý khoảng 70K tệp nguồn trong hỗn hợp các trường hợp kiểm thử trình phân tích cú pháp một tệp, kiểm tra căng thẳng tiêu thụ 1000 tệp và kiểm tra kịch bản tiêu thụ tệp <1K. Cũng như báo cáo kết quả kiểm tra, khai thác tích lũy và hiển thị tổng số tệp được tiêu thụ và thời gian chạy tiêu thụ trong coan (nó chỉ chuyển từng dòng lệnh coan cho lệnh Linux timevà thu thập và cộng các số được báo cáo). Thời gian được tâng bốc bởi thực tế là bất kỳ số lượng thử nghiệm nào mất 0 thời gian có thể đo được đều sẽ cộng với 0, nhưng sự đóng góp của các thử nghiệm đó là không đáng kể. Các thống kê thời gian được hiển thị ở cuối make checknhư thế này:
coan_test_timer: info: coan processed 70844 input_files.
coan_test_timer: info: run time in coan: 16.4 secs.
coan_test_timer: info: Average processing time per input file: 0.000231 secs.
Tôi đã so sánh hiệu suất khai thác thử nghiệm giữa GCC 4.7.2 và Clang 3.2, tất cả mọi thứ đều bằng nhau ngoại trừ các trình biên dịch. Kể từ Clang 3.2, tôi không còn yêu cầu bất kỳ sự khác biệt tiền xử lý nào giữa các vùng mã mà GCC sẽ biên dịch và các lựa chọn thay thế Clang. Tôi đã xây dựng cùng một thư viện C ++ (GCC) trong từng trường hợp và chạy tất cả các phép so sánh liên tiếp trong cùng một phiên cuối.
Mức tối ưu hóa mặc định cho bản phát hành của tôi là -O2. Tôi cũng đã thử nghiệm thành công các bản dựng tại -O3. Tôi đã thử nghiệm mỗi cấu hình 3 lần back-to-back và tính trung bình 3 kết quả, với các kết quả sau. Số trong một ô dữ liệu là số micrô giây trung bình được sử dụng bởi coan thực thi để xử lý mỗi tệp ~ 70K (đọc, phân tích và ghi đầu ra và chẩn đoán).
| -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.7.2 | 231 | 237 |0.97 |
----------|-----|-----|-----|
Clang-3.2 | 234 | 186 |1.25 |
----------|-----|-----|------
GCC/Clang |0.99 | 1.27|
Bất kỳ ứng dụng cụ thể nào cũng rất có thể có những đặc điểm không phù hợp với điểm mạnh hoặc điểm yếu của nhà soạn nhạc. Điểm chuẩn nghiêm ngặt sử dụng các ứng dụng đa dạng. Với ý nghĩ đó, các tính năng đáng chú ý của các dữ liệu này là:
- Tối ưu hóa -3 đã gây bất lợi cho GCC
- Tối ưu hóa -O3 rất quan trọng đối với Clang
- Ở mức tối ưu hóa -O2, GCC nhanh hơn Clang chỉ bằng một cái râu
- Ở mức tối ưu hóa -O3, Clang quan trọng nhanh hơn GCC.
Một so sánh thú vị hơn nữa của hai trình biên dịch đã xuất hiện một cách tình cờ ngay sau những phát hiện đó. Coan tự do sử dụng các con trỏ thông minh và một trong số đó được thực hiện rất nhiều trong việc xử lý tệp. Loại con trỏ thông minh đặc biệt này đã được nhập vào các bản phát hành trước vì mục đích phân biệt trình biên dịch, là một std::unique_ptr<X>trình biên dịch được cấu hình có đủ hỗ trợ cho việc sử dụng nó, và ngược lại std::shared_ptr<X>. Sự thiên vị std::unique_ptrlà ngu ngốc, vì những con trỏ này trên thực tế đã được chuyển đi, nhưng std::unique_ptrtrông giống như tùy chọn fitter để thay thế
std::auto_ptrtại một thời điểm khi các biến thể C ++ 11 là tiểu thuyết đối với tôi.
Trong quá trình xây dựng thử nghiệm để đánh giá nhu cầu tiếp tục của Clang 3.2 về sự khác biệt tương tự này, tôi đã vô tình xây dựng
std::shared_ptr<X>khi tôi có ý định xây dựng std::unique_ptr<X>và rất ngạc nhiên khi thấy rằng kết quả thực thi, với tối ưu hóa -O2 mặc định, là nhanh nhất đã thấy, đôi khi đạt được 184 msecs. mỗi tệp đầu vào. Với một thay đổi đối với mã nguồn, kết quả tương ứng là những kết quả này;
| -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.7.2 | 234 | 234 |1.00 |
----------|-----|-----|-----|
Clang-3.2 | 188 | 187 |1.00 |
----------|-----|-----|------
GCC/Clang |1.24 |1.25 |
Những điểm cần lưu ý ở đây là:
- Cả trình biên dịch hiện không có lợi ích gì từ tối ưu hóa -O3.
- Clang đánh bại GCC cũng quan trọng ở mỗi cấp độ tối ưu hóa.
- Hiệu suất của GCC chỉ bị ảnh hưởng nhẹ bởi thay đổi loại con trỏ thông minh.
- Hiệu suất -O2 của Clang bị ảnh hưởng quan trọng bởi sự thay đổi loại con trỏ thông minh.
Trước và sau khi thay đổi loại con trỏ thông minh, Clang có thể xây dựng một coan nhanh hơn đáng kể ở mức tối ưu hóa -O3 và nó có thể xây dựng một thực thi nhanh hơn bằng nhau ở -O2 và -O3 khi loại con trỏ đó là loại tốt nhất - std::shared_ptr<X>- cho công việc.
Một câu hỏi rõ ràng mà tôi không đủ thẩm quyền để nhận xét là tại sao
Clang có thể tìm thấy tốc độ tăng 25% -O2 trong ứng dụng của tôi khi loại con trỏ thông minh được sử dụng nhiều được thay đổi từ duy nhất sang chia sẻ, trong khi GCC không quan tâm để cùng thay đổi. Tôi cũng không biết mình nên cổ vũ hay la ó khi phát hiện ra rằng tối ưu hóa -O2 của Clang có độ nhạy lớn như vậy đối với sự khôn ngoan trong các lựa chọn con trỏ thông minh của tôi.
CẬP NHẬT: GCC 4.8.1 v clang 3.3
Các kết quả tương ứng bây giờ là:
| -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.1 | 442 | 443 |1.00 |
----------|-----|-----|-----|
Clang-3.3 | 374 | 370 |1.01 |
----------|-----|-----|------
GCC/Clang |1.18 |1.20 |
Thực tế là tất cả bốn tệp thực thi hiện nay đều mất thời gian trung bình lớn hơn nhiều so với trước đây để xử lý tệp 1 không phản ánh về hiệu suất của trình biên dịch mới nhất. Đó là do thực tế là nhánh phát triển sau này của ứng dụng thử nghiệm đã có rất nhiều phân tích tinh vi trong thời gian đó và trả tiền cho nó theo tốc độ. Chỉ có các tỷ lệ là đáng kể.
Các điểm lưu ý bây giờ không phải là tiểu thuyết bắt mắt:
- GCC không quan tâm đến tối ưu hóa -O3
- clang được hưởng lợi rất ít từ tối ưu hóa -O3
- clang đánh bại GCC bởi một biên độ quan trọng tương tự ở mỗi cấp độ tối ưu hóa.
So sánh các kết quả này với các kết quả cho GCC 4.7.2 và clang 3.2, điều nổi bật là GCC đã lấy lại khoảng một phần tư số clang dẫn đầu ở mỗi cấp độ tối ưu hóa. Nhưng vì ứng dụng thử nghiệm đã được phát triển rất nhiều trong khi đó, người ta không thể tự tin gán cái này cho một sự bắt kịp trong việc tạo mã của GCC. (Lần này, tôi đã lưu ý ảnh chụp nhanh ứng dụng mà từ đó thời gian thu được và có thể sử dụng lại.)
CẬP NHẬT: GCC 4.8.2 v clang 3.4
Tôi đã hoàn thành bản cập nhật cho GCC 4.8.1 v Clang 3.3 nói rằng tôi sẽ sử dụng cùng một snaphot coan để cập nhật thêm. Nhưng thay vào đó, tôi quyết định thử nghiệm trên ảnh chụp nhanh đó (sửa đổi 301) và trên ảnh chụp nhanh phát triển mới nhất, tôi đã vượt qua bộ thử nghiệm của nó (sửa đổi 619). Điều này mang lại cho kết quả một chút kinh độ và tôi có một động lực khác:
Bài đăng ban đầu của tôi lưu ý rằng tôi đã không dành nỗ lực để tối ưu hóa coan cho tốc độ. Đây vẫn là trường hợp của rev. 301. Tuy nhiên, sau khi tôi đã xây dựng bộ máy thời gian vào khai thác thử nghiệm coan, mỗi lần tôi chạy bộ thử nghiệm, tác động hiệu suất của những thay đổi mới nhất khiến tôi phải đối mặt. Tôi thấy rằng nó thường lớn một cách đáng ngạc nhiên và xu hướng tiêu cực hơn nhiều so với tôi cảm thấy được khen ngợi bởi sự tăng cường trong chức năng.
Bằng cách sửa đổi 308 thời gian xử lý trung bình cho mỗi tệp đầu vào trong bộ kiểm tra đã tăng hơn gấp đôi kể từ lần đăng đầu tiên ở đây. Vào thời điểm đó, tôi đã thực hiện chính sách 10 năm không bận tâm về hiệu suất. Trong một loạt các sửa đổi, hiệu suất lên tới 619 luôn luôn được xem xét và một số lượng lớn trong số đó đã hoàn toàn viết lại các phần tử tải trọng chính trên các dòng nhanh hơn về cơ bản (mặc dù không sử dụng bất kỳ tính năng biên dịch không chuẩn nào để làm như vậy). Thật thú vị khi thấy phản ứng của mỗi nhà soạn nhạc đối với lần lượt này,
Dưới đây là ma trận thời gian quen thuộc hiện tại cho các bản dựng mới nhất của trình biên dịch rev.301:
coan - rev.301 kết quả
| -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.2 | 428 | 428 |1.00 |
----------|-----|-----|-----|
Clang-3.4 | 390 | 365 |1.07 |
----------|-----|-----|------
GCC/Clang | 1.1 | 1.17|
Câu chuyện ở đây chỉ được thay đổi một chút từ GCC-4.8.1 và Clang-3.3. Hiển thị của GCC là một trifle tốt hơn. Clang's là một trifle tồi tệ hơn. Tiếng ồn cũng có thể giải thích cho điều này. Clang vẫn đi trước -O2và -O3lợi nhuận không quan trọng trong hầu hết các ứng dụng nhưng sẽ khá quan trọng đối với một số ít.
Và đây là ma trận cho rev. 619.
coan - rev.619 kết quả
| -O2 | -O3 |O2/O3|
----------|-----|-----|-----|
GCC-4.8.2 | 210 | 208 |1.01 |
----------|-----|-----|-----|
Clang-3.4 | 252 | 250 |1.01 |
----------|-----|-----|------
GCC/Clang |0.83 | 0.83|
Lấy số liệu 301 và 619 cạnh nhau, một số điểm lên tiếng.
Tôi đã nhắm đến việc viết mã nhanh hơn và cả hai trình biên dịch đều minh chứng rõ ràng cho những nỗ lực của tôi. Nhưng:
GCC hoàn trả những nỗ lực đó một cách hào phóng hơn Clang. Tại -O2
tối ưu hóa Clang của 619 xây dựng là 46% nhanh hơn so với 301 build của nó: tại -O3cải thiện Clang là 31%. Tốt, nhưng ở mỗi cấp độ tối ưu hóa, bản dựng 619 của GCC nhanh hơn gấp đôi so với 301.
GCC nhiều hơn đảo ngược ưu thế trước đây của Clang. Và ở mỗi cấp độ tối ưu hóa, GCC hiện đánh bại Clang 17%.
Khả năng của Clang trong bản dựng 301 để có được nhiều đòn bẩy hơn GCC từ -O3tối ưu hóa đã biến mất trong bản dựng 619. Cả trình biên dịch đều tăng một cách có ý nghĩa từ -O3.
Tôi đã rất ngạc nhiên bởi sự đảo ngược của vận may này mà tôi nghi ngờ rằng tôi có thể đã vô tình tạo ra một bản dựng chậm chạp của bản thân 3,4 (vì tôi đã xây dựng nó từ nguồn). Vì vậy, tôi đã chạy lại thử nghiệm 619 với cổ phiếu của bản phân phối Clang 3.3. Kết quả thực tế giống như trong 3,4.
Vì vậy, liên quan đến phản ứng với lượt về: Về các con số ở đây, Clang đã làm tốt hơn nhiều so với GCC ở tốc độ vắt ra khỏi mã C ++ của tôi khi tôi không giúp đỡ. Khi tôi dồn hết tâm trí để giúp đỡ, GCC đã làm một công việc tốt hơn Clang rất nhiều.
Tôi không nâng quan sát đó thành một nguyên tắc, nhưng tôi rút ra bài học rằng "Trình biên dịch nào tạo ra các nhị phân tốt hơn?" là một câu hỏi mà ngay cả khi bạn chỉ định bộ kiểm tra mà câu trả lời sẽ là tương đối, thì đó vẫn không phải là vấn đề rõ ràng về việc chỉ định thời gian cho các nhị phân.
Là nhị phân tốt hơn của bạn là nhị phân nhanh nhất, hay nó là mã bù tốt nhất cho mã được chế tạo rẻ tiền? Hoặc bù đắp tốt nhất cho tốn kém
đang crafted rằng ưu tiên bảo trì và tái sử dụng hơn tốc độ? Nó phụ thuộc vào bản chất và trọng lượng tương đối của động cơ của bạn để tạo ra nhị phân và các ràng buộc mà bạn làm như vậy.
Và trong mọi trường hợp, nếu bạn quan tâm sâu sắc đến việc xây dựng các nhị phân "tốt nhất" thì tốt hơn hết bạn nên kiểm tra xem các trình biên dịch liên tiếp cung cấp như thế nào về ý tưởng "tốt nhất" của bạn qua các lần lặp liên tiếp của mã.