GCC optimization

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page GCC optimization and the translation is 25% complete.
Outdated translations are marked like this.
Other languages:

이 안내서에서는 안전하고 멀쩡한 CFLAGS와 CXXFLAGS를 사용하여 컴파일한 코드를 최적화 하는 방법을 소개합니다. 일반적으로 최적화 하기 이전의 이론적인 내용도 설명합니다.

Default CFLAGS can be set in make.conf for Gentoo systems. CFLAGS can also be specified per-package.

See also
For more information see CFLAGS and CXXFLAGS in the Gentoo Handbook, and the safe CFLAGS article. See also the FAQ.

도입부

CFLAGS와 CXXFLAGS란 뭔가요?

CFLAGS와 CXXFLAGS는 C/C++ 코드를 컴파일할 때 빌드 시스템에 컴파일러 옵션을 늘상 전달할 때 활용하는 환경 변수 중 하나입니다. 이 변수를 표준화한 건 아니지만, 언제 어디서든 활용하며 컴파일러를 실행할 때 추가, 제대로 작성한 빌드에 개별 옵션을 전달할 때 제대로 이해하도록 해야합니다. 이 분야에서 일반적으로 활용하는 변수 일부 목록을 보려면 GNU make 정보 페이지를 확인하십시오.

젠투 시스템을 이루는 꾸러미의 대부분은 C/C++ 언어로 작성했기 때문에, 관리자가 올바르게 설정하려는 이 두가지 변수는 시스템을 빌드하는 과정에 상당한 영향을 줍니다.

이 변수는 프로그램에 대한 많은 양의 디버그 메시지를 줄여주거나 오류 경고 수준을 높이고, 물론 생산 코드의 최적화 수준을 조절하는데 사용할 수도 있습니다. GCC 설명서 에서는 이들 변수에서 사용할 수 있는 옵션과 목적에 대한 완전한 목록을 제공합니다.

어떻게 사용하나요?

보통 설정 스크립트를 실행하거나 automake로 만든 makefile로 CFLAGS와 CXXFLAGS를 설정합니다. 젠투 시스템에서는 CFLAGS 변수와 CXXFLAGS 변수를 /etc/portage/make.conf에 설정합니다. 이 파일에 설정한 변수는 이 옵션을 기반으로 모든 꾸러미를 컴파일하는 포티지에서 실행할 프로그램의 환경으로 내보냅니다.

코드 /etc/portage/make.conf의 CFLAGS 설정
CFLAGS="-march=athlon64 -O2 -pipe"
CXXFLAGS="${CFLAGS}"
중요
USE 플래그에 여러 줄을 넣을 수 있지만, CFLAGS에 똑같이 하면 cmake 같은 프로그램에 문제가 될 수 있습니다. CFLAGS 선언을 한 줄로 했는지, 문제를 막기 위해 가능한 한 공백을 줄였는지 확인하십시오. 예제로 bug #500034를 보십시오.

보시는 바와 같이, CXXFLAGS는 CFLAGS에 나타나는 모든 옵션을 사용하는 집합입니다. 대부분의 모든 시스템에서는 이 방식으로 설정해야합니다. CXXFLAGS 추가 옵션은 일반적이지 않으며, 보통 여기 언급한 설정이 전체적으로 설정할만하므로 보통 적용하지 않습니다.

요령
Safe CFLAGS article might help beginners start optimizing their systems.

오해

CFLAGS에 컴파일러 최적화 옵션을 여러개 설정해두면 작고 빠르게 동작하는 이진 파일을 만들 수 있지만, 비정상적으로 코드가 동작할 수 있고, 크기가 부풀어오를 수 있으며, 실행 시간이 늘어나거나, 빌드에 실패할 수 있습니다. CFLAGS를 다루다보면 빨라지기보단 오히려 성능 저하 측면으로 돌아갑니다. 임의로 설정하지 마십시오.

/etc/portage/make.conf에 설정한 전역 CFLAGS 변수는 시스템의 모든 꾸러미에 적용하므로 보통 관리자만 광범위하게 적용할 수 있는 값으로 설정합니다. 개별 꾸러미에서는 이빌드 또는 빌드 시스템 자체에서 컴파일러를 실행할 때 사용할 최종 플래그 셋을 만들 때 옵션을 수정합니다.

준비됐죠?

