프로그램 최적화

Program optimization

컴퓨터 과학에서 프로그램 최적화, 코드 최적화 또는 소프트웨어 최적화란 소프트웨어 시스템의 일부 측면이 보다 효율적으로 작동하거나 리소스를 [1]적게 사용하도록 소프트웨어 시스템을 수정하는 과정입니다.일반적으로 컴퓨터 프로그램은 보다 빠르게 실행되도록 최적화되거나 메모리 스토리지 또는 기타 자원을 적게 사용하여 작동하거나 전력을 적게 소비하도록 최적화될 수 있다.

일반

"최적화"라는 단어는 "최적화"와 같은 어원을 공유하지만, 최적화 프로세스가 진정으로 최적의 시스템을 생산하는 경우는 드물다.시스템은 일반적으로 절대적인 관점에서가 아니라 다른 가능한 메트릭과 대조되는 특정 품질 메트릭에 대해서만 최적화할 수 있다.그 결과 최적화된 시스템은 일반적으로 1개의 애플리케이션 또는 1명의 대상자에게만 최적화됩니다.메모리를 더 많이 소비하는 대신 프로그램이 일부 작업을 수행하는 데 걸리는 시간을 줄일 수 있습니다.메모리 용량이 많은 애플리케이션에서는 메모리 사용량을 줄이기 위해 의도적으로 느린 알고리즘을 선택할 수 있습니다.대부분의 경우 모든 경우에 잘 작동하는 "하나의 크기만 맞는" 설계가 없기 때문에 엔지니어는 가장 관심 있는 속성을 최적화하기 위해 균형을 잡습니다.또한 소프트웨어를 완전히 최적화하기 위해 필요한 작업(더 이상 개선할 수 없음)은 발생할 수 있는 이점에 대해 거의 항상 합당한 작업보다 더 많습니다.따라서 최적화 프로세스는 완전히 최적의 솔루션에 도달하기 전에 중단될 수 있습니다.다행히도, 가장 큰 개선이 프로세스 초기에 이루어지는 경우가 많습니다.

특정 품질 메트릭(실행 속도 등)에 대해서도 대부분의 최적화 방법은 결과만 개선할 뿐 최적의 출력을 산출할 가능성은 없습니다.최적화는 진정으로 최적의 출력을 찾는 과정입니다.

최적화 수준

최적화는 여러 수준에서 발생할 수 있습니다.일반적으로 레벨이 높을수록 영향이 크고 나중에 프로젝트에서 변경하기가 어려우며, 대폭적인 변경이나 변경이 필요한 경우 완전히 다시 작성해야 합니다.따라서 최적화는 일반적으로 높은 것에서 낮은 것으로 개선하여 진행되며, 초기 이익은 더 크고 더 적은 작업으로 달성되며, 이후 이익은 더 작아지고 더 많은 작업이 요구됩니다.단, 전체 퍼포먼스는 프로그램의 매우 낮은 수준의 퍼포먼스에 좌우되는 경우가 있습니다.또, 늦기 단계에서의 작은 변경이나 낮은 수준의 상세 내용에 대한 조기 검토가 큰 영향을 미칠 수 있습니다.일반적으로 프로젝트 전체의 효율성은 어느 정도 고려되지만(이는 매우 다양하지만), 주요 최적화는 늦어도 개선해야 할 사항으로 간주되는 경우가 많습니다.장기간에 걸친 프로젝트에서는 일반적으로 최적화 사이클이 있습니다.이 사이클에서는 한 영역을 개선하면 다른 영역에 제약이 있음을 알 수 있습니다.이 사이클은 일반적으로 퍼포먼스가 허용 가능하거나 이득이 너무 적거나 비용이 많이 드는 경우에 삭감됩니다.

퍼포먼스는 프로그램 사양의 일부입니다.비상적으로 느린 프로그램은 목적에 적합하지 않습니다.60Hz(초당 프레임 수)의 비디오 게임은 허용되지만 초당 6프레임의 비디오 게임은 허용할 수 없을 정도로 불안정합니다.퍼포먼스는 시스템이 충분한 퍼포먼스를 제공할 수 있도록 처음부터 고려해야 합니다.시제품은 (최적화를 통해) 최종 시스템이 허용 가능한 성능을 달성할 것이라는 확신이 있으려면 대략 허용 가능한 성능을 가져야 합니다.이것은 항상 나중에 최적화를 실시할 수 있기 때문에 생략되는 경우가 있습니다.그 결과, 프로토타입 시스템이 너무 느리고(대부분 크기 이상), 인텔 432(1981)와 같은 아키텍처상 퍼포먼스 목표를 달성할 수 없기 때문에 최종적으로 장애가 발생하는 시스템도 있습니다.Java(1995년)와 같이 HotSpot(1999년)를 통해서만 허용 가능한 성능을 달성했습니다.프로토타입과 생산 시스템 간의 성능 변화 정도, 최적화에 얼마나 순응하는지는 불확실성과 위험의 중요한 원천이 될 수 있습니다.

