인텔 컴파일러는 Microsoft 컴파일러보다 정말 낫습니까? [닫은]

몇 년 전 인텔이 Visual Studio 호환 컴파일러를 판매한다는 사실을 알게되었을 때 놀랐습니다. 환상적인 진단 도구뿐만 아니라 특히 C / C ++에서 시도했습니다. 그러나 코드는 그 차이를 알아 차리기 위해 계산 집약적이지 않았습니다. 유일한 인상은 : 인텔이 지금 당장 나를 위해 해냈 는가, 나노초 해상도의 놀라운 툴, 믿을 수 없을 정도. 그러나 재판이 끝나고 팀은 구매를 진지하게 고려하지 않았습니다.

경험상 라이센스 비용이 중요하지 않은 경우 어떤 공급 업체가 승자입니까?

거룩한 전쟁을 일으키는 것은 광범위하거나 모호한 질문이나 시도가 아닙니다. 이런 종류의 질문은 두 가지 매우 가시적 인 도구에 관한 것입니다. 도구에 미스터리 나 놀라움이있을 때는 아무도 좋아하지 않습니다. 최고와 최고 사이의 선택은 항상 고통입니다. 나는 또한 잔디가 항상 녹색 논쟁 이라는 것을 이해 합니다 . 모든 "만약"이야기를 듣고 싶습니다.

인텔이 이달의 칩 스테핑에 맞게 로컬로 최적화 한 경우, 모든 하드웨어 대상이 실제로 Microsoft가 컴파일 한 것처럼 작동하지는 않습니까? AMD 하드웨어가 대상이고 아무런 이유없이 모든 것이 느려지면 어떻게합니까? 또는 인텔 하드웨어에 눈에 띄지 않는 기회가 많으면 Microsoft 컴파일러 작성자가 너무 느리게 채택하여 컴파일러에서 구현하지 않을 수 있습니까? 둘 다 정확히 동일하고 실제로 하나의 코드베이스가 두 개의 다른 상자에 싸여서 일부 공급 업체에 의해 두 공급 업체 모두에게 라이센스를 부여한 경우 어떻게해야합니까?

등등. 그러나 누군가 대답을 알고 있습니다.

경고 : 자신의 경험을 바탕으로 답변-YMMV

코드가 실제로 계산 비용이 많이 든다면 그렇습니다 . 이전의 Intel C ++ Compiler (현재 올바르게 호출하면 Intel Studio)와 표준 Microsoft Visual C ++ Compiler를 사용하여 20 배 이상 향상되었습니다 . 코드가 완벽하지는 않았으며 그 역할을 수행했을 수도 있습니다 (실제로 인텔 컴파일러를 사용하여 귀찮은 이유, 거대한 코드베이스를 리팩터링하는 것보다 쉬웠습니다). 또한 코드를 실행하는 데 사용 된 CPU는 인텔 코어 2였습니다. 쿼드는 그런 것들에 완벽한 CPU이지만 결과는 충격적이었습니다. 컴파일러 자체에는 SSE 기능 과 같은 특정 CPU를 대상으로하는 등 코드를 최적화하는 다양한 방법이 포함되어 있습니다. 정말 수 -O2/이 -O3떨어져 부끄러워 실행합니다. 그리고 그것은프로파일 러 를 사용 하기 전에

그러나 매우 공격적인 최적화를 설정하면 컴파일에 시간이 오래 걸리고, 큰 프로젝트의 경우 2 시간이 전혀 불가능하지는 않습니다. 또한 높은 수준의 최적화를 사용하면 코드에서 오류가 발생할 가능성이 높아집니다 (gcc에서도 확인할 수 있음 -O3). 잘 아는 프로젝트에는 이전에 발견하지 못한 결과적인 버그를 찾아서 수정할 수 있기 때문에 더할 나위가 있습니다. 그러나 털이 난장판을 컴파일 할 때는 손가락을 건너 x86 신들에게기도하십시오.

AMD 시스템에서 성능에 대한 뭔가 : 그것은 인텔의 CPU만큼 좋지 않아,하지만 아직 방법 (내 경험에서, 다시)를 MS C ++ 컴파일러보다. 그 이유는 SSE2를 지원 하는 일반 CPU를 대상으로 할 수도 있기 때문입니다 (예 :) . 그러면 SSE2가 장착 된 AMD CPU는 많이 식별되지 않습니다. 인텔 CPU의 인텔 컴파일러는 실제로 쇼를 훔칩니다. 그러나 모두 이중 무지개와 반짝이는 유니콘은 아닙니다. 비 GenuineIntel CPU에서 바이너리가 전혀 실행되지 않고 다른 벤더가 CPU 에서 인위적으로 열등한 성능을 발휘 한 바이너리에 대해 약간의 비난이있었습니다.. 또한이 정보는 적어도 3 년 전의 정보이며 현재로서는 유효하지 않지만 새로운 제품 설명은 인텔이 인텔 이외의 CPU에 적합하다고 생각하는 이진 파일을 느리게 실행할 수 있도록합니다.

