Các trình biên dịch Intel có thực sự tốt hơn các trình biên dịch của Microsoft không? [đóng cửa]

Nhiều năm trước, tôi đã rất ngạc nhiên khi phát hiện ra rằng Intel bán trình biên dịch tương thích Visual Studio. Tôi đã thử nó đặc biệt cho C / C ++ cũng như các công cụ chẩn đoán tuyệt vời. Nhưng mã đơn giản là không chuyên sâu về mặt tính toán để nhận thấy sự khác biệt. Ấn tượng duy nhất là: Intel đã thực sự làm điều đó cho tôi ngay bây giờ, wow, công cụ tuyệt vời với độ phân giải nano giây, không thể tin được. Nhưng thử nghiệm đã kết thúc và nhóm không bao giờ nghiêm túc xem xét việc mua hàng.

Từ kinh nghiệm của bạn, nếu chi phí giấy phép không thành vấn đề, nhà cung cấp nào là người chiến thắng?

Nó không phải là một câu hỏi rộng rãi hoặc mơ hồ hoặc suy nghĩ để châm ngòi cho một cuộc chiến thánh. Loại câu hỏi này là về hai công cụ rất dễ nhìn thấy. Không ai thích khi các công cụ có bất kỳ bí ẩn hoặc bất ngờ. Và lựa chọn giữa tốt nhất và tốt nhất luôn là nỗi đau. Tôi cũng hiểu cỏ luôn lập luận xanh hơn . Tôi muốn nghe tất cả các câu chuyện "what ifs".

Điều gì sẽ xảy ra nếu Intel chỉ tối ưu hóa cục bộ cho bước tiến của tháng và không phải mọi mục tiêu phần cứng sẽ thực sự hoạt động tốt như Microsoft biên soạn? Điều gì sẽ xảy ra nếu phần cứng AMD là mục tiêu và mọi thứ sẽ chậm lại mà không có lý do? Hoặc mặt khác, điều gì sẽ xảy ra nếu phần cứng của Intel có quá nhiều cơ hội không thể nhận ra, rằng các nhà văn trình biên dịch Microsoft quá chậm để chấp nhận và không bao giờ thực hiện nó trong trình biên dịch? Điều gì sẽ xảy ra nếu cả hai giống hệt nhau, thực sự là một cơ sở mã duy nhất chỉ được bọc vào hai hộp khác nhau và được cấp phép cho cả hai nhà cung cấp bởi một số cửa hàng bên thứ ba?

Và như vậy. Nhưng ai đó biết một số câu trả lời.

CẢNH BÁO: Trả lời dựa trên kinh nghiệm của bản thân - YMMV

Nếu mã thực sự đắt tiền, có, chắc chắn . Tôi đã thấy sự cải thiện hơn 20 lần với Trình biên dịch Intel C ++ trước đây (nay là Intel Studio nếu tôi nhớ lại chính xác) so với Trình biên dịch Microsoft Visual C ++ tiêu chuẩn. Đúng là mã rất xa hoàn hảo và có thể đã đóng một vai trò (thực ra đó là lý do tại sao chúng tôi bận tâm sử dụng trình biên dịch Intel, nó dễ dàng hơn việc tái cấu trúc cơ sở mã khổng lồ), CPU cũng được sử dụng để chạy mã là Intel Core 2 Quad, đó là CPU hoàn hảo cho một điều như vậy, nhưng kết quả đã gây sốc. Bản thân trình biên dịch chứa vô số cách để tối ưu hóa mã, bao gồm cả việc nhắm mục tiêu một CPU cụ thể về các khả năng của SSE . Nó thực sự làm -O2/ -O3chạy trốn xấu hổ. Và đó làtrước khi sử dụng hồ sơ.

Lưu ý rằng, tuy nhiên, bật tối ưu hóa thực sự tích cực sẽ khiến việc biên dịch mất khá nhiều thời gian, hai giờ cho một dự án lớn là không thể. Ngoài ra, với mức độ tối ưu hóa cao, khả năng xảy ra lỗi trong mã sẽ cao hơn (điều này cũng có thể được quan sát với gcc -O3). Đối với một dự án mà bạn biết rõ, đây có thể là một điểm cộng, vì bạn sẽ tìm và sửa bất kỳ lỗi nào mà bạn không mắc phải trước đó, nhưng khi biên dịch một mớ hỗn độn đầy lông, bạn chỉ cần bắt chéo ngón tay và cầu nguyện với các vị thần x86.