설계 수준

최고 수준에서는 주어진 목표, 제약조건 및 예상 사용/부하와 같은 가용 자원을 최대한 활용할 수 있도록 설계를 최적화할 수 있다.시스템의 아키텍처 설계는 그 성능에 막대한 영향을 미칩니다.예를 들어, 네트워크 지연이 전체 성능에 대한 주요 제약 조건인 네트워크 지연이 네트워크 트립을 최소화하도록 시스템이 최적화되어 여러 라운드 트립이 아닌 단일 요청(또는 푸시 프로토콜에서처럼 요청이 없는 경우)이 이상적입니다.설계 선택은 목적에 따라 달라집니다.컴파일러를 설계할 때 고속 컴파일러가 중요한 우선 사항이라면 원패스 컴파일러가 멀티패스 컴파일러보다 빠르지만(동일한 작업을 가정할 경우), 출력 코드 속도가 목표라면 느린 멀티패스 컴파일러가 더 오래 걸리더라도 목표를 더 잘 충족시킵니다.플랫폼과 프로그래밍 언어의 선택은 이 레벨에서 이루어지며, 이러한 언어를 자주 변경하면 완전한 재작성이 요구되지만 모듈러 시스템에서는 일부 컴포넌트만 재작성할 수 있습니다.예를 들어 Python 프로그램은 C의 성능에 중요한 섹션을 재작성할 수 있습니다.분산형 시스템에서는 설계 수준에서 아키텍처(클라이언트-서버, 피어-투-피어 등)의 선택이 이루어지며, 특히 모든 컴포넌트(오래된 클라이언트 등)를 동기화할 수 없는 경우에는 변경이 어려울 수 있습니다.

알고리즘 및 데이터 구조

전체 설계를 고려할 때 효율적인 알고리즘과 데이터 구조를 적절히 선택하고 이러한 알고리즘과 데이터 구조를 효율적으로 구현해야 합니다.설계 후에는 알고리즘과 데이터 구조의 선택이 프로그램의 다른 어떤 측면보다 효율성에 영향을 미칩니다.함수 정의에서 추상 데이터 유형을 사용하고 구체적인 데이터 구조 정의를 몇 군데로 제한함으로써 최소화할 수 있지만, 데이터 구조 가정과 그 성능 가정은 프로그램 전체에서 사용되기 때문에 일반적으로 데이터 구조를 변경하는 것은 알고리즘보다 어렵습니다.

알고리즘의 경우 이는 주로 알고리즘이 일정한 O(1), 로그 O(log n), 선형 O(n), 또는 경우에 따라서는 로그 선형 O(n log n)가 되도록 하는 것으로 구성됩니다(공간과 시간 모두).2차 복잡도 O(n2)의 알고리즘은 스케일링에 실패하며, 선형 알고리즘도 반복적으로 호출되면 문제를 일으키며, 가능하면 보통 상수 또는 로그로 대체됩니다.

점근적 성장 순서를 넘어서는, 점근적으로 느린 알고리즘이 점근적으로 빠른 알고리즘보다 빠를 수도 있고 작을 수도 있습니다(단순하기 때문에). 두 알고리즘이 모두 작은 입력에 직면했을 때, 그것은 현실에서 일어날 수 있습니다.대부분의 경우 하이브리드 알고리즘은 크기에 따라 이 트레이드오프 때문에 최고의 성능을 제공합니다.

성능을 향상시키는 일반적인 기술은 일을 피하는 것입니다.일반적인 경우 빠른 경로를 사용하여 불필요한 작업을 방지하여 성능을 향상시키는 것이 좋은 예입니다.예를 들어, 라틴어 텍스트에 대한 단순 텍스트 레이아웃 알고리즘을 사용하고, Devanagari와 같은 복잡한 스크립트에 대한 복잡한 레이아웃 알고리즘으로만 전환합니다.또 하나의 중요한 기술은 중복 계산을 회피하는 캐시, 특히 메모화입니다.캐싱의 중요성 때문에 시스템에는 많은 수준의 캐싱이 존재하기 때문에 메모리 사용으로 인한 문제 및 오래된 캐시로 인한 수정 문제가 발생할 수 있습니다.

