문제

일반적으로 컴파일러를 최대 속도 또는 최소 코드 크기에 맞게 최적화하도록 설정합니까?아니면 개별 최적화 설정을 수동으로 구성합니까?왜?

나는 대부분의 사람들이 컴파일러 최적화 설정을 기본 상태로 두는 경향이 있다는 것을 알았습니다. 이는 Visual C++에서 최대 속도를 의미합니다.저는 항상 기본 설정이 벤치마크에서 보기 좋게 보이는 것과 더 관련이 있다고 느꼈습니다. 벤치마크는 전체 성능에 가장 적합한 것보다 L2 캐시에 완전히 맞는 작은 프로그램인 경향이 있기 때문에 일반적으로 가장 작은 크기에 최적화되도록 설정했습니다.

도움이 되었습니까?

해결책

Gentoo 사용자로서 저는 전체 OS에서 꽤 많은 최적화를 시도했으며, 젠투 포럼 그것에 대해.GCC에 대한 몇 가지 좋은 플래그는 다음에서 찾을 수 있습니다. 위키.

간단히 말해서 크기 최적화는 RAM이 제한된 오래된 Pentium3 노트북에서 가장 잘 작동했지만 Core2Duo가 있는 기본 데스크톱 컴퓨터에서는 -O2가 전반적으로 더 나은 결과를 제공했습니다.

또한 작은 스크립트 가장 최적화된 x86(32비트) 특정 플래그에 관심이 있다면.

gcc를 사용하고 특정 애플리케이션을 실제로 최적화하고 싶다면 다음을 시도해 보세요. 아코베아.일련의 벤치마크를 실행한 다음 가능한 모든 컴파일 플래그 조합을 사용하여 다시 컴파일합니다.사이트에 Huffman 인코딩을 사용하는 예가 있습니다(낮을수록 좋음).

A relative graph of fitnesses:

   Acovea Best-of-the-Best: **************************************                (2.55366)
     Acovea Common Options: *******************************************           (2.86788)
                       -O1: **********************************************        (3.0752)
                       -O2: ***********************************************       (3.12343)
                       -O3: ***********************************************       (3.1277)
           -O3 -ffast-math: **************************************************    (3.31539)
                       -Os: *************************************************     (3.30573)

(이 Opteron 시스템에서는 -Os가 가장 느린 것으로 나타났습니다.)

다른 팁

나는 최소한의 크기를 사용하는 것을 선호합니다.메모리는 저렴할 수 있지만, 캐시는 아니다.

On Freund가 말했듯이 캐시 지역성이 중요하다는 사실 외에도 Microsoft가 수행하는 또 다른 작업은 응용 프로그램을 프로파일링하고 시작 후 처음 몇 초 동안 실행되는 코드 경로를 찾는 것입니다.그런 다음 이 데이터를 컴파일러에 다시 공급하고 시작 중에 실행되는 부분을 서로 가깝게 배치하도록 요청합니다.이로 인해 시작 시간이 더 빨라집니다.

나는 이 기술이 VS에서 공개적으로 사용 가능하다고 믿지만 100% 확신할 수는 없습니다.

나에게는 내가 사용하는 플랫폼에 따라 다릅니다.일부 임베디드 플랫폼의 경우나 Cell 프로세서 작업을 할 때 매우 작은 캐시나 코드용으로 제공되는 최소한의 공간과 같은 제약이 있었습니다.

저는 GCC를 사용하며 "가장 안전한" 최적화 수준인 "-O2"에 두는 경향이 있으며 최소 크기보다 속도를 선호합니다.

매우 높은 성능의 애플리케이션을 개발하는 경우가 아니라면 아마도 큰 차이는 없을 것입니다. 이 경우 특정 사용 사례에 대한 다양한 옵션을 벤치마킹해야 할 것입니다.

Microsoft는 크기에 최적화된 모든 C/C++ 소프트웨어를 제공합니다.벤치마킹 후 그들은 실제로 더 나은 속도를 제공한다는 것을 발견했습니다(캐시 지역성으로 인해).

다양한 유형의 최적화가 있으며, 최대 속도와 작은 코드는 단 하나입니다.이 경우 실행 파일이 조금 더 커지므로 최대 속도를 선택하겠습니다.반면에 특정 유형의 프로세서에 맞게 애플리케이션을 최적화할 수도 있습니다.어떤 경우에는 이것이 좋은 생각이지만(당신의 스테이션에서만 프로그램을 실행하려는 경우), 이 경우 프로그램이 다른 아키텍처에서 작동하지 않을 가능성이 있습니다(예:Pentium 4 시스템에서 작동하도록 프로그램을 컴파일합니다. -> 아마도 Pentium 3에서는 작동하지 않을 것입니다.

둘 다 구축하고 프로파일링하여 특정 프로젝트와 하드웨어에서 더 잘 작동하는 것을 선택하세요.

성능이 중요한 코드의 경우 즉, 그렇지 않은 경우 아무거나 선택하고 신경쓰지 마세요.

우리는 항상 최적의 속도를 위해 최대화를 사용하지만 C++로 작성한 모든 코드는 어떻게든 생물정보학 알고리즘과 관련이 있으며 코드 크기는 상대적으로 작지만 속도는 매우 중요합니다.

요즘은 메모리가 저렴합니다 :) 따라서 임베디드 시스템으로 작업하지 않는 한 컴파일러 설정을 최대 속도로 설정하는 것이 의미가 있을 수 있습니다.물론 대답은 구체적인 상황에 따라 다릅니다.

이는 프로그램의 적용에 따라 다릅니다.빠른 산업 공정을 제어하기 위해 애플리케이션을 프로그래밍할 때 속도를 최적화하는 것이 합리적입니다.사용자 입력에만 반응하면 되는 애플리케이션을 프로그래밍할 때 크기 최적화가 합리적일 수 있습니다.즉, 실행 파일의 크기가 걱정되는 경우입니다.

이와 같이 컴파일러 설정을 조정하는 것이 최적화입니다."성급한 최적화는 모든 악의 근원이다"라는 원칙에 따라, 나는 프로그램이 최종 출시 상태에 가까워질 때까지 그것에 신경 쓰지 않고 그것이 충분히 빠르지 않다는 것을 발견했습니다.거의 없다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top