나는 그것이 인텔에 대해 무엇인지, 왜 그렇게 좋은 숫자 계산 도구를 만드는지 알지 못하지만 이것도 살펴보십시오 : http://julialang.org/ . 비교가 있고 마지막 행을 보면 MATLAB 은 C 코드와 Julia 를 물리 치고 빛을 발합니다. 저에게 놀라운 것은 저자가 이유를 인텔의 수학 커널 라이브러리 라고 생각한다는 것 입니다.

나는 이것이 인텔 컴파일러 툴킷에 대한 광고처럼 들리지만, 내 경험상 실제로 잘 작동했으며 심지어 간단한 논리조차도 CPU를 만드는 사람들이 프로그래밍하는 방법을 가장 잘 알고 있어야한다고 지시합니다. Intel C ++ 컴파일러 인 IMO는 가능한 모든 마지막 성능 향상을 압박합니다.

인텔 컴파일러는 매우 효율적인 숫자 코드를 생성하는 것으로 유명합니다.

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_revisited/

나는 그것을 주장하지 않는 것이 있습니다 입니다 거기에 가장 빠른 컴파일러,하지만 확실히 효율을위한 매우 좋은 평판을 누리고 있습니다. Windows 용 "공식적인"LAPACK 바이너리의 저자를 구축하기 위해 인텔 포트란 컴파일러를 사용합니다 http://icl.cs.utk.edu/lapack-for-windows/을 그들이 일 또는 효율성에 대한 두 가지를 알아야한다.

인텔 C ++에는 코드 생성기 외에 gcc보다 몇 가지 장점이 있습니다. 이 두 가지 모두 EDG 프론트 엔드를 기반으로한다는 사실에서 비롯 됩니다. 더 좋든 나쁘 든, 두 가지 모두 (느리게) 침식되므로 장점은 이전처럼 크지 않습니다.

첫 번째는 더 나은 오류 메시지를 규칙적으로 발행한다는 것입니다. Clang과 gcc 사이의 오류 메시지를 비교할 수 있습니다 . 인텔 C ++ (EDG 프론트 엔드 기반의 다른 대부분과 함께)은 수년간 Clang과 유사한 진단을 발행 해 왔습니다.

둘째, EDG 프론트 엔드는 인텔 코드 생성기가 빠른 코드를 생성하는 것만 큼 뛰어난 언어 적합성으로 잘 알려져 있습니다. 거의 모든 합리적인 조치로 EDG 프론트 엔드는 사용 가능한 다른 컴파일러보다 C ++ 98, 03 또는 (현재 버전에서는) C ++ 0x를 더 잘 준수합니다.

내가 말했듯이, 이러한 두 가지 장점은 시간이 지남에 따라 다양한 정도로 침식되었습니다. 최신 버전의 gcc는 꽤 괜찮은 언어 적합성을 가지고 있습니다. Clang은 훨씬 더 나은 오류 메시지를 가지고 있으며 전체 C ++ 언어를 구현하는 데에도 진전을 보이고 있습니다. 그러나 인텔 C ++은 여전히 ​​두 가지 측면에서 하나보다 낫습니다. 하나의 패키지는 우수한 진단을 위해 하나의 컴파일러가 필요하고 더 나은 적합성 및 코드 생성을 위해 다른 하나가 필요하지 않고 대부분의 일을 올바르게 수행합니다.

우리는 이것을 직장에서 잠시 전에 시도했습니다. 우리의 코드베이스는 대부분 델파이에 있지만, 누군가가 C ++ DLL 방식으로 할 때 좋은 아이디어라고 생각하는 계산 집약적 인 기능을 가지고 있습니다. 제 동료 중 한 명이 인텔 컴파일러에 대해 큰 이야기를 들었으므로 시도해보기로했습니다. 인텔 컴파일러에서 DLL을 다시 빌드하고 일부 속도 테스트를 실행 한 결과 결과가 너무 놀랐 기 때문에 그가 무언가 잘못하고 있다고 생각했습니다.

DLL은 조합 및 토폴로지 구성 요소와 관련하여 매우 어려운 몇 가지 문제를 계산해야합니다.이 구성 요소는 기술적으로 "올바른"경우 난이도 난이도 클래스이지만 NP 성능을 피하기 위해 다양한 휴리스틱을 사용합니다. 그럼에도 불구하고 많은 수의 크 런칭이 진행되고 있습니다. 그리고 우리가 실행 한 테스트에서 VS 컴파일러와 인텔 컴파일러의 차이는 엡실론 내에 있었거나 인텔 컴파일러는 일반적으로 20 % 정도의 어딘가에서 현저히 느 렸습니다. 인텔 컴파일러가 더 빠른 코드를 생성하도록하기 위해 컴파일 설정을 변경 한 경우에도 마찬가지입니다. 그래서 우리는 그것을 바꾸지 않았습니다.

물론 이것은 실제 사례 중 하나 일뿐입니다. 귀하의 마일리지가 다를 수 있습니다.

