GCC optimization/ko

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

CFLAGS와 CXXFLAGS란 뭔가요?
CFLAGS와 CXXFLAGS는 소스 코드를 컴파일할 때 어떤 종류의 스위치를 사용할지 GNU 컴파일러 모음( gcc )에 알려주는 환경 변수입니다. CFLAGS는 C로 작성한 코드용, CXXFLAGS는 C++로 작성한 코드용 변수입니다.

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

어떻게 사용하나요?
CFLAGS and CXXFLAGS can be used in two ways. First, they can be used per-program with Makefiles generated by automake.

그러나 포티지 트리에서 설치 패키지를 찾았을때는 이걸 활용할 수는 없습니다. 대신 의 CFLAGS와 CXXFLAGS를 설정합니다. 이 방식으로 여러분이 지정한 옵션을 사용하여 모든 패키지를 컴파일합니다.

보시는 바와 같이, CXXFLAGS는 CFLAGS에 나타나는 모든 옵션을 사용하는 집합입니다. 이 방식이야 말로 거의 별다른 문제 없이 처리하길 원하는 방법입니다. CXXFLAGS에 추가 옵션을 지정할 필요조차도 없습니다.

오해
CFLAGS와 CXXFLAGS는 소스 코드를 작고 동작이 빠른 바이너리로 만드는데 매우 효율적인 수단이 될 수 있음을 의미하기도 하지만, 코드 기능을 망가뜨리거나, 바이너리 크기를 키우기도 하고, 실행 시간을 늦추며, 심지어는 컴파일 실패를 야기하기도 합니다.

CFLAGS가 만병 통치약 같은건 아닙니다. 시스템을 자동적으로 좀 더 빠르게 동작하게 하거나 디스크상에서 바이너리가 적은 공간을 차지하게 하진 않습니다. 시스템을 최적화(또는 "성능을 좋게") 하려는 플래그를 추가하면 할수록 골로 가게 하는 확실한 방법이 됩니다. 그러니까 .. 성능을 감소시키는 시점이 있습니다.

인터넷에서 찾아보겠다고 큰소리 치실지 모르겠지만, CFLAGS와 CXXFLAGS를 과감하게 이것저것 설정하는 것은 오히려 좋은 상황으로 끌고가기 보다는 프로그램을 더욱 안좋게 할 수가 있습니다. 특별한 목적으로 특별한 시점에서 플래그를 사용하도록 설계한것이 처음 장소에 플래그가 존재하는 이유임을 기억하십시오. CFLAG 일부는 코드 일부에 좋을 뿐이지만 이것이 결코 머신에 설치하는 모든 컴파일 요소에 맞춰진 것임을 의미하는게 아닙니다.

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

기본
The goal behind using CFLAGS and CXXFLAGS is to create code tailor-made to your system; it should function perfectly while being lean and fast, if possible. Sometimes these conditions are mutually exclusive, so we'll stick with combinations known to work well. Ideally, they are the best available for any CPU architecture. We'll mention the aggressive flags later so you know what to look out for. We won't discuss every option listed on the gcc manual (there are hundreds), but we'll cover the basic, most common flags.

-march
The first and most important option is. This tells the compiler what code it should produce for your processor architecture (or arch); it says that it should produce code for a certain kind of CPU. Different CPUs have different capabilities, support different instruction sets, and have different ways of executing code. The  flag will instruct the compiler to produce code specifically for your CPU, with all its capabilities, features, instruction sets, quirks, and so on.

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

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

To get more details, including  and   values, use:

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

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

그래도 어떤 CPU를 쓰는지 모르겠다면, 아마 그냥 를 사용하고 싶을 것입니다. 이 플래그를 사용하면 GCC는 프로세서를 감지하고 자동으로 적당한 플래그를 설정합니다. 그러나 다른 CPU에서 사용할 패키지를 컴파일하려 한다면 이 플래그를 쓰면 안됩니다.

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

Also available are the  and   flags. These flags are normally only used when there is no available  option; certain processor architectures may require   or even. Unfortunately, gcc 's behavior isn't very consistent with how each flag behaves from one architecture to the next.

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

