GNU 도구 및 Linux 커널을 -O3
gcc 최적화 옵션은 이상하고 펑키 한 버그를 생성합니다. 사실인가요? 누구든지 그것을 시도 했습니까 아니면 단지 사기입니까?
Gentoo에서 사용되었으며 특이한 점을 발견하지 못했습니다.
-O3
에는 몇 가지 단점이 있습니다.
-O2
또는 -Os
보다 느린 코드를 생성하는 경우가 많습니다. 때때로 루프 언 롤링으로 인해 더 긴 코드를 생성하는데, 이는 코드의 캐시 성능 저하로 인해 실제로 느려질 수 있습니다.-O3
에도 동일하게 적용될 수 있습니다.-O3
플래그는 컨텍스트 전환 비용 또는 I/O 속도를 not 변경합니다. 전체 성능의 0.1 % 미만 속도 향상과 같은 것은 그만한 가치가 없다고 생각합니다.도구 체인 (특히 glibc)의 큰 덩어리는 최적화 수준을 변경하면 컴파일되지 않습니다. 빌드 시스템은 대부분의 정상적인 배포판에서 이러한 섹션에 대한 -O 기본 설정을 무시하도록 설정되어 있습니다.
간단히 말해서, 특정 기본 라이브러리 및 OS 기능은 많은 경우에 더 빠를 것이 아니라 실제로 말하는 것을 수행하는 코드에 따라 달라집니다. 특히 -fgcse-after-reload (-O3에 의해 활성화 됨)는 이상한 문제를 일으킬 수 있습니다.
지난 10 년 동안 저는 전 세계적으로 -O3 -march=native
를 사용하여 1000 개 이상의 패키지로 여러 젠투 시스템을 실행 해 왔지만 -O3
가 가져야 할 이러한 신화적인 안정성 문제에 아직 부딪히지 않았습니다. CPU 집약적 인 애플리케이션 (예 : 수학/과학 앱)의 벤치 마크는 더 빠른 코드를 생성하기 위해 지속적으로 -O3
를 보여줍니다. 그렇지 않으면 결국 무의미합니다. 대부분의 데스크톱 앱 CFLAGS
은 IO 바운드이기 때문에별로 중요하지 않습니다.하지만 CPU 바운드 인 서버 측 항목에서는 중요합니다.
-O3는 레지스터 사용, 스택 프레임이 상호 작용하는 방식 및 함수 재진입에 대한 특정 가정이 참인 경우에만 안전한 일부 공격적인 최적화를 사용하며 이러한 가정은 특히 인라인 어셈블리가있을 때 커널과 같은 일부 코드에서 참이 보장되지 않습니다. 사용됨 (커널 및 드라이버 모듈의 매우 낮은 수준의 일부에 있음).
대부분의 응용 프로그램에서 -O3 및 기타 최적화 노브를 사용하는 것을 피할 수 있지만 (그리고 할 수 있음 속도가 향상됨) 커널 자체 또는 필요한 도구 체인에서 이러한 조정을 사용하는 것은 주저합니다. 빌드 (컴파일러, binutils 등).
생각해보십시오. raid 및 ext3 하위 시스템의 5 % 성능 향상이 시스템 충돌이나 잠재적 인 데이터 손실 및/또는 손상의 가치가 있습니까?
재생중인 Quake 포트 또는 DVD 컬렉션을 divx 파일로 추출하는 데 사용하는 오디오/비디오 코덱에 대해 원하는 모든 노브를 조정하십시오. 개선 된 것을 볼 수있을 것입니다. 낭비 할 시간과 잃어 버릴 수있는 데이터가 없다면 커널을 엉망으로 만들지 마십시오.