Một cái gì đó về hiệu suất trên máy AMD: Đó là không tốt như CPU Intel, nhưng nó vẫn còn cách tốt hơn so với MS C ++ biên dịch (một lần nữa, từ kinh nghiệm của tôi). Lý do là bạn cũng có thể nhắm mục tiêu một CPU chung có hỗ trợ SSE2 (ví dụ). Sau đó, CPU AMD với SSE2 sẽ không bị phân biệt đối xử nhiều. Mặc dù vậy, trình biên dịch Intel trên CPU Intel thực sự ăn cắp chương trình. Tuy nhiên, đó không phải là tất cả cầu vồng đôi và kỳ lân sáng bóng. Đã có một số cáo buộc nặng nề về việc nhị phân không chạy hoàn toàn trên các CPU không phải là chính hãng và điều này được thừa nhận một cách giả tạo về hiệu năng kém hơn trên CPU bởi các nhà cung cấp khác. Cũng lưu ý rằng đây là thông tin từ ít nhất 3 năm trước và hiện tại vẫn chưa rõ tính hợp lệ, NHƯNG các mô tả sản phẩm mới cung cấp cho các nhị phân một chuỗi carte để chạy chậm như Intel thấy phù hợp với CPU không phải của Intel.

Tôi không biết Intel nói gì và tại sao họ tạo ra các công cụ tính toán số tốt như vậy, nhưng cũng hãy xem điều này: http://julialang.org/ . Có một so sánh và nếu bạn nhìn vào hàng cuối cùng, MATLAB tỏa sáng bằng cách đánh bại cả mã C và Julia , điều khiến tôi ngạc nhiên là các tác giả nghĩ rằng lý do là Thư viện hạt nhân toán học của Intel .

Tôi nhận ra điều này nghe có vẻ giống như một quảng cáo cho bộ công cụ Intel Compiler, nhưng theo kinh nghiệm của tôi, nó thực sự đã làm rất tốt, và thậm chí logic đơn giản chỉ ra rằng những kẻ tạo ra CPU nên biết cách lập trình tốt nhất cho chúng. IMO, trình biên dịch Intel C ++ siết chặt mọi mức tăng hiệu suất cuối cùng có thể.

Intel Compiler có tiếng là sản xuất mã số rất hiệu quả:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_Vvisited/

Xin lưu ý rằng tôi không cho rằng đó là trình biên dịch nhanh nhất ngoài đó, nhưng chắc chắn nó rất nổi tiếng về hiệu quả. Lưu ý rằng các tác giả của các nhị phân LAPACK "chính thức" cho Windows sử dụng trình biên dịch Intel Fortran để xây dựng chúng: http://icl.cs.utk.edu/lapack-for-windows/ và họ nên biết một hoặc hai điều về hiệu quả.

Intel C ++ có một vài lợi thế so với gcc ngoài trình tạo mã. Cả hai đều xuất phát (phần lớn) từ thực tế là nó dựa trên giao diện EDG . Dù tốt hay xấu, cả hai đều bị xói mòn (từ từ), vì vậy những lợi thế không còn lớn như trước đây.

Đầu tiên là nó phát hành các thông báo lỗi tốt hơn nhiều như một quy tắc. Bạn có thể muốn xem xét so sánh các thông báo lỗi giữa Clang và gcc. Intel C ++ (cùng với hầu hết các thiết bị khác dựa trên giao diện EDG) đã đưa ra chẩn đoán tương tự như Clang trong nhiều năm.

Thứ hai, là giao diện người dùng EDG nổi tiếng về sự phù hợp ngôn ngữ đặc biệt tốt vì trình tạo mã Intel là để sản xuất mã nhanh. Bằng hầu hết mọi biện pháp hợp lý, giao diện người dùng EDG cung cấp sự phù hợp tốt hơn với C ++ 98, 03 hoặc (trong các phiên bản hiện tại) C ++ 0x so với bất kỳ trình biên dịch nào khác hiện có.