Only non-x86/x86-64 CPUs (such as Sparc, Alpha, and PowerPC) may require  or   instead of. On these architectures,  /   will sometimes behave just like   (on x86/x86-64)... but with a different flag name. Again, gcc 's behavior and flag naming just isn't consistent across architectures, so be sure to check the gcc manual to determine which one you should use for your system.

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

7가지의  레벨 설정 ,  ,  ,  ,  ,  ,  가 있습니다. 파일에서 이들 중 하나만을 사용해야 합니다.

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

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


 * : 이 레벨(글자"O" 다음에 숫자 영이 따라옴)은 최적화를 완전히 끄고, CFLAGS 또는 CXXFLAGS에  레벨을 기본으로 지정하지 않았을 경우에 기본값이 됩니다. 컴파일 시간을 줄이고 디버그 정보를 개선할 수 있지만, 어떤 프로그램은 최적화를 활성화 하지 않으면 제대로 동작하지 않는 수가 있습니다. 이 옵션은 디버깅 목적이 아니라면 사용하지 않는 것이 좋습니다.


 * : 이 레벨은 매우 기본적인 최적화를 수행합니다. 컴파일러는 더 많은 컴파일 시간을 소비하지 않고도 빠르고 작은 코드를 만들어냅니다. 좀 기본적일 수는 있지만 항상 컴파일 작업이 완료됩니다.


 * : 에서 한 단계 상승합니다. 특별하게 필요한 경우가 아닌 한 권장하는 최적화 레벨입니다.   플래그는   플래그로 활성화 한 플래그보다 더 많은 플래그를 활성화 합니다.   플래그로, 컴파일러에서는 바이너리 크기와의 절충 없이 무조건 코드 성능을 끌어올리여 하며, 컴파일 시간을 너무 많이 소비하지 않습니다.


 * : 가능한 가장 높은 최적화 레벨입니다. 컴파일 시간과 메모리 사용에 있어 그 이상의 최적화를 활성화합니다. 으로 컴파일 할 때는 성능을 개선한다는 보장이 없으며, 실제로 대부분의 경우, 바이너리가 커지고 메모리 사용량이 증가하여 시스템을 느리개 할 수 있습니다.  는 또한 몇가지 꾸러미를 깨뜨리는 걸로 알려져 있습니다. 따라서   플래그 사용을 권장하지 않습니다.


 * : 이 옵션은 코드 크기를 최적화 합니다. 만든 코드의 크기가 늘어나지 않게 하는 모든  옵션을 활성화 합니다. 매우 제한된 디스크 저장소 공간을 가지고 있거나 CPU의 캐시 크기가 작을 경우 유용합니다.


 * : GCC4.8에 새로운 일반 최적화 레벨 를 도입했습니다. 빠른 컴파일을 필요로 하며 실행시간 성능의 타당한 수준을 제공하면서 우수한 디버깅 경험을 할 수 있게 바로 잡았습니다. 개발에 있어 전체적인 경험은 기본 최적화 레벨  보단 낫습니다. 참고로  는  를 의미하지 않으며, 디버깅에 혼란을 주는 최적화 기능을 끌 뿐입니다.


 * : GCC 4.7에서 새로 도입했으며,,   ,  , and  로 이루어져 있습니다. 이 옵션은 엄격한 표준 준수를 깨며, 사용을 권장하지 않습니다.

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

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

-fomit-frame-pointer
This is a very common flag designed to reduce generated code size. It is turned on at all levels of  (except  ) on architectures where doing so does not interfere with debugging (such as x86-64), but you may need to activate it yourself by adding it to your flags. Though the gcc manual does not specify all architectures it is turned on by using, you will need to explicitly activate it on x86, with gcc up to version 4.6 or when using. However, using this flag will make debugging hard to impossible.

In particular, it makes troubleshooting applications written in Java much harder, though Java is not the only code affected by using this flag. So while the flag can help, it also makes debugging harder; backtraces in particular will be useless. However, if you don't plan to do much software debugging and haven't added any other debugging-related CFLAGS such as, then you can try using.

