gcc의 최적화 옵션은 크게 4가지입니다
1.그냥 최적화 안 함
2. -O2 적당한 속도 최적화 적당한 크기 최적화
3. -O3 속도위주 최적화
4. -Os 크기 최적화
1.은 그냥 말그대로 최적화따위 없이 코드를 컴파일한 그대로 써먹겠다는 겁니다. inline으로 도배가 되어있거나 수동으로 최적화가 되어있는 방식이면 이걸 쓰는게 훨씬 효율적입니다.
2. 일반적인 옵션입니다. 보통은 이걸 쓴다고 보면 됩니다. 분기나 함수호출이 줄줄이 있다면 함수하나에 몰아넣거나 분기를 최대한 줄이는 등의 최적화를 합니다.
최적화로 인한 오류는 거의 없습니다.
3. 속도를 위해 최적화 하는 방식입니다. 파일크기를 희생해서 속도를 올립니다. O2에서 쓰는 최적화는 물론이고 자체적으로 지저분한 코드를 더 빠른 코드로 갈아치우기도 합니다. 대신 파일크기가 커지기 때문에 도리어 캐시메모리가 모자라 O2보다 느려지기도 하며 코드를 바꾸다가 오류를 일으키기도 합니다.
4. 그냥 작은 용량을 위해 쓰는 옵션입니다.
코딱지만한 임베디드쪽에서 주로 사용합니다. O2에서 MB단위였던게 KB단위로 만들어지는 기염을 토하기도 합니다.
다만 O3같은 생각지 못 한 오류가 드물게 있습니다.
보통 일반적인 코드는 O2를 이용해서 처리합니다. O3도 사실 오류가 있을 수 있다고 했지만 진짜 오류가 생기는 경우는 매우 드뭅니다. 그래서 요즘은 O3로 하는 경우도 많습니다.
요즘은 기본적으로 디스크가 남아돌아서 Os를 PC에서 쓰는경우는 거의 없고 대부분 임베디드장치에서 씁니다. 그리고 실행속도가 느려지기 때문에 (함수 내부 코드가 겹친다 싶으면 그걸 또 쪼개서 호출하기 때문에 매우 복잡해집니다) 속도가 중요한 임베디드 기기에서도 잘 안 씁니다.
그 외에 -O1도 있지만 이건 쓰는걸 보기 힘들군요.
아무튼 궁금해진차에
그래서 리눅스 커널을 O2 O3로 최적화해서 각각 돌려본 결과
정말 무의미한 속도차이만이 있었습니다. (실제 벤치마크를 돌리면 O3가 미묘하게 빠르다곤 합니다. 그런데 오차범위 이내 수준)
리눅스 커널 컴파일의 기본옵션이 O2인것은 다 이유가 있던겁니다.
혹시나 Os로도 해봤는데 커널이미지의 크기는 작아졌지만 역시 큰 차이는 없었습니다.
리눅스커널쯤 되면 크게 옵션에 의한 차이가 없는거 같습니다. 제가 임의로 짠 엉망진창 코드라면 달라질거 같은데 그것까지 하기엔 너무 귀찮군요.
'약간의 리눅스관련 고찰' 카테고리의 다른 글
| 보수적인 리눅서의 Wayland (0) | 2026.05.18 |
|---|---|
| 왜 데비안을 쓰는가 (8) | 2024.10.19 |
| 최근 마음에 들지 않는 레드햇 (0) | 2024.04.05 |
| VKD3D와 DXVK의 관계 (0) | 2024.02.04 |
| Lightdm 우분투처럼 고르는 방법 (1) | 2023.07.16 |