소스 코드 수준

일반적인 알고리즘과 추상 머신에서의 그 실장 이외에, 구체적인 소스 코드 레벨의 선택은 큰 차이를 만들 수 있습니다.예를 들어 초기 C 컴파일러에서는while(1)보다 느렸다for(;;)무조건 루프를 위해서요.왜냐하면while(1)1을 평가한 후 그것이 사실인지 테스트하는 조건부 점프를 했다.for (;;)무조건적인 점프가 있었습니다.이것 같은 일부 최적화는 현재 컴파일러를 최적화함으로써 실행할 수 있습니다.이는 소스 언어, 타깃 머신 언어 및 컴파일러에 따라 다르며 이해하기 어렵거나 예측이 어렵거나 시간이 지남에 따라 변화할 수 있습니다.컴파일러와 머신 코드를 이해하는 것이 성능을 향상시킬 수 있는 중요한 부분입니다.루프 불변 코드 모션 및 반환값 최적화는 보조 변수의 필요성을 줄여주는 최적화의 예입니다. 또한 우회 최적화를 방지하여 성능을 더 빠르게 만들 수도 있습니다.

빌드 레벨

소스 레벨과 컴파일 레벨 사이에서 디렉티브와 빌드 플래그를 사용하여 각각 소스 코드와 컴파일러의 퍼포먼스 옵션을 조정할 수 있습니다.예를 들어 프리프로세서 정의를 사용하여 불필요한 소프트웨어 기능을 비활성화하거나 특정 프로세서 모델 또는 하드웨어 기능을 최적화하거나 분기를 예측하거나 할 수 있습니다.BSD의 포트나 Gentoo의 Portage와 같은 소스 기반 소프트웨어 배포 시스템은 이러한 형태의 최적화를 활용할 수 있습니다.

컴파일 레벨

최적화 컴파일러를 사용하면 실행 가능한 프로그램이 컴파일러가 예측할 수 있는 만큼 최적화되는 경향이 있습니다.

조립 수준

가장 낮은 수준에서, 특정 하드웨어 플랫폼을 위해 설계된 어셈블리 언어를 사용하여 코드를 작성하는 것은 프로그래머가 기계 명령의 완전한 레퍼토리를 이용할 경우 가장 효율적이고 콤팩트한 코드를 생성할 수 있습니다.임베디드 시스템에서 사용되는 많은 운영체제는 전통적으로 이러한 이유로 어셈블리 코드로 작성되어 왔습니다.프로그램(매우 작은 프로그램 제외)은 시간과 비용 때문에 처음부터 끝까지 어셈블리에서 작성되는 경우가 거의 없습니다.대부분은 고급 언어에서 어셈블리 및 수작업으로 컴파일되어 있습니다.효율성과 크기가 덜 중요한 경우, 큰 부분은 고급 언어로 작성될 수 있습니다.

최신 컴파일러의 최적화와 최신 CPU의 복잡성이 높아짐에 따라 컴파일러가 생성하는 것보다 효율적인 코드를 기술하는 것이 어려워졌습니다.또, 이 「최종」의 최적화 스텝을 필요로 하는 프로젝트는 거의 없습니다.

오늘날 작성된 많은 코드는 가능한 한 많은 기계에서 실행되도록 되어 있습니다.그 결과 프로그래머나 컴파일러가 새로운 CPU나 오래된 모델의 기호에 의해 제공되는 보다 효율적인 명령을 항상 이용하지는 않습니다.또, 이러한 순서를 사용하지 않고, 특정의 프로세서에 맞추어 조정된 어셈블리 코드는, 다른 프로세서에서는 최적이 아닌 경우가 있어, 코드의 다른 튜닝을 기대할 수 있습니다.

일반적으로 오늘날 프로그래머는 어셈블리 언어로 쓰는 것이 아니라 디어셈블러를 사용하여 컴파일러의 출력을 분석하고 컴파일러가 보다 효율적으로 컴파일될 수 있도록 높은 수준의 소스 코드를 변경합니다.또, 컴파일러가 비효율적인 이유를 이해할 수 있습니다.

실행 시간