-msse, -msse2, -msse3, -mmmx, -m3dnow
These flags enable the SSE, SSE2, SSE3, MMX, and 3DNow! instruction sets for x86 and x86-64 architectures. These are useful primarily in multimedia, gaming, and other floating point-intensive computing tasks, though they also contain several other mathematical enhancements. These instruction sets are found in more modern CPUs.

You normally don't need to add any of these flags to as long as you are using the correct   (for example,   implies  ). Some notable exceptions are newer VIA and AMD64 CPUs that support instructions not implied by  (such as SSE3). For CPUs like these you'll need to enable additional flags where appropriate after checking the output of.

근데 -funroll-loops -fomg-optimize로 성능이 더 좋아졌는데요?!
No, you only think you do because someone has convinced you that more flags are better. Aggressive flags will only hurt your applications when used system-wide. Even the gcc manual says that using  and   makes code larger and run more slowly. Yet for some reason, these two flags, along with,  ,  , and similar flags, continue to be very popular among ricers who want the biggest bragging rights.

The truth of the matter is that they are dangerously aggressive flags. Take a good look around the Gentoo Forums and Bugzilla to see what those flags do: nothing good!

You don't need to use those flags globally in CFLAGS or CXXFLAGS. They will only hurt performance. They may make you sound like you have a high-performance system running on the bleeding edge, but they don't do anything but bloat your code and get your bugs marked INVALID or WONTFIX.

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

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

Need more proof? Examine the source code:

보시는 바와 같이 3보다 큰 값은  처럼 취급합니다.

대상 머신이 아닌곳에서 컴파일은 어떤가요?
Some readers might wonder if compiling outside the target machine with a strictly inferior CPU or GCC sub-architecture will result in inferior optimization results (compared to a native compilation). The answer is simple: No. Regardless of the actual hardware on which the compilation takes place and the CHOST for which GCC was built, as long as the same arguments are used (except for ) and the same version of GCC is used (although minor version might be different), the resulting optimizations are strictly the same.

To exemplify, if Gentoo is installed on a machine whose GCC's CHOST is i686-pc-linux-gnu, and a Distcc server is setup on another computer whose GCC's CHOST is i486-linux-gnu, then there is no need to be afraid that the results would be less optimal because of the strictly inferior sub-architecture of the remote compiler and/or hardware. The result would be as optimized as a native build, as long as the same options are passed to both compilers (and the  parameter doesn't get a   argument). In this particular case the target architecture needs to be specified explicitly as explained in Distcc and -march=native.

The only difference in behavior between two GCC versions built targeting different sub-architectures is the implicit default argument for the  parameter, which is derived from the GCC's CHOST when not explicitly provided in the command line.

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

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

The Gentoo Developer Manual outlines where and how flag filtering/replacing works.

It's possible to circumvent  filtering by redundantly listing the flags for a certain level, such as , by doing things like:

However, this is not a smart thing to do. CFLAGS are filtered for a reason! When flags are filtered, it means that it is unsafe to build a package with those flags. Clearly, it is not safe to compile your whole system with  if some of the flags turned on by that level will cause problems with certain packages. Therefore, you shouldn't try to "outsmart" the developers who maintain those packages. Trust the developers. Flag filtering and replacing is done for your benefit! If an ebuild specifies alternative flags, then don't try to get around it.

You will most likely continue to run into problems when you build a package with unacceptable flags. When you report your troubles on Bugzilla, the flags you use in will be readily visible and you will be told to recompile without those flags. Save yourself the trouble of recompiling by not using redundant flags in the first place! Don't just automatically assume that you know better than the developers.

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

패키지별로 플래그를 사용해도 되나요?
Information on how to use per-package environment variables (including CFLAGS) is described in the Gentoo Handbook, "Per-Package Environment Variables".

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


 * GCC 온라인 문서


 * Chapter 5 of the Gentoo Installation Handbooks


 * man make.conf


 * 위키피디아


 * 젠투 포럼