-O3 최적화를 사용하여 GNU/Linux 컴파일

-O3몇 가지 단점이 있습니다:

1. 첫째, 생성되는 코드는 일반적 -O2으로 또는 -Os. 루프 풀림으로 인해 코드가 길어지는 경우도 있는데, 실제로는 코드의 캐싱 성능이 좋지 않아 속도가 느려질 수도 있습니다.
2. 말했듯이 때로는 잘못된 코드가 생성됩니다. 이는 최적화 오류 또는 코딩 오류(예: 엄격한 별칭 무시)로 인해 발생할 수 있습니다. 커널 코드는 때로는 "스마트"하고 때로는 "지능적"이어야 하기 때문에 일부 커널 개발자가 실수를 했을 수도 있습니다. 당시 안정적인 gcc 4.5를 사용하여 커널을 컴파일할 때 사용자 공간 유틸리티 충돌과 같은 온갖 종류의 이상한 문제에 직면했습니다. 다양한 버그로 인해 저는 여전히 커널에 gcc 4.4를 사용하고 있으며 몇 가지 선택된 사용자 공간 유틸리티를 사용하고 있습니다. 동일한 상황이 적용됩니다 -O3.
3. 나는 그것이 리눅스 커널에 많은 이점을 가져다 준다고 생각하지 않습니다. 커널은 과도한 계산을 수행하지 않으며 어셈블리 최적화 기능을 갖추고 있습니다. -O3플래그는아니요컨텍스트 전환 비용이나 I/O 속도를 변경합니다. 나는 0.1% 미만의 전체 성능 속도 향상이 그만한 가치가 있다고 생각하지 않습니다.

저는 지난 10년 동안 -O3 -march=native전 세계적으로 사용되는 1000개 이상의 패키지가 포함된 여러 Gentoo 시스템을 실행해 왔지만 아직 -O3발생해야 할 이러한 신비한 안정성 문제에 직면한 적이 없습니다. CPU 집약적인 애플리케이션(예: 수학/과학 애플리케이션)에 대한 벤치마크는 항상 더 빠른 코드가 생성될 수 있다는 것을 보여 주었습니다 -O3. 그렇지 않으면 아무 의미가 없습니다. 대부분의 데스크톱 응용 프로그램의 경우 CFLAGSIO 바인딩이므로 그다지 중요하지 않지만 CPU 바인딩된 서버 측 콘텐츠의 경우 중요합니다.

이는 Gentoo에서 사용되며 특이한 점은 보이지 않습니다.

-O3는 레지스터 사용, 스택 프레임 상호 작용 방식 및 함수 재진입에 대한 특정 가정이 참인 경우에만 안전한 일부 공격적인 최적화를 사용하며 이러한 가정은 커널과 같은 일부 코드에서 참이라고 보장되지 않습니다. 참, 특히 사용될 때 인라인 어셈블리에서(커널과 해당 드라이버 모듈의 매우 낮은 수준 부분에 있기 때문에)