저스트 인 타임 컴파일러는 런타임 데이터를 기반으로 컴파일 오버헤드를 감수하고 커스터마이즈된 머신 코드를 생성할 수 있습니다.이 기술은 최초의 정규 표현 엔진으로 거슬러 올라가며 Java HotSpot 및 V8 for JavaScript와 함께 널리 보급되었습니다.경우에 따라 적응형 최적화는 실제 입력 또는 기타 요인에 따라 파라미터를 동적으로 조정함으로써 정적 컴파일러의 능력을 초과하는 런타임 최적화를 실행할 수 있다.

프로파일 가이드의 최적화는 런타임프로파일에 기초한 사전(AOT) 컴파일 최적화 기술로 적응형 최적화의 동적 기법의 정적 "평균 사례"와 유사합니다.

코드를 최적화하기 위해 자체 수정 코드는 런타임 조건에 따라 변경될 수 있습니다. 이는 어셈블리 언어 프로그램에서 더 일반적입니다.

일부 CPU 설계에서는 런타임에 일부 최적화를 수행할 수 있습니다.예를 들어 순서가 다른 실행, 추측 실행, 명령 파이프라인 및 분기 예측 변수가 있습니다.컴파일러는 예를 들어 명령 스케줄링을 통해 프로그램이 이러한 CPU 기능을 활용할 수 있도록 지원합니다.

플랫폼 의존 및 독립 최적화

코드 최적화는 플랫폼에 의존하는 기술과 플랫폼에 의존하지 않는 기술로 크게 분류할 수도 있습니다.후자는 대부분의 플랫폼 또는 모든 플랫폼에서 유효하지만 플랫폼에 의존하는 기술은 하나의 플랫폼의 특정 속성을 사용하거나 단일 플랫폼 또는 단일 프로세서에 따라 파라미터에 의존합니다.따라서, 다른 프로세서에 대해서, 같은 코드의 다른 버전의 기입이나 작성이 필요한 경우가 있습니다.예를 들어 컴파일레벨 최적화의 경우 플랫폼에 의존하지 않는 기술은 일반적인 기술(루프 언롤링, 함수 호출 감소, 메모리 효율이 높은 루틴, 조건 감소 등)로 대부분의 CPU 아키텍처에 동일한 방식으로 영향을 미칩니다.플랫폼에 의존하지 않는 최적화의 좋은 예가 inner for loop과 함께 나타나 있습니다.inner for loop이 있는 루프는 inner while loop이 없는 루프 또는 inner while [2]loop이 있는 루프보다 유닛 시간당 더 많은 계산을 수행하는 것이 관찰되었습니다.일반적으로 이러한 기능은 프로그램을 완료하기 위해 필요한 총 명령 경로 길이를 줄이거나 프로세스 중 총 메모리 사용량을 줄이는 데 도움이 됩니다.한편 플랫폼에 의존하는 기술은 명령 스케줄링, 명령 수준의 병렬화, 데이터 수준의 병렬화, 캐시 최적화 기술(즉, 다양한 플랫폼 간에 다른 파라미터)과 최적의 명령 스케줄링이 동일한 아키텍처의 다른 프로세서에서도 다를 수 있습니다.

강도 저하

계산 태스크는 다양한 효율로 여러 가지 방법으로 수행할 수 있습니다.동등한 기능을 갖춘 보다 효율적인 버전을 강도 감소라고 합니다.예를 들어, 다음 C 코드 스니펫을 생각해 봅시다.이 코드 스니펫의 목적은 1부터1까지의 모든 정수의 합을 구하는 것입니다.N:

인트 i, 합 = 0; 위해서 (i = 1; i <=> N; ++i) {   합 += i; } 인쇄물("합계: %d\n", 합);

이 코드는 (산술 오버플로우가 없다고 가정하고) 다음과 같은 수학 공식을 사용하여 다시 작성할 수 있습니다.

인트 합 = N * (1 + N) / 2; 인쇄물("합계: %d\n", 합);

최적화 컴파일러에 의해 자동으로 실행되는 최적화는 동일한 기능을 유지하면서 보다 계산적으로 효율적인 방법(알고리즘)을 선택하는 것입니다.이러한 기술의 일부에 대해서는, 알고리즘의 효율을 참조해 주세요.그러나 종종 관련 없는 기능을 제거함으로써 성능을 크게 개선할 수 있습니다.

최적화가 항상 명확하거나 직관적인 프로세스인 것은 아닙니다.위의 예에서 "최적화된" 버전은 원래 버전보다 실제로 느려질 수 있습니다.N는 충분히 작았고, 특정 하드웨어는 곱셈이나 나눗셈보다 덧셈과 루프 조작이 훨씬 더 빠릅니다.