Như tôi đã nói, cả hai lợi thế này đã bị xói mòn ở các mức độ khác nhau theo thời gian. Các phiên bản gần đây của gcc có sự phù hợp ngôn ngữ khá tốt. Clang có các thông báo lỗi tốt hơn đáng kể và cũng đang tiến triển tốt trong việc thực hiện toàn bộ ngôn ngữ C ++. Tuy nhiên, khi bạn đi thẳng vào nó, Intel C ++ vẫn tốt hơn cả về cả hai và đó là một gói duy nhất thực hiện đúng mọi thứ thay vì cần một trình biên dịch để chẩn đoán tốt và một trình biên dịch khác để tạo sự phù hợp và tạo mã tốt hơn.

Chúng tôi đã thử điều này tại nơi làm việc một thời gian trở lại. Hầu hết các cơ sở mã của chúng tôi đều ở Delphi, nhưng chúng tôi đã có một số chức năng chuyên sâu tính toán mà ai đó nghĩ sẽ là một ý tưởng tốt để thực hiện theo cách của C ++ DLL khi nào. Và một trong những đồng nghiệp của tôi đã nghe những điều tuyệt vời về trình biên dịch Intel, vì vậy anh ấy đã quyết định dùng thử. Chúng tôi đã xây dựng lại DLL trong trình biên dịch Intel và thực hiện một số bài kiểm tra tốc độ, và kết quả đã làm anh ấy ngạc nhiên đến mức anh ấy nghĩ rằng anh ấy phải làm gì đó sai.

DLL phải tính toán một số vấn đề rất khó khăn với các thành phần tổ hợp và cấu trúc liên kết, về mặt kỹ thuật thuộc lớp độ khó NP-hard nếu chúng tôi thực hiện chúng "đúng", nhưng chúng tôi sử dụng các phương pháp phỏng đoán khác nhau để tránh hiệu suất NP. Mặc dù vậy, có rất nhiều khủng hoảng đang diễn ra. Và đối với các thử nghiệm chúng tôi đã chạy, sự khác biệt giữa trình biên dịch VS và trình biên dịch Intel là trong epsilon hoặc trình biên dịch Intel chậm hơn đáng kể, thường là ở đâu đó trong khoảng 20%. Và nó vẫn như vậy cho dù anh ta có thay đổi gì về cài đặt biên dịch để cố gắng để trình biên dịch Intel tạo mã nhanh hơn. Vì vậy, chúng tôi đã kết thúc không chuyển sang nó.

Tất nhiên đây chỉ là một ví dụ trong thế giới thực. Số dặm của bạn có thể thay đổi.

Trong một ứng dụng nhúng mà tôi từng làm việc, một thử nghiệm trình biên dịch Intel cho thấy nó sẽ giúp chúng tôi tiết kiệm được phần cứng mới với hiệu suất cao hơn. Chi phí cho phần cứng mới là khoảng $ 10 / đơn vị, doanh số dự kiến ​​là 1 triệu đơn vị, Thêm chi phí phát triển và sự chậm trễ của dự án. Tùy chọn 2 là một hồ sơ / vi tối ưu hóa một cơ sở mã được cấu hình / tối ưu hóa hợp lý - kết quả không xác định, thời gian không xác định.

Bạn nghĩ ông chủ nói gì khi chúng tôi yêu cầu tiền để mua trình biên dịch .......

Tuy nhiên - đây là trường hợp cạnh rất may mắn và hiếm hơn - đầu ra mã nhanh hơn 10% từ trình biên dịch Intel đã đẩy chúng tôi trở lại mặt chính xác của hiệu suất. Nếu chúng tôi đã ở bên phải, hoặc hơn 10%, điều đó sẽ không tạo ra sự khác biệt. Nếu chúng ta có các kỹ sư, có lẽ chúng ta có thể đã tối ưu hóa mã và lưu phần cứng phần cứng và không cần trình biên dịch Intel, nhưng rủi ro là rất cao và trình biên dịch Intel hoạt động rẻ hơn thời gian kỹ thuật.

