-O3 최적화로 GNU / Linux 컴파일

-O3gcc 최적화 옵션 을 사용하여 GNU 도구와 Linux 커널을 컴파일 하면 이상하고 펑키 한 버그가 발생 한다고합니다 . 사실인가요? 아무도 그것을 시도 했습니까 아니면 그냥 사기입니까?

젠투에서 사용되었으며 이상한 점은 발견되지 않았습니다.

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

1. 우선 -O2또는 보다 더 느린 코드를 생성합니다 -Os. 때로는 루프 언 롤링으로 인해 더 긴 코드를 생성하는데, 이는 코드의 캐시 성능 저하로 인해 실제로 느려질 수 있습니다.
2. 말했듯이 때로는 잘못된 코드를 생성합니다. 최적화의 오류 또는 코드의 오류 (예 : 엄격한 앨리어싱 무시)로 인한 것일 수 있습니다. 커널 코드가 때로는 '스마트'해야하므로 일부 커널 개발자가 오류를 범했을 가능성이 있습니다. gcc 4.5로 커널을 컴파일 할 때 사용자 공간 유틸리티 충돌과 같은 다양한 이상한 문제가 발생했습니다. 커널에 gcc 4.4를 사용하고 다양한 버그로 인해 선택된 여러 사용자 공간 유틸리티를 사용합니다. 에도 동일하게 적용될 수 있습니다 -O3.
3. 나는 그것이 리눅스 커널에 많은 이점을 제공한다고 생각하지 않습니다. 커널은 많은 계산을하지 않으며, 장소에 따라 어셈블리에 최적화되어 있습니다. -O3플래그는 컨텍스트 전환 비용이나 I / O 속도를 변경 하지 않습니다 . 전체 성능의 <0.1 % 속도 향상과 같은 것이 가치가 있다고 생각하지 않습니다.

최적화 수준을 변경하면 툴체인의 큰 덩어리 (특히 glibc) 플랫 아웃이 컴파일되지 않습니다. 빌드 시스템은 대부분의 깔끔한 배포판에서 이러한 섹션에 대한 -O 기본 설정을 무시하도록 설정되어 있습니다.

간단히 말해서, 특정 기본 라이브러리 및 OS 기능은 코드가 실제로 수행하는 코드에 달려 있으며 많은 경우 더 빠를 것이 아닙니다. 특히 -fgcse-re-reload (-O3로 활성화)는 이상한 문제를 일으킬 수 있습니다.

지난 10 년 동안 저는 -O3 -march=native전 세계적으로 1000 개 이상의 패키지를 사용하여 여러 젠투 시스템을 운영해 왔지만 아직까지도 이러한 신화적인 안정성 문제 -O3는 발생하지 않았습니다 . 수학 / 과학 응용 프로그램과 같은 CPU 집약적 응용 프로그램의 벤치 마크는 -O3더 빠른 코드를 생성하는 것을 지속적으로 보여줍니다 . 그렇지 않으면 의미가 없습니다. 대부분의 데스크톱 응용 프로그램 CFLAGS은 IO 바인딩이기 때문에 중요하지 않지만 CPU 바인딩 된 서버 쪽 작업에는 중요합니다.

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

대부분의 응용 프로그램에서 -O3 및 기타 최적화 노브를 사용하여 벗어날 수 있지만 속도가 향상 될 수 있지만 커널 자체 또는 빌드에 필요한 도구 체인 (컴파일러, binutils, 기타.).

생각해보십시오 : 시스템 충돌 또는 잠재적 인 데이터 손실 및 / 또는 손상 가치가있는 raid 및 ext3 하위 시스템의 5 % 성능 향상입니까?

재생중인 해당 Quake 포트 또는 DVD 모음을 divx 파일로 리핑하는 데 사용하는 오디오 / 비디오 코덱에 대해 원하는 모든 노브를 조정하십시오. 당신은 아마 개선을 볼 수 있습니다. 낭비 할 시간이없고 손실 할 수있는 데이터가 없다면 커널을 망칠 필요가 없습니다.