트레이드오프

그러나 최적화는 보다 정교한 알고리즘을 사용하여 "특수한 경우"와 "꼼수"를 사용하고 복잡한 트레이드오프를 수행하는 데 의존하는 경우도 있습니다."완전 최적화된" 프로그램은 최적화되지 않은 버전보다 이해하기 어려울 수 있으며, 따라서 더 많은 장애를 포함할 수 있습니다.명백한 반작용을 제거할 뿐만 아니라 일부 코드 레벨 최적화는 유지관리성을 감소시킵니다.

최적화는 일반적으로 실행 시간, 메모리 사용량, 디스크 공간, 대역폭, 전력 소비량 또는 기타 리소스 등 한두 가지 측면의 성능 향상에 초점을 맞춥니다.여기에는 보통 트레이드오프가 필요합니다.즉, 한 요소가 다른 요소를 희생시키면서 최적화됩니다.예를 들어 캐시 크기를 늘리면 런타임 성능이 향상되지만 메모리 소비량도 증가합니다.그 외의 일반적인 트레이드오프에는, 코드의 명확성과 일관성이 있습니다.

최적화를 수행하는 프로그래머가 일부 작업에 대해 소프트웨어를 개선하되 다른 작업의 효율성을 떨어뜨리는 대가를 치러야 하는 경우가 있습니다.이러한 트레이드오프는 때때로 비기술적인 성질의 경우가 있습니다.예를 들어, 경쟁사가 벤치마크 결과를 발표했을 경우, 이는 상업적 성공을 위해 반드시 이겨야 하지만 소프트웨어의 통상적인 사용 효율을 떨어뜨려야 하는 부담이 수반될 수 있습니다.이러한 변화를 농담으로 비관이라고 부르기도 한다.

병목 현상

최적화에는 시스템의 병목 현상(퍼포먼스를 제한하는 컴포넌트)을 발견하는 것이 포함됩니다.코드의 경우, I/O 지연이나 네트워크 대역폭 등 다른 요인이 될 수 있지만, 이것은 핫 스팟(필요한 자원의 주요 소비자인 코드의 중요한 부분)이 되는 경우가 많습니다.

컴퓨터 과학에서 자원 소비는 종종 멱함수 법칙 분포의 형태를 따르며, 파레토 원리는 자원의 80%가 일반적으로 [3]연산의 20%에 의해 사용된다는 것을 관찰함으로써 자원 최적화에 적용될 수 있다.소프트웨어 엔지니어링에서는 컴퓨터 프로그램 실행 시간의 90%가 코드의 10%를 실행하는 데 소비되는 것이 더 나은 근사치인 경우가 많습니다(이 문맥에서는 90/10 법칙이라고 합니다).

보다 복잡한 알고리즘과 데이터 구조는 많은 항목에서 뛰어난 성능을 발휘합니다.단순한 알고리즘은 소량의 데이터에 더 적합합니다.즉, 보다 복잡한 알고리즘의 셋업, 초기화 시간 및 상수 요인이 이점을 능가할 수 있기 때문에 하이브리드 알고리즘 또는 적응형 알고리즘은 단일 알고리즘보다 빠를 수 있습니다.퍼포먼스 프로파일러를 사용하면 어떤 기능이 어떤 [4]조건에 적합한지에 대한 결정을 좁힐 수 있습니다.

경우에 따라서는, 메모리를 증설하는 것으로, 프로그램의 실행 속도를 높일 수 있습니다.예를 들어 필터링 프로그램은 일반적으로 각 행을 읽고 즉시 해당 행을 필터링하여 출력합니다.이 경우 한 줄에 충분한 메모리만 사용되지만 각 디스크 읽기 지연으로 인해 일반적으로 성능이 저하됩니다.결과를 캐싱하는 것도 마찬가지로 효과적이지만 더 많은 메모리를 사용해야 합니다.

최적화하는 시기

최적화를 통해 가독성이 저하되고 성능 향상에만 사용되는 코드를 추가할 수 있습니다.이로 인해 프로그램 또는 시스템이 복잡해져 유지 보수 및 디버깅이 어려워질 수 있습니다.그 결과, 개발 스테이지의 마지막에 최적화나 퍼포먼스 튜닝을 실시하는 경우가 많습니다.

Donald Knuth는 최적화에 대해 다음과 같은 두 가지 진술을 했습니다.