Về sự cân bằng tôi sẽ nói đó là một hình thức tối ưu hóa vi mô - đừng làm điều đó cho đến khi bạn biết bạn cần, và sau đó, chỉ sau khi bạn đã tìm hiểu và tìm ra nguyên nhân thực sự của các vấn đề. Đây là một lựa chọn đặc biệt tốt trong hồ sơ của bạn cho thấy bạn chậm 'ở mọi nơi' và không có cổ chai được xác định.

Tôi chỉ gặp ba lợi thế:

1. Nó có hỗ trợ cho các tính năng của CPU Intel mới hơn sớm hơn nhiều so với các trình biên dịch khác.

2. Đây là một trình biên dịch bổ sung tuyệt vời để đưa ra các cảnh báo và nắm bắt các vấn đề mà các trình biên dịch khác bỏ lỡ. GCC nắm bắt được một số điều ICC không có, và ngược lại. Visual studio nắm bắt được một số thứ ICC không có, và ngược lại.

3. Nó thực hiện công việc tự động song song các vòng lặp (phân phối chúng trên nhiều luồng tự động) tốt hơn bất kỳ trình biên dịch nào khác. Không có nhiều lợi ích mã từ điều này, nhưng khi bạn có mã đó, nó có thể tạo ra một sự khác biệt.

Chúng tôi sử dụng trình biên dịch intel cho mọi dự án phê bình hiệu năng của cơ sở mã của chúng tôi. Điều tuyệt vời về nó là, nó làm cho việc tối ưu hóa mã thực sự có thể duy trì được. Thay vì thêm thủ công các cuộc gọi __mm ở mọi nơi và yêu cầu trình biên dịch tìm nạp dữ liệu, tất cả chúng sẽ được tối ưu lại trong bản phát hành tiếp theo, bạn chỉ cần sắp xếp lại một số mã của mình và tăng tốc độ điên cuồng.

Thông thường, mã được tối ưu hóa dễ theo dõi hơn tay được tối ưu hóa, nó nhanh hơn mã được tối ưu hóa bằng tay và khi một tập lệnh mới được phát hành, trình biên dịch sẽ sử dụng tập lệnh đó. Thật tuyệt vơi.

Điều tương tự cũng xảy ra với trình biên dịch arm (từ arm, không phải intel), nếu bạn phát hành trên arm, sẽ thực hiện một công việc tuyệt vời trong việc vector hóa cho bạn.

Kiểm tra trang điểm chuẩn này. Tóm lại, intel thắng.

Nhưng biên độ có thể không lớn: nếu bạn biên dịch thành 32 bit và hệ thống xây dựng của bạn không thể tối ưu hóa hồ sơ hướng dẫn hồ sơ, mức tăng là 10%. Là một cải tiến như vậy có giá trị rắc rối và thời gian biên dịch lâu hơn?

Người ta nói rằng Intel đã phát hành Intel C ++ Compiler v13.0 cho HĐH Android, nỗ lực đầu tiên của họ trong việc cung cấp trình biên dịch C / C ++ tối ưu hóa được thiết kế dành riêng cho nền tảng di động của Google.

Các nhà phát triển có thể sử dụng trình biên dịch trên các hệ thống dựa trên Linux * để tạo ứng dụng cho thiết bị Android dựa trên bộ xử lý Intel, bao gồm bộ xử lý Intel® Atom ™. Trình biên dịch Intel tương thích với GNU C ++ và các công cụ dành cho nhà phát triển trong Bộ công cụ phát triển bản địa Android (NDK) Bạn cũng không thể sử dụng trình biên dịch trên bất kỳ máy phát triển nào. Cả Windows và OS X đều không được hỗ trợ; các công cụ chỉ được chứng nhận để sử dụng với Ubuntu 10.04 hoặc 11.04

Phiên bản hiện tại của Android NDK sử dụng phiên bản 4.6 của chuỗi công cụ Gnu Compiler Collection (GCC) mã nguồn mở theo mặc định. Nhưng các trình biên dịch của Intel bao gồm rất nhiều tối ưu hóa độc quyền cho các chip của riêng nó và thường có thể xuất mã thực thi hoạt động tốt hơn so với các trình biên dịch do bên thứ ba tạo ra như GCC.