코드 최적화

최적화 방법이 준수해야하는 기본 요구 사항은 최적화 된 프로그램이 비 최적화 버전과 동일한 출력 및 부작용을 가져야한다는 것입니다. 그러나 이 요구 사항은 최적화의 이점이 프로그램 동작의 변경으로 인해 발생할 수 있는 결과보다 더 중요한 것으로 추정되는 경우 무시될 수 있습니다.

최적화 유형 및 레벨

최적화는 자동 최적화 프로그램 또는 프로그래머가 수행할 수 있습니다. 최적화 프로그램은 특수 소프트웨어 도구 또는 컴파일러의 내장 단위(소위 최적화 컴파일러)입니다. 최신 프로세서는 코드 명령어의 실행 순서를 최적화 할 수도 있습니다.

최적화는 상위 레벨 및 하위 레벨 최적화로 분류됩니다. 높은 수준의 최적화는 일반적으로 추상 엔티티(함수,프로 시저,클래스 등)를 처리하는 프로그래머가 수행합니다.)및 시스템의 설계를 최적화하기 위해 마음에 작업의 일반적인 프레임 워크를 유지합니다. 최적화는 소스 코드의 기본 구조 블록(루프,분기 등)수준에서 수행됩니다. -일부 저자는 별도의(“중간”)수준으로 분류하는 동안 일반적으로 너무 높은 수준의 최적화라고(엔.워스?). 낮은 수준의 최적화는 소스 코드가 일련의 기계 명령어로 컴파일되는 단계에서 수행되며,이 단계에서는 일반적으로 자동 최적화가 사용됩니다. 그러나 어셈블러 프로그래머는 숙련 된 프로그래머보다 완벽한 기계가 이것을 더 잘 할 수는 없다고 생각합니다(그러나 가난한 프로그래머가 컴퓨터보다 훨씬 더 나빠질 것이라는 데 모두 동의합니다).

최적화 할 내용

수동 코드 최적화를 사용하면 최적화가 정확히 어떻게 수행되어야하는지 알아야 할뿐만 아니라 프로그램의 특정 부분을 최적화해야 하는지를 알 필요가 있습니다. 여러 가지 이유(느린 입력 작업,작업자와 컴퓨터의 작업 속도의 차이 등)로 인해 프로그램 실행 시간의 90%는 코드의 10%만 실행하는 데 소비됩니다(이 진술은 다소 투기 적이며 파레토 원리는 매우 의심스러운 근거이지만 타넨 바움은 설득력있게 들립니다). 최적화는 프로그램 개발에 소요되는 시간을 제외하고 추가 시간이 걸리므로 전체 프로그램을 최적화하는 것보다 시간이 중요한 10%의 코드를 최적화하는 데 집중하는 것이 좋습니다. 이러한 코드 조각은 병목 현상으로 알려져 있으며 프로그램의 여러 부분이 실행하는 데 걸리는 시간을 측정 할 수있는 특수 유틸리티(프로파일 러)에 의해 감지 될 수 있습니다.

그러나 실제로 최적화는 일반적으로”혼란스러운”프로그래밍 단계(“복사-붙여 넣기”,”나중에 볼 것”,”이 방법은 괜찮습니다”와 같은 방법 포함)후에 수행되므로 최적화가 혼합되어 있습니다.이 방법은 다음과 같습니다.=0&&=0),등등. 프로파일 러는 이러한 종류의 최적화에 거의 도움이되지 않습니다. 그럼에도 불구하고 정적 분석 도구,즉 소스 코드의 심층 분석에 의존하는 의미 오류를 검색하도록 설계된 도구를 사용하여 이러한 문제를 감지 할 수 있습니다. 이상한 조건을 가진 위에서 언급 한 예에서 볼 수 있듯이 비효율적 인 코드는 오류의 결과로 나타날 수 있습니다.=0&&=0 대신해야한다). 강력한 정적 분석기는 이러한 코드 조각을 감지하고 경고 메시지를 생성하여 관심을 끌 것입니다.

최적화의 좋고 나쁜 결과

프로그래밍에서는 거의 모든 것이 합리성의 관점에서 다루어 져야한다. 미숙 한 어셈블러 프로그래머가 작성한 코드는 컴파일러에서 생성 한 코드보다 3-5 배 느린다는 믿음이 있습니다. 널리 알려진 문구는 크 누스 초기 저수준 최적화(예:연산자 또는 변수 저장 시도):”조기 최적화는 모든 악의 뿌리”.

대부분의 프로그래머는 옵티마이저가 수행하는 최적화에 대해 불평하지 않으며 그 중 일부는 일반적이고 의무적입니다. 예를 들어,같은 기능 언어 꼬리 호출 최적화(꼬리 호출은 루프로 표현 될 수있다 재귀의 특별한 경우이다).

그러나 기계 코드 수준에서 여러 개의 복잡한 최적화가 컴파일을 크게 느리게 할 수 있음을 이해해야합니다. 일반적인 시스템 설계 최적화(워스)에 비해 그들이 당신이 얻을 수 있도록 혜택은 너무 중요하지 않을 수 있습니다. 또한 모든 구문 및 의미 론적”프릴”을 가진 현대 언어에는 많은 뉘앙스와 미묘함이 있으므로 익숙하지 않은 프로그래머는 최적화 결과에 놀랄 수 있음을 명심해야합니다.컴파일러는 함수에 의해 반환 된 임시 개체를 복사 방지 할 때,소위 반환 값 최적화. 컴파일러는 복사를 생략하기 때문에 이 메서드를”복사 제거”라고도합니다. 그래서,다음 코드:

#include <iostream> struct C { C() {} C(const C&) { std::cout << "A copy was made.\n"; }}; C f() { return C();} int main() { std::cout << "Hello World!\n"; C obj = f();}

여러 출력을 가질 수 있습니다:

Hello World!A copy was made.A copy was made.Hello World!A copy was made.Hello World!

이상하게 보일 수 있으므로 언어 표준이 이러한 경우 복사 생성자의 호출을 생략 할 수 있기 때문에 생성자가 부작용이있는 경우에도 세 가지 버전이 모두 유효합니다(12.8 클래스 객체 복사,단락 15).

결론

따라서 가능한 한 전문 유틸리티를 사용하여 프로그램 코드를 최적화하는 것을 항상 고려해야하지만 많은주의를 기울여이 작업을 수행하고 컴파일러에서 예기치 않은 트릭이 발생할 가능성에 대비해야합니다.따라서 코드를 최적화할 수 있는 몇 가지 상황을 찾을 수 있습니다. 그러나 다른 정적 분석기는 프로파일링 도구를 대체할 수 없습니다. 동적 프로그램 분석기 만 병목 현상을 식별 할 수 있습니다. 정적 분석기는 입력 데이터 프로그램이 얻는 것과 특정 코드 조각이 실행되는 빈도를 알지 못합니다. 그래서 우리는 분석기가 성능 향상을 보장하지 않는 코드의 일부”마이크로 최적화”를 구현할 것을 제안한다고 말하고 있습니다.

고려 된 단점에도 불구하고 프로파일 링 도구를 보완하는 역할을 수행합니다. 또한 최적화와 관련된 경고를 처리 할 때 코드가 더 간단하고 짧아지는 경우가 많습니다. 이 효과는”타 이젠 코드를 예로 사용하여 마이크로 최적화 탐색”기사에서 더 자세히 고려됩니다.