"약 97%의 경우 사소한 효율성은 잊어야 합니다. 시기상조 최적화는 모든 악의 근원입니다.그러나 중요한 3%[5]에서 기회를 놓쳐서는 안 됩니다.

(또한 그는 몇 [6]년 후 토니 호어의 말을 인용한 것으로 돌렸습니다만, 호어가 이 문구를 만든 것은 실수였을 수도 있습니다.)[7]

확립된 엔지니어링 분야에서는 쉽게 얻을 수 있는 12%의 향상은 결코 한계로 간주되지 않습니다.소프트웨어 [5]엔지니어링에서도 같은 견해가 우세해야 한다고 생각합니다.

"프리미처 최적화"는 프로그래머가 성능 고려가 코드 설계에 영향을 미치는 상황을 설명하는 데 사용되는 문구입니다.최적화로 인해 코드가 복잡해지고 프로그래머가 최적화로 인해 주의가 산만해지기 때문에 설계가 원래보다 깨끗하지 않거나 코드가 잘못될 수 있습니다.

프로그램의 특정 부분을 최적화할지 여부를 결정할 때는 항상 Amdahl의 법칙을 고려해야 합니다.프로그램 전체에 미치는 영향은 특정 부분에서 실제로 소비하는 시간의 양에 크게 좌우됩니다.퍼포먼스 분석 없이 코드를 확인하는 것은 항상 명확하지 않습니다.

따라서 더 나은 접근법은 먼저 설계를 하고 설계에서 코드를 작성한 다음 결과 코드를 프로파일/벤치마킹하여 어떤 부품을 최적화해야 하는지 확인하는 것입니다.심플하고 우아한 디자인은 이 단계에서 최적화가 더 쉬워지는 경우가 많습니다.프로파일링을 하다 보면 섣부른 최적화로 해결되지 않았을 예기치 않은 성능 문제가 드러날 수 있습니다.

실제로 소프트웨어를 처음 설계할 때 성능 목표를 염두에 두어야 하는 경우가 많지만 프로그래머는 설계와 최적화의 목표를 균형 있게 조정합니다.

최신 컴파일러와 운영체제는 매우 효율적이기 때문에 의도한 성능 향상이 실현되지 않는 경우가 많습니다.예를 들어 운영 체제 수준에서 다시 캐시된 애플리케이션 수준에서 데이터를 캐싱해도 실행 성능이 향상되지 않습니다.그렇다 하더라도 프로그래머가 실패한 최적화를 프로덕션 코드에서 제거하는 경우는 드문 경우입니다.또한 하드웨어의 진보는 잠재적인 개선을 배제하지 않는 경우가 대부분이지만, 그 목적이 부정된 후에도 불분명한 코드는 앞으로도 지속될 것입니다.

매크로

매크로를 사용한 코드 개발 중 최적화는 언어별로 다른 형태를 취합니다.

C나 C++ 등 일부 절차 언어에서는 토큰 치환을 사용하여 매크로가 구현됩니다.오늘날 인라인 함수는 많은 경우에 안전한 유형 대안으로 사용될 수 있습니다.두 경우 모두, 인라인된 함수 본체는 컴파일러에 의해 연속 폴딩을 포함한 컴파일 시간 최적화를 수행할 수 있으며, 이는 일부 계산을 컴파일 시간으로 이동할 수 있다.

많은 기능 프로그래밍 언어에서 매크로는 구문 분석 트리/추상 구문 트리의 구문 분석 시간 대체를 사용하여 구현되며, 이는 사용하기에 더 안전하다고 주장됩니다.대부분의 경우 해석이 사용되기 때문에 이러한 계산이 해석 시간에만 수행되도록 하는 방법 중 하나이며, 경우에 따라서는 유일한 방법이기도 합니다.

Lisp는 이러한 스타일의 [citation needed]매크로를 만들어 냈으며, 이러한 매크로를 종종 "Lisp-like macro"라고 합니다.C++에서 템플릿 메타프로그래밍을 사용해도 동일한 효과를 얻을 수 있습니다.

두 경우 모두 작업이 컴파일 시간으로 이동됩니다.한쪽의 C 매크로와 다른 한쪽의 Lisp와 같은 매크로와 C++ 템플릿 메타프로그래밍의 차이점은 후자의 툴은 컴파일 타임/파스 타임에 임의의 계산을 실행할 수 있는 반면, C 매크로의 확장은 계산을 실행하지 않고 옵티마이저의 기능에 의존한다는 것입니다.또한 C 매크로는 재귀 또는 반복을 직접 지원하지 않으므로 Turing은 완전하지 않습니다.