이제 약간의 위험성이 있다는 사실을 인지하고, 여러분의 컴퓨터에 멀쩡하고 안전한 최적화를 수행하도록 해보겠습니다. 여러분께 도움이 될 것이고 버그질라에 문제를 알리면 개발자들에게 촉망받을 것입니다. (개발자들은 종종 어떤 문제가 집요하게 나타나면 최소한의 CFLAGS로 패키지를 다시 컴파일 하라고 합니다. 과감한 플래그 설정은 오히려 코드를 제대로 동작하지 못하게 함을 기억하십시오.)

최적화

기본

CFLAGS와 CXXFLAGS를 사용하는 목적은 시스템에 코드를 잘 다듬어 놓기 위함입니다. 가능하면 잘 빠지고 빠르게 제 기능을 완벽하게 다 할 것입니다. 가끔은 상호간에 배타적이어서 두 요소가 잘 동작하게 붙들고 있을 때도 있습니다. 이상적으로는 어떤 CPU 아키텍처에든 잘 돌아갑니다. 후반에 적극적인 플래그를 언급하여 여러분이 알아보고자 하는 바를 알 수 있게끔 할 것입니다. GCC 설명서에 있는 모든 옵션(수백개!)에 대해 언급하지 않겠지만 대부분 기본적이고 일반적인 플래그를 다루도록 하겠습니다.

참고
어떤 플래그가 실제로 어떤 역할을 하는지 확신할 수 없을 때면 GCC 설명서의 관련 장을 참고하십시오. 설명서를 봐도 무슨 얘긴지 모르겠다면 구글에서 검색해보든지, GCC 메일링 리스트에서 확인해 보십시오.

-march

제일 처음에 나오는 가장 중요한 옵션은 -march입니다. 이 플래그는 프로세서 아키텍처 (또는 arch)에 대해 어떤 코드를 만들어야 하는지 컴파일러에게 일러줍니다. GCC에게 각각의 CPU에 맞춰 코드를 만들어야 함을 알려줍니다. 각기 다른 시스템의 CPU에서는 각자 다른 기능을 보유하고, 다른 명령셋을 지원하며, 개별 코드 실행에 각각 다른 방식을 활용합니다. -march 플래그는 보유한 CPU에 맞게 기능, 특징, 명령셋, 고유의 동작 등을 포함한 코드를 컴파일러에게 만들어달라고 지시합니다.

-march= is an ISA selection option; it tells the compiler that it may use the instructions from the ISA. On an Intel/AMD64 platform with -march=native -O2 or lower optimization level, the code will likely end up with AVX instructions used but using shorter SSE XMM registers. To take full advantage of AVX YMM registers, the -ftree-vectorize, -O3 or -Ofast options should be used as well[1].

-ftree-vectorize is an optimization option (default at -O3 and -Ofast), which attempts to vectorize loops using the selected ISA if possible. The reason it previously wasn't enabled at -O2 is that it doesn't always improve code, it can make code slower as well, and usually makes the code larger; it really depends on the loop etc. As of GCC 12, it is enabled by default with a low cost model (-fvect-cost-model=very-cheap) to strike a balance between code size and speed benefits. The cost model can be specified with -fvect-cost-model.

/etc/portage/make.conf의 CHOST 변수에 일반적으로 아키텍처에서 사용하는 플래그를 지정하지만, -march 플래그는 지정 시스템 프로세서에 맞게 프로그램을 최적화하는데 사용할 수 있습니다. (다른 CPU 중에서) x86과 x86-64 CPU는 -march 플래그를 사용해야 합니다.

어떤 CPU를 가지고 있나요? 찾아보려면 다음 명령을 실행하십시오:

user $cat /proc/cpuinfo

or even install app-portage/cpuid2cpuflags and add the available CPU-specific options to the /etc/portage/package.use/00cpuflags file, which the tool does through e.g. the CPU_FLAGS_* variable:

user $cpuid2cpuflags
CPU_FLAGS_X86: aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sha sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3
root #echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

march와 mtune 값에 대한 자세한 내용을 살펴보려면, 다음 두 명령을 사용할 수 있습니다.

  • 처음 명령은 컴파일러에 링크 작업을 수행하지 말라고 하는(-c) 대신, 명령행 옵션을 분명하게 보여주는 --help 옵션을 해석하여 어떤 옵션을 활성화했고 비활성화했는지(-Q) 보여줍니다. 이 경우 선택한 대상 아키텍처에 대해 활성화한 옵션을 보여줍니다:
user $gcc -c -Q -march=native --help=target
  • 두번째 명령은 헤더 파일을 빌드할 컴파일러 지시자를 보여줍니다만, 실제 동작 과정 없이 화면에 보여줍니다(-###). 최종 출력 행에는 모든 최적화 옵션과 아키텍처 선택을 지닌 명령이 나타납니다.
user $gcc -### -march=native /usr/include/stdlib.h
참고
The l2-cache-size option represents processor's last level cache (L2 or higher if present).[2]
  • The glibc-hwcaps feature (>=sys-libs/glibc-2.33) can be used to define -march for a more general processor architecture (for >=sys-devel/gcc-11):
user $/lib64/ld-linux-x86-64.so.2 --help
...
Subdirectories of glibc-hwcaps directories, in priority order:
 x86-64-v4
 x86-64-v3 (supported, searched)
 x86-64-v2 (supported, searched)
 x86_64 (supported, searched)

In this example, the cpu supports x86-64-v3 psABI x86_64 which can be used for -march=x86-64-v3.

이제 -march 동작을 보겠습니다. 예제는 옛날 펜티엄 III 칩입니다:

파일 /etc/portage/make.confPentium III 예제
CFLAGS="-march=pentium3"
CXXFLAGS="${CFLAGS}"

64-bit AMD CPU에 대한 또 다른 설정 내용입니다:

파일 /etc/portage/make.confAMD64 예제
CFLAGS="-march=athlon64"
CXXFLAGS="${CFLAGS}"

어떤 CPU를 쓰는지 모르겠거나 어떤 설정을 선택해야 할지 모르겠다면, 아마 그냥-march=native 설정을 사용할 수 있습니다. 이 플래그를 사용하면 GCC는 프로세서를 감지하고 자동으로 적당한 플래그를 설정합니다. 그러나 다른 CPU에서 사용할 패키지를 컴파일하려 한다면 이 플래그를 쓰면 안됩니다.

하나의 컴퓨터에서 패키지를 컴파일 하는데 다른 컴퓨터에서 실행하려 한다면(예를 들어 더 느리고 오래된 머신에서 실행할 바이너리를 빌드하는데 더 빠른 컴퓨터를 사용하는 경우), -march=native를 사용하지 마십시오. "Native"는 말 그대로 해당 CPU에서만 동작할 코드를 만듦을 의미합니다. AMD Athlon 64 CPU에서 -march=native 플래그로 빌드한 프로그램은 옛날 VIA C3 CPU에서 실행할 수 없습니다.

또한 이 말고도 -mtune와 -mcpu 플래그가 있습니다. 이 플래그는 보통 -march 옵션을 쓰지 못할때만 사용합니다. 어떤 프로세서 아키텍처에서는 -mtune아니면 -mcpu가 필요합니다. 불행하게도 GCC의 동작은 어떤 한 아키텍처에서 다음 아키텍처로 각각의 플래그를 부여하는데 있어 일관성이 꽤 있는 것이 아닙니다.

x86과 x86-64 CPU에서 -march 플래그를 통해 존재하는 모든 명령 셋과 올바른 ABI를 활용하여 CPU에 대한 지정 코드를 생성합니다. 이전의 다른 CPU에 대한 이전 호환성은 없습니다. i386과 i486 같은 예전 CPU에 대해 코드를 생성할 때만 -mtune의 사용을 고려하는것이 좋습니다. -mtune 플래그는 -march보다 훨씬 일반적인 코드를 만들어냅니다. 각각의 CPU에 대한 적당한 코드를 만들어내겠지만서도, 존재하는 명령셋과 ABI에 맞춰주진 못합니다. x86이나 x86-64 시스템에서 -mcpu 플래그는 오래된 요소이므로 사용하지 마십시오.

비 x86/x86-64 CPU에서는(Sparc, 알파 PowerPC) -march 대신 -mtune 또는 -mcpu가 필요할듯 합니다. 이 아키텍처에서는 -mtune / -mcpu 옵션이 (x86/x86-64의) -march 처럼 동작하기도 합니다...만 플래그 이름은 달라집니다. 다시 말해, GCC의 동작과 플래그 이름은 전 아키텍처에 대해 일관성이 있는건 아니므로, 시스템에서 사용할 아키텍처가 무엇인지 정하려면 GCC 설명서를 확인하십시오.

참고
-march / -mtune / -mcpu 설정에 대해 제안하는 더 많은 내용은 사용 해당 아키텍처의 젠투 설치 핸드북 5장을 읽어보십시오. 또한 GCC 설명서 내용중, 아키텍처별 옵션 목록에서 -march, -mcpu, -mtune 차이를 자세하게 설명한 부분을 읽어보십시오.
경고
distcc로 컴파일 할 때는 make.conf의 CFLAGS 또는 CXXFLAGS 값을 -march=native 또는 -mtune=native로 사용하지 마십시오.

-O

경고
Using -O3 or -Ofast may cause some packages to break either during the compilation or misbehave at runtime.
참고
To print all packages that were built with specified CFLAGS/CXXFLAGS it's possible to use the following command: grep Ofast /var/db/pkg/*/*/CFLAGS

다음은 -O 변수입니다. 이 변수는 최적화의 전체 수준을 제어합니다. 이 값을 늘려 바꾸면 최적화 설정을 통해 특히 최적화 레벨을 올리는 만큼 코드 컴파일 과정의 시간을 더 걸리게 하거나, 메모리를 더 많이 소비합니다.

7가지의 -O 레벨 설정 -O0, -O1, -O2, -O3, -Os, -Og, -Ofast가 있습니다. /etc/portage/make.conf 파일에서 이들 중 하나만을 사용해야 합니다.

-O0는 예외로 간주하고, 각각의 -O 설정은 몇가지 추가 플래그를 활성화 하므로, GCC 메뉴얼의 최적화 옵션 장을 읽어 각각의 -O 레벨에서 어떤 플래그를 활성화 하는지, 이들이 각각 어떤 동작을 취하는지 알아보십시오.

각각의 최적화 레벨을 살펴보도록 하겠습니다:

  • -O0: 이 레벨(글자"O" 다음에 숫자 영이 따라옴)은 최적화를 완전히 끄고, CFLAGS 또는 CXXFLAGS에 -O 레벨을 기본으로 지정하지 않았을 경우에 기본값이 됩니다. 컴파일 시간을 줄이고 디버그 정보를 개선할 수 있지만, 어떤 프로그램은 최적화를 활성화 하지 않으면 제대로 동작하지 않는 수가 있습니다. 이 옵션은 디버깅 목적이 아니라면 사용하지 않는 것이 좋습니다.
  • -O1: 이 레벨은 매우 기본적인 최적화를 수행합니다. 컴파일러는 더 많은 컴파일 시간을 소비하지 않고도 빠르고 작은 코드를 만들어냅니다. 기본적일 수는 있지만 항상 컴파일 작업이 완료됩니다.
  • -O2: -O1에서 한 단계 상승합니다. 시스템에서 특별하게 필요한 경우가 아닌 한 권장하는 최적화 레벨입니다. -O2 플래그는 -O1 플래그로 활성화 한 플래그보다 더 많은 플래그를 활성화 합니다. -O2 플래그로, 컴파일러에서는 바이너리 크기와의 절충 없이 무조건 코드 성능을 끌어올리여 하며, 컴파일 시간을 너무 많이 소비하지 않습니다.
  • -O3: 가능한 가장 높은 최적화 레벨입니다. 컴파일 시간과 메모리 사용에 있어 그 이상의 최적화를 활성화합니다. -O3으로 컴파일 할 때는 성능을 개선한다는 보장이 없으며, 실제로 대부분의 경우, 바이너리가 커지고 메모리 사용량이 증가하여 시스템을 느리개 할 수 있습니다. -O3는 또한 몇가지 꾸러미를 깨뜨리는 걸로 알려져 있습니다. -O3 플래그 사용을 권장하지 않습니다.
  • -Ofast: GCC 4.7에서 새로 도입했으며, -O3, -ffast-math, -fno-protect-parens, and -fstack-arrays로 이루어져 있습니다. 이 옵션은 엄격한 표준 준수를 깨며, 사용을 권장하지 않습니다.
  • -Os: 코드 크기를 최적화 합니다. 만든 코드의 크기가 늘어나지 않게 하는 모든 -O2 옵션을 활성화 합니다. 매우 제한된 디스크 저장소 공간을 가지고 있거나 CPU의 캐시 크기가 작을 경우 유용합니다.
  • -Oz: Introduced in GCC 12.1, more aggressively optimize for size than -Os. Note this will heavily degrade runtime performance than -O2, due to increasing the number of instructions executed if those instructions require fewer bytes to encode.
  • -Og: GCC4.8에 새로운 일반 최적화 레벨 -Og를 도입했습니다. 빠른 컴파일을 필요로 하며 실행시간 성능의 타당한 수준을 제공하면서 우수한 디버깅 경험을 할 수 있게 바로 잡았습니다. 개발에 있어 전체적인 경험은 기본 최적화 레벨 -O0보단 낫습니다. 참고로 -Og는 -g를 의미하지 않으며, 디버깅에 혼란을 주는 최적화 기능을 끌 뿐입니다.

이전에 말한 바와 같이, -O2가 추천하는 최적화 레벨입니다. -O2를 사용하지 않아 패키지 컴파일에 실패했다면 이 옵션으로 다시 빌드해보십시오. 대체 옵션으로 -O1또는 -O0 -g2 -ggdb 같은 더 낮은 최적화 레벨의 플래그로 CFLAGS와 CXXFLAGS를 설정해보십시오(오류 보고 및 존재하는 문제 확인용).

-pipe

일반적인 플래그로 -pipe가 있습니다. 이 플래그는 실제로 코드를 생성하는덴 아무런 영향잉 벗습니다만, 컴파일 과정을 좀 더 빠르게 합니다. 컴파일러에게 메모리를 더욱 소비하는 제각기 다른 스테이지에서 컴파일을 수행하는 동안 임시 파일 대신 파이프를 사용하라고 알려줍니다. 시스템에서 메모리가 부족하면 GCC가 갑자기 끝납니다. 이 경우, 이 플래그를 사용하지 마십시오.

-fomit-frame-pointer

생성 코드의 크기를 줄이도록 설계한 가장 일반적인 플래그입니다. (x86-64 같은) 디버깅에 혼란을 겪지 않는 아키텍처에서 모든 -O 레벨(-O0 제외)을 켜놓겠지만 활성화해야합니다. 이 경우 플래그에 추가하십시오. GCC 설명서에는 모든 아키텍처 별로 다루지 않지만 -O 옵션을 켜놓았습니다. 아직까지도 GCC 4.6 이상을 쓰거나 어떤 GCC 버전에서든 -Os 플래그를 사용한다면, x86-32 에 대해 -fomit-frame-pointer 옵션을 분명히 활성화해야합니다. 그러나 -fomit-frame-pointer 옵션을 활성화하면 디버깅을 어렵게 하거나 불가능하게 할 수 있습니다.

다만 일부의 경우에는, Java가 이 플래그로 인해 코드에만 영향을 받는 것이 아니기 때문에 Java로 작성한 프로그램의 문제 해결을 더 어렵게 합니다. 따라서 플래그는 어디엔가 도움이 된다면, 디버깅을 어렵게 하며, 백트레이싱이 무용지물이 됩니다. 그러나 프로그램 디버깅을 면밀하게 진행할 생각이 없거나, -ggdb와 같은 디버깅 관련 CFLAGS를 추가하지 않았다면, -fomit-frame-pointer를 사용해볼 수 있습니다.

중요
-fomit-frame-pointer 플래그를 유사한 플래그 -momit-leaf-frame-pointer와 함께 사용하지 마십시오. -fomit-frame-pointer 플래그가 제대로 동작하므로 후자의 플래그 사용은 권장하지 않습니다. 게다가 -momit-leaf-frame-pointer 플래그는 코드 성능에 부정적 영향을 주는걸로 나타납니다.

-msse, -msse2, -msse3, -mmmx, -m3dnow

이 플래그는 x86과 x86-64 아키텍처의 Streaming SIMD Extentions(SSE), SSE2, SSE3, MMX, 3DNow! 기계 명령 세트 사용을 가능하게 합니다. 이 명령 세트는 수학적 개선 기능이 포함되어 있어 주로 멀티미디어, 게임, 기타 부동 소수점 치중 계산처리 작업에 쓸만합니다. 이 기계 명령 세트는 최신 CPU에 들어있습니다.

중요
cat /proc/cpuinfo명령을 실행하여 CPU에서 이들 명령을 지원하는지 확인하십시오. 출력 내용에는 추가 기계 명령 세트 지원 내용이 들어있습니다. 참고로 pni는 SSE3의 또 다른 이름일 뿐입니다.

보통, 올바른 -march (예: -march=nocona 는 암묵적으로 -msse3을 의미) 플래그 설정을 이미 사용하고 있어왔기 때문에, 어떤 플래그도 /etc/portage/make.conf에 추가할 필요는 없습니다. (SSE3와 같이) -march가 암시하지 않는 기계 명령을 지원하는 최근의 VIA와 AMD64 CPU에는 참고할 만한 별도의 고려사항이 있습니다. 이들 CPU 같은 경우는 /proc/cpuinfo의 내용을 확인하여 적당한 플래그를 넣고 활성화해야합니다.

참고
적당한 CPU 형식 플래그로 어떤 기계 명령 세트를 활성화하는지 찾아보려면 x86과 x86-64 관련 플래그 목록을 살펴보십시오. 기계 명령이 목록에 있다면 지정할 필요가 없습니다. 기계 명령 세트는 적당한 -march 설정으로 활성화합니다.

Hardening optimizations

참고
While it is possible to use a hardened profile, it certainly isn't necessary for adding some hardening flags to /etc/portage/make.conf on a different profile. Especially on a desktop system, the use of position independent code (PIC) and position independent executables (PIE) on a system-wide level may cause compilation failures.

Hardening an otherwise unhardened system, like when using a desktop profile, can be considered a GCC optimization as well, especially in the light of security vulnerabilities such as Meltdown and Spectre.

Some packages feature an individual hardened USE flag, enabling tested security enhancements (like CFLAGS/CXXFLAGS). It may be a good idea to set this system-wide in /etc/portage/make.conf.

참고
Reading section Do I need to pass any flags to LDFLAGS/CFLAGS in order to turn on hardened building? in the Hardened/FAQ is recommended for retrieving some basic hardened CFLAGS/CXXFLAGS.
경고
Changing the CFLAGS/CXXFLAGS can cause problems and in some cases may even render a system unusable. Rebuilding the whole system with emerge -e @world may resolve the situation.

Overflow protection

Optimizing CFLAGS/CXXFLAGS for overflow protection can be a good idea if security concerns outweigh speed optimization. This may be the case on a daily-use desktop system, while e.g. on an optimized gaming PC it will be considered counterproductive.

For GCC version 12, package sys-devel/gcc, the USE flags default-stack-clash-protection and default-znow will automatically enable additional overflow protection.

참고
A lot of these flags are now applied internally through the GCC toolchain automatically under the hardened profile, and some even under the regular profile. See table at Hardened/Toolchain.
CFLAGS/CXXFLAGS LDFLAGS function
-D_FORTIFY_SOURCE=2 run-time buffer overflow detection
-D_GLIBCXX_ASSERTIONS run-time bounds checking for C++ strings and containers
-fstack-protector-strong stack smashing protector
-fstack-clash-protection increased reliability of stack overflow detection
-fcf-protection control flow integrity protection
-Wl,-z,defs detect and reject underlinking
-Wl,-z,now disable lazy binding
-Wl,-z,relro read-only segments after relocation

ASLR

Address Space Layout Randomization (ASLR) is measure to increase security by randomly placing each function and buffer in memory. This makes it harder for attack vectors to succeed.

PIE is enabled by default when it is safe to do so on all 17.0 profiles[3]. PIC may also be enabled by default on executables for architectures that require it (like AMD64).

There is no need to set PIE or PIC manually in CFLAGS.

CFLAGS/CXXFLAGS LDFLAGS function
-fpie -Wl,-pie full ASLR for executables
-fpic -shared no text relocations for shared libraries

최적화 자주 묻는 질문

Higher version of GCC should mean better optimizations?

Not always because of software regression, where an optimization with an earlier version of GCC no longer optimizes. A full list of regressions can be found at this link. Should this happen, please file a bug to Gentoo's bugzilla and/or GCC's bugzilla.

Is there a perfect optimizer?

No, because it would solve the halting problem, where it can tell if any program stops or runs forever [4].

What about optimizing GCC itself?

gcc has pgo and lto use flags that enables Profile Guided Optimization and Link Time Optimization respectively. To enable for building gcc itself with PGO and LTO:

파일 /etc/portage/package.use/gcc
sys-devel/gcc pgo lto

In Gentoo, a 3-stage bootstrap of gcc is done, meaning it compiles itself three times [5]. In stage1, gcc is complied using an older gcc. In stage2, gcc is compiled using stage1 gcc. In stage3, gcc is compiled using stage2 gcc and is used to verify that stage2 gcc and stage3 gcc are the same. This is done because it is tested more completely and has better performance. The lto use flag adds -flto to BOOT_CFLAGS. The pgo use flag adds -fprofile-generate to stage2 gcc and adds -fprofile-use -fprofile-reproducible=parallel-runs to stage4 gcc.

gcc performance may improve via PGO, although it may as much as double the compile times.

근데 -funroll-loops -fomg-optimize로 성능이 더 좋아졌는데요?!

아닌데요. 누군가가 더 많은 플래그를 사용하는게 좋다고 납득시켰기 때문에 그렇게 생각할 뿐입니다. 플래그를 섣부르게 설정하면 시스템 전체 밤위에서 사용할 때 프로그램을 꼬이게 할 뿐입니다. 심지어는 GCC 설명서en에서도 -funroll-loops와 -funroll-all-loops 플래그는 코드를 더욱 크게 만들고 더 느리게 동작한다고 이야기합니다. 이런 문제 때문에, 이들 두 플래그에, -ffast-math, -fforce-mem, -fforce-addr와 같은 플래그 등을 붙이는 것이 허풍떨기 좋아하는 이들 사이에서 잘 알려진 이야기일 것입니다.

사실은 이런 플래그 추가 사용이 굉장히 무모한 행위라는 점입니다. 어떤 플래그가 무슨 역할을 하는지에 대해서는 바람직한 젠투 포럼en 과 버그질라en 에서 확인해보십시오. 좋을게 하나도 없습니다!

CFLAGS 또는 CXXFLAGS에서 시스템 전체적으로 이 플래그를 사용할 필요는 없습니다. 전체적으로 사용하면 성능만 떨어뜨릴 뿐입니다. 최첨단의 고성능 시스템을 만들 것 같지만 아무 효과가 없으며, 코드를 부풀리고 잘못된 버그(INVALID) 내지는 고치지 않을 버그(WONTFIX)로 처리됩니다.

이런 위험한 플래그는 필요하지 않습니다. 사용하지 마십시오. 기본 플래그 -march, -O, -pipe에 집착하십시오.

3 보다 높은 -O 레벨은 어떤가요?

어떤 사용자는 -O4, -O9 등의 플래그를 사용하여 더 나은 성능으로 끌어올렸다고 자랑하기까지 합니다만, 실제로는 3보다 큰 -O 레벨은 효과가 없습니다. -O4와 같은 CFLAGS를 컴파일러가 받아들이겠지만, 실제로는 이들 플래그가 하는 일은 없습니다. -O3 이상의 플래그는 그 이상의 최적화를 수행하지 않습니다.

증명이 좀 더 필요한가요? 소스 코드를 시험해보십시오:

코드 -O 소스 코드
if (optimize >= 3)
    {
      flag_inline_functions = 1;
      flag_unswitch_loops = 1;
      flag_gcse_after_reload = 1;
      /* Allow even more virtual operators.  */
      set_param_value ("max-aliased-vops", 1000);
      set_param_value ("avg-aliased-vops", 3);
    }

보신 바와 같이, 3보다 큰 값은 -O3 처럼 취급합니다.

대상 머신이 아닌곳에서 컴파일은 어떤가요?

일부 독자들은 명백하게 저질인 CPU가 달린 대상 머신 이외의 머신이나 GCC 하위 아키텍처에서 컴파일하면 (자체적으로 컴파일하는 과정에 비해) 저질 최적화가 되는지 궁금해하실텐데, 간단하게 말씀드리자면 아닙니다. 컴파일한 실제 하드웨어가 어딘지, GCC가 빌드할 CHOST 값이 어떤지와는 상관 없이 (-march=native는 제외한) 비슷한 길이의 인자를 사용하며 동일한 GCC 버전을 사용하여(마이너 버전은 차이가 있을지 모르겠지만), 최적화 결과는 완전히 동일합니다.

예시를 하나 들어보자면 GCC CHOST값이 i686-pc-linux-gnu인 머신에 젠투를 설치했고, GCC의 CHOST값이 i486-linux-gnu인 다른 컴퓨터에 DiscCC 서버를 설정했다면, 원격 컴파일러 또는 하드웨어의 하위 아키텍처가 저질이라 결과가 덜 이상적일지도 모른다는 걱정을 하지 않아도 됩니다. 결과는 각 컴파일러에 동일한 옵션을 전달(하고 -march 매개변수에 native 인자를 전달하지 않으므로)자체 빌드 결과물 만큼 최적화 처리 됩니다. 이런 경우 대상 아키텍처는 DistCC와 -march=native에 설명한 대로 분명하게 지정해야합니다.

다른 하위 아키텍처를 대상으로 빌드한 두 GCC 버전의 동작상 유일한 차이점이 있다면, 명령줄에서 분명하게 전달하지 않을 때, GCC의 CHOST 에서 전달하는 -march 매개변수에 기본 인자를 생략한다는 점입니다.

중복 플래그는 무엇인가요?

종종 다양한 -O 레벨로 맞춰놓은 CFLAGS 와 CXXFLAGS 값은 /etc/portage/make.conf에 중복 지정되어 있습니다. 가끔은 무시하는걸로 끝나지만, 플래그를 걸러내거나 플래그를 바꾸는 일을 막아주기도 합니다.

포티지 트리에서 대부분의 이빌드가 플래그를 걸러내거나 바꿉니다. 어떤 -O 레벨에 대해서는 꾸러미에서 컴파일 오류가 나거나 추가 플래그를 사용했을 경우 소스코드가 민감하게 동작하기 때문에 이렇게 처리합니다. 이빌드는 CFLAGS와 CXXFLAGS 둘 중 하나 또는 전부를 걸러내거나, -O 레벨을 다른 레벨로 바꿉니다.

젠투 개발자 설명서en에서는 플래그 필터링/바꿔치기 작업을 하는 위치와 방법을 다룹니다.

다음처럼 -O3 같은 플래그를 각 레벨에 대해 반복해서 나열하면 -O 필터링을 피해살 수 있습니다:

코드 중복 CFLAGS 지정
CFLAGS="-O3 -finline-functions -funswitch-loops"

그러나 이건 현명한 방법이 아닙니다. CFLAGS를 어떤 이유로 무시할 수 있습니다. 플래그를 가려 인식하면, 해당 플래그로 구러미를 빌드하는것이 안전하지 않음을 의미합니다. 분명하게 말해서 어떤 꾸러미에 대해 -O3 레벨로 플래그를 활성화하면 문제가 생길 경우, 이 레벨로 전체 시스템을 컴파일 하는게 안전하지 않다는 의미가 됩니다. 그러니, 꾸러미를 관리하는 개발자보다 "앞서 나가려" 하지 마십시오. "개발자를 믿으십시오". 플래그를 선별하고 대체하는건 이미 시스템 및 프로그램의 안정화 확보를 목적으로 끝냈습니다! 이빌드에 다른 플래그를 정의했다면 다른곳에 넣으려 하지 마십시오.

허용할 수 없는 플래그로 꾸러미를 빌드하면 거의 대부분 문제 상황으로 끌려갑니다. 버그질라에 이 문제를 보고할 때면, /etc/portage/make.conf에 사용한 플래그가 분명히 나타나며, 누군가는 해당 플래그를 빼고 다시 컴파일하라고 알려줄겁니다. 처음에 언급한대로 중복 플래그를 빼서 다시 컴파일하는일이 없도록 하십시오! 개발자들보다 여러분이 더 잘 알거라고 멋대로 판단하지 마십시오.

LDFLAGS란 무엇인가요?

젠투 개발자는 기본적이고 안전한 LDFLAGS 값을 기반 프로파일에 설정했으므로, 바꿀 필요가 없습니다.

패키지별로 플래그를 사용해도 되나요?

경고
패키지별로 플래그를 사용하면 디버그와 지원이 복잡해질 수 있습니다. 버그 보고서 작성시 사용한 기능과 바꾼 부분의 언급 여부를 확인하십시오.

패키지별 환경 변수 사용법(CFLAGS 포함)은 젠투 핸드북, "꾸러미별 환경 변수"편에 설명했습니다.

Profile Guided Optimization (PGO)

Profile guided optimization (PGO) consists of compiling and profiling a program to assess hot paths in the code. Optimizations are then applied based on this analysis. Specifically, the code is compiled with -fprofile-generate, which instrument the code. Second, the code is run with applications to collect profile information. Finally, using the profiled data, the code is compiled with -fprofile-use. To manually enable PGO for packages, see this link.

Firefox also supports PGO although sometimes it may break the build.

Link Time Optimization (LTO)

참고
LTO heavily increases compile times and if changing even one object file when compiling, LTO recompiles the whole code again. There is a ongoing GSoC project to make sure LTO only recompiles what it deems necessary.

LTO is still experimental. LTO may need to be disabled before reporting bugs because it is a common source of problems. The -flto flag is used, with an optional auto argument (Detects how many jobs to use) or a integer argument (An integer number of jobs to execute parallel).

See the LTO article for more information on LTO on Gentoo.

See also

자료

다음 자료는 최적화에 대해 더 이해하는데 도움이 될 것입니다:

References

  1. ↑ GNU GCC Bugzilla, AVX/AVX2 no ymm registers used in a trivial reduction. Retrieved on 2017/07/18.
  2. ↑ GNU GCC Bugzilla, 'gcc -marc=native' sets L2 cache size equal to L3 cache size on i7 and i5 CPU. Retrieved on 2022/08/14.
  3. ↑ New 17.0 profiles in the Gentoo repository
  4. ↑ https://en.wikipedia.org/wiki/Full-employment_theorem
  5. ↑ https://gcc.gnu.org/install/build.html


This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document:
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.

Retrieved from "https://wiki.gentoo.org/index.php?title=GCC_optimization/ko&oldid=1289739"