내가 한 번 임베디드 응용 프로그램에서 인텔 컴파일러의 시험판을 사용하면 새로운 하드웨어를 더 높은 성능으로 회전시킬 필요가 없다는 것을 보여주었습니다. 새 하드웨어의 비용은 단위당 약 $ 10, 1 백만 단위의 판매 예상, 개발 비용 및 프로젝트 지연을 추가했습니다. 옵션 2는 이미 합리적으로 잘 프로파일 링 / 최적화 된 코드 기반-알려지지 않은 결과, 알려지지 않은 시간 인 프로필 / 마이크로 최적화였습니다.

사장님이 우리에게 컴파일러 구매를위한 자금을 요청했을 때 어떻게 생각하십니까? ......

그러나 이것은 매우 운이 좋고 드문 경우였습니다. 인텔 컴파일러의 10 % 빠른 코드 출력으로 인해 우리는 올바른 성능 측면으로 되돌아갔습니다. 우리가 이미 오른쪽에 있거나 10 %를 초과했다면 차이가 없었을 것입니다. 엔지니어가 코드를 최적화하고 하드웨어 스핀을 절약 할 수 있었고 인텔 컴파일러는 필요하지 않았지만, 위험은 높았고 인텔 컴파일러는 엔지니어링 시간보다 저렴했습니다.

균형 잡히면 그것은 그것이 마이크로 최적화의 한 형태라고 말할 것입니다-당신이 알아야 할 때까지, 그리고 문제의 실제 원인을 프로파일 링하고 찾은 후에 만하지 마십시오. 그것은 당신이 '모든 곳'에서 느리고 병목이 확인되지 않았 음을 보여주는 프로파일의 특히 좋은 선택입니다.

나는 세 가지 장점 만 겪었습니다.

1. 다른 컴파일러보다 훨씬 빨리 최신 Intel CPU의 기능을 지원합니다.

2. 경고를 발행하고 다른 컴파일러가 놓친 문제를 포착하는 훌륭한 추가 컴파일러입니다. GCC는 ICC가하지 않는 것을 포착하고 그 반대도 마찬가지입니다. Visual Studio는 ICC가 제공하지 않는 것을 포착합니다.

3. 다른 컴파일러보다 자동 병렬 루프 (다중 스레드에 자동으로 분배)를 훨씬 잘 수행합니다. 코드의 이점은 그리 크지 않지만 코드가 있으면 큰 차이가 생길 수 있습니다.

우리는 코드베이스의 모든 성능 평가 프로젝트에 인텔 컴파일러를 사용합니다. 가장 좋은 점은 코드 최적화가 실제로 유지 관리 가능하다는 것입니다. 어디서나 __mm 호출을 수동으로 추가하고 컴파일러에게 데이터를 프리 페치하도록 지시하는 대신, 다음 릴리스에서 다시 최적화되지 않는 코드를 다시 정렬하면 코드를 다시 정렬하고 미친 듯이 속도를 높일 수 있습니다.

최적화 된 코드는 수작업으로 최적화 된 것보다 따르기 쉽고, 손으로 최적화 된 것보다 빠르며, 새로운 명령어 세트가 릴리스되면 컴파일러는 해당 명령어 세트를 사용합니다. 환상적이야.

arm에서 해제하면 벡터화에 큰 도움이되는 경우 arm 컴파일러 (intel이 아닌 arm에서)도 마찬가지입니다.

이 벤치 마크 페이지를 확인하십시오. 요컨대 인텔이 이긴다.

그러나 마진이 그렇게 크지 않을 수도 있습니다. 32 비트로 컴파일하고 빌드 시스템이 프로파일 가이드 최적화를 지원할 수 없다면 이득은 10 % 정도입니다. 이러한 개선이 문제가되고 컴파일 시간이 길어 집니까?

인텔은 안드로이드 OS 용 인텔 C ++ 컴파일러 v13.0을 출시했다고 전해진다. 구글의 모바일 플랫폼을 위해 특별히 설계된 최적화 된 C / C ++ 컴파일러를 제공하려는 첫 시도 다.

개발자는 Linux * 기반 시스템에서 컴파일러를 사용하여 인텔 ® 아톰 ™ 프로세서를 포함한 인텔 프로세서 기반 Android 장치 용 앱을 만들 수 있습니다. 인텔 컴파일러는 NDK (Android Native Development Kit)의 GNU C ++ 및 개발자 도구와 호환됩니다. 개발 시스템에서도 컴파일러를 사용할 수 없습니다. Windows와 OS X는 모두 지원되지 않습니다. 이 도구는 Ubuntu 10.04 또는 11.04에서만 사용하도록 인증되었습니다

Android NDK의 현재 버전은 기본적으로 오픈 소스 GCC (Gnu Compiler Collection) 툴체인 버전 4.6을 사용합니다. 그러나 인텔의 컴파일러에는 자체 칩에 대한 독점 최적화가 많이 포함되어 있으며 GCC와 같은 타사 컴파일러에서 생성 한 것보다 성능이 우수한 실행 코드를 출력 할 수 있습니다.