그러나 모든 최적화와 마찬가지로 프로젝트가 완료되기 전에 이러한 툴이 어디에 가장 큰 영향을 미칠지 예측하기 어려운 경우가 많습니다.

자동 및 수동 최적화

주요 기사:컴파일러 최적화

카테고리:컴파일러 최적화

최적화는 컴파일러에 의해 자동화되거나 프로그래머에 의해 수행될 수 있습니다.일반적으로 로컬 최적화의 경우 이득이 제한되고 글로벌 최적화의 경우 이득이 커집니다.일반적으로 가장 강력한 최적화는 우수한 알고리즘을 찾는 것입니다.

시스템 전체를 최적화하는 작업은 자동화된 최적화 작업에는 너무 복잡하기 때문에 프로그래머가 주로 수행합니다.이 경우 프로그래머 또는 시스템 관리자는 시스템 전체의 성능을 향상시키기 위해 코드를 명시적으로 변경합니다.효율성은 향상되지만 자동 최적화보다 훨씬 더 비싸다.많은 파라미터가 프로그램 성능에 영향을 미치기 때문에 프로그램 최적화 공간이 넓습니다.메타 휴리스틱스와 기계 학습은 프로그램 [8]최적화의 복잡성을 해결하기 위해 사용된다.

프로파일러(또는 성능 분석기)를 사용하여 가장 많은 리소스를 사용하는 프로그램 섹션(병목 현상)을 찾습니다.프로그래머들은 때때로 병목현상이 어디에 있는지 명확하게 알고 있다고 믿지만, 직관은 종종 [citation needed]틀립니다.중요하지 않은 코드를 최적화하는 것은 일반적으로 전체 성능에 거의 도움이 되지 않습니다.

병목현상이 국지화되면 최적화는 보통 프로그램에서 사용되는 알고리즘을 재고하는 것으로 시작됩니다.대부분의 경우 특정 알고리즘은 특정 문제에 맞게 특별히 조정되어 일반 알고리즘보다 성능이 향상됩니다.예를 들어, 방대한 항목 목록을 정렬하는 작업은 일반적으로 가장 효율적인 일반 알고리즘 중 하나인 빠른 정렬 루틴을 사용하여 수행됩니다.그러나 항목의 일부 특성이 악용 가능한 경우(예: 항목이 이미 특정 순서로 배열되어 있는 경우), 다른 방법을 사용하거나 사용자 지정 정렬 루틴을 사용할 수 있습니다.

프로그래머가 최적의 알고리즘이 선택되었음을 합리적으로 확인한 후 코드 최적화를 시작할 수 있습니다.루프는 풀 수 있습니다(루프 오버헤드를 낮추기 위해 CPU 캐시에 과부하가 걸리면 속도가 저하되는 경우가 많지만), 가능한 한 작은 데이터 타입을 사용할 수 있습니다.부동소수점 대신 정수 산술 등을 사용할 수 있습니다(이러한 기술 및 기타 기술에 대해서는 알고리즘 효율 문서를 참조하십시오).

성능 병목 현상은 프로그램에서 사용되는 알고리즘이나 데이터 구조가 아니라 언어 제한 때문일 수 있습니다.프로그램의 중요한 부분을 다른 프로그래밍 언어로 재작성하여 기본 머신에 더 직접 액세스할 수 있는 경우가 있습니다.예를 들어, Python과 같은 매우 높은 수준의 언어에서는 더 빠른 속도를 위해 모듈이 C로 작성되는 것이 일반적입니다.C로 이미 작성된 프로그램에는 어셈블리에 모듈이 기록될 수 있습니다.D로 작성된 프로그램은 인라인 어셈블러를 사용할 수 있습니다.

이러한 상황에서 섹션의 개서는 90/10 법칙으로 알려진 일반적인 "경험의 규칙"에 의해 무효화됩니다.이것은 시간의 90%가 코드의 10%에 소비되고 나머지 90%에는 10%만 소비된다는 것입니다.따라서 프로그램의 극히 일부만 최적화하는 데 지적인 노력을 기울이면 올바른 부품을 찾을 수 있다면 전체 속도에 큰 영향을 미칠 수 있습니다.

수동 최적화는 가독성을 저해하는 부작용이 있을 수 있습니다.따라서 코드 최적화는 신중하게 문서화되어야 하며(가능하다면 인라인 코멘트를 사용하여) 향후 개발에 미치는 영향을 평가해야 한다.

자동 최적화를 실행하는 프로그램을 옵티마이저라고 합니다.대부분의 옵티마이저는 컴파일러에 내장되어 컴파일 중에 동작합니다.대부분의 경우 옵티마이저는 생성된 코드를 특정 프로세서에 맞게 조정할 수 있습니다.

현재 자동 최적화는 컴파일러 최적화에만 한정되어 있습니다.그러나 컴파일러 최적화는 보통 비교적 일반적인 최적화의 고정 집합으로 제한되기 때문에 문제 설명과 언어별 최적화를 받아들일 수 있는 최적화에 대한 수요가 상당히 많기 때문에 엔지니어가 커스텀 최적화를 지정할 수 있습니다.최적화에 대한 설명을 받아들이는 툴은 프로그램 변환 시스템이라고 불리며 C++와 같은 실제 소프트웨어 시스템에 적용되기 시작하고 있습니다.

일부 고급 언어(Eiffel, Estrel)는 중간 언어를 사용하여 프로그램을 최적화합니다.

그리드 컴퓨팅 또는 분산 컴퓨팅은 사용량이 많은 컴퓨터에서 유휴 시간이 있는 컴퓨터로 작업을 이동하여 시스템 전체를 최적화하는 것을 목표로 합니다.

최적화에 소요된 시간

때로는 최적화에 걸리는 시간 자체가 문제가 될 수 있다.

기존 코드를 최적화해도 일반적으로 새로운 기능이 추가되지 않으며, 더 나쁜 것은 이전에 동작하던 코드에 새로운 버그가 추가될 수 있다는 것입니다(변경 시).수동으로 최적화된 코드는 최적화되지 않은 코드보다 "가독성"이 떨어지는 경우가 있기 때문에 최적화는 또한 코드의 유지 보수성에 영향을 미칠 수 있습니다.최적화에는 대가가 따르기 때문에 투자가 가치가 있는지 확인하는 것이 중요합니다.

자동 최적화 장치(또는 코드 최적화를 수행하는 프로그램인 최적화 컴파일러)는 대상 프로그램의 효율성을 더욱 개선하거나 자체 작동을 가속화하기 위해 그 자체를 최적화해야 할 수 있습니다.최적화를 "켜서" 컴파일을 수행하면 일반적으로 시간이 더 오래 걸립니다. 단, 이것은 보통 프로그램이 상당히 큰 경우에만 문제가 됩니다.

특히 Just-in-Time 컴파일러의 경우 런타임 컴파일 컴포넌트와 타깃 코드를 함께 실행하는 퍼포먼스가 전체적인 실행 속도를 향상시키는 열쇠입니다.

레퍼런스

  1. ^ 로버트 세지윅, 알고리즘, 1984, 페이지 84
  2. ^ Adewumi, Tosin P. (2018-08-01). "Inner loop program construct: A faster way for program execution". Open Computer Science. 8 (1): 115–122. doi:10.1515/comp-2018-0004.
  3. ^ Wescott, Bob (2013). The Every Computer Performance Book, Chapter 3: Useful laws. CreateSpace. ISBN 978-1482657753.
  4. ^ "Performance Profiling with a Focus". Retrieved 15 August 2017.
  5. ^ a b Knuth, Donald (December 1974). "Structured Programming with go to Statements". ACM Computing Surveys. 6 (4): 268. CiteSeerX 10.1.1.103.6084. doi:10.1145/356635.356640. S2CID 207630080.
  6. ^ 소프트웨어에서의 TeX의 오류—연습과 경험, 제19권, 제7호(1989년 7월), 페이지 607–685는 그의 저서 Literate Programming (276페이지)에 전재되었습니다.
  7. ^ "Premature optimization is the root of all evil". hans.gerwitz.com. Retrieved 2020-12-18. Hoare, however, did not claim it when I queried him in January of 2004
  8. ^ Memeti, Suejb; Pllana, Sabri; Binotto, Alécio; Kołodziej, Joanna; Brandic, Ivona (26 April 2018). "Using meta-heuristics and machine learning for software optimization of parallel computing systems: a systematic literature review". Computing. Springer Vienna. 101 (8): 893–936. arXiv:1801.09444. Bibcode:2018arXiv180109444M. doi:10.1007/s00607-018-0614-9. S2CID 13868111.

추가 정보

Wikibooks는 "속도를 위한 코드 최적화"라는 주제로 책을 출판했습니다.