🛠️ 프로그램 성능 최적화

💭 프로그램의 최적화는 무엇을 위한 것인가?

프로그래머들이 프로그램을 단순히 '작성'만 한다면 모든 사람들이 만족할 수 있는가?
에 대해 생각해본다면 당연히 답은 아니다 :
사용자는 정확하고 빠른 소프트웨어를 기대한다.
응답이 1초가 3초로만 늘어나도 이탈률이 튄다.
슬랙에서 보낸 농담 메시지가 내 팀원이 아니라 코치님께 가는 버그처럼, 느림과 오류로 인해
아무도 해당 프로그램을 사용하지 않을 것이다.

따라서 우리는 모든 합리적 환경에서 정확성과 속도를 동시에 달성해야 한다.
이를 위해 무엇을 측정하고, 어디를 줄이며,
어떤 순서로 개선할지 체계적인 최적화 방법을 살펴보려고 한다.

💊 효율적인 프로그램을 위한 방안

💻 효율적인 프로그램의 작성

첫째, 적절한 알고리즘과 자료구조를 선택한다.

둘째, 컴파일러가 효과적으로 최적화해서 효율적인 실행코드로 바꿀 수 있는 소스코드를 작성해야 한다.

• 이 최적화 컴파일러의 능력과 한계를 이해해야 한다.

💭 프로그래머들의 고민

첫째, 어떻게 코드가 사용되고 어떤 결정적인 요소들이 영향을 끼치는가를 고려해야 한다.

둘째, 어떻게 하면 구현과 유지를 쉽게할 지, 동시에 어떻게 더 빨리 돌릴 수 있을지 사이에서 타협해야 한다.

☑️ 컴파일러의 이용

첫째, 코드가 수행해야 하는 작업을 효율적으로 수행하도록 불필요한 작업을 제거해야 한다.

• 불필요한 함수 호출, 조건 테스트, 메모리 참조 등

둘째, 컴파일러는 계속해서 능력이 갱신되고 개선되므로 컴파일러가 효율적인 코드를 생성할 수 있는 정도의 최소한의 수정만 한다.

최적화 컴파일러의 능력과 한계

🤖 현대 컴파일러의 능력

• 목표: 불필요한 연산을 제거하고, 계산을 단순화하며, 연산 빈도를 줄여 성능 향상
• 최적화 수준: -Og(기본), -O1, -O2, -O3로 갈수록 공격적인 최적화 수행

⚠️ 최적화 수준에서 발생할 수 있는 문제

최적화 수준이 높으면 훨씬 우수한 C언어를 작성하고, 성능을 개선할 수 있다.
다만 디버그가 어려워진다.

**최적화 수준이 높다 = 저수준 언어에 가깝다**

디버거는 기계가 아닌 사람의 입장에서 프로그램을 관찰하기 위한 번역기이다.
즉, 최적화 수준이 높아진다면 원래의 소스코드와 변화가 많아지기 때문에 매핑하기 어렵기 때문이다.

---

하지만 최적화 옵션을 아무리 적당하게 높인다고 해도, 모든 상황에서 최고의 성능을 보장하진 않는다.
코드 구조나 데이터 접근 방식에 따라 컴파일러가 적용할 수 있는 최적화에 한계가 있기 때문이다.
이러한 한계를 만드는 대표적인 요인들이 바로 다음과 같다.

😈 최적화를 방해하는 최적화 장애물

1. 메모리 별칭: 포인터 간의 관계를 확정하기 어렵기 때문에 보수적으로 처리할 수 있다.

   • 두 포인터가 같은 메모리를 가리키는 문제로 인해서 정확한 값이 들어가지 않는 최악을 한번 더 고려해야 하기 때문에 서로 다른 포인터라고 해도 같은 위치를 가리킨다고 가정한다.

2. 함수 호출: 호출 오버헤드와 외부 영향(전역 변수 변경 등) 때문에 최적화가 제한될 수 있다.

   • 부작용(Side Effect) 으로 함수가 외부 상태를 변경하면 명령 순서 변경이 불가능.

---

💬 프로그램 성능의 표현

그렇다면 최적화를 잘 활용하려면 이제 단순히 컴파일러 옵션에만 의존하는 것이 아니라 현재 코드가 어느 부분에서 병목이 발생하는지를 파악하고, 이를 수치로 표현해 분석하는 과정이 필요하다.
이 과정이 있어야 코드 구조 변경이나 알고리즘 개선이 실제 성능 향상으로 이어졌는지 객관적으로 확인할 수 있다. 이러한 성능 분석에는 다양한 지표가 사용되는데, 하나의 예시가 바로 CPE이다.

🥚 CPE (Cycles Per Element)

: 데이터 1개를 처리하는 데 필요한 평균 CPU 사이클 수로 요소당 측정 사이클이라고도 한다.

• 측정 이유: 하드웨어마다 성능에 따른 시간(ns) 차이가 있으므로, 사이클 단위가 비교에 더 적합
• 루프 전개(Loop Unrolling)를 활용하면 반복 횟수를 줄이고 CPE 감소 가능.

// 기본 루프
void psum1(float a[], float p[], long n) {
    p[0] = a[0];
    for (long i = 1; i < n; i++)
        p[i] = p[i-1] + a[i]; //한번의 반복문에 1개의 원소만 처리
}

// 루프 전개 적용
void psum2(float a[], float p[], long n) {
    p[0] = a[0];
    for (long i = 1; i < n-1; i += 2) {
        float mid = p[i-1] + a[i];
        p[i] = mid;
        p[i+1] = mid + a[i+1]; //한번의 반복문에 2개의 원소 처리
    }
}

• psum1: CPE ≈ 9.0
• psum2: CPE ≈ 6.0 → 성능 향상이 된 것을 확인 할 수 있다.

위의 코드에서 볼 수 있는 것처럼
1. 반복문 안에 작업이 1개인 경우는 요소당 사이클의 수와 반복당 사이클의 수가 같다.
2. 반복문 안에 여러개의 작업이 있는 경우 요소당 사이클의 수는 반복당 사이클의 수보다 더 작다.

즉, 우리가 궁금한건 데이터 1개를 처리하는데 걸리는 시간이므로
루프 전개시 성능차이를 확인할 수 있는 CPE를 확인하는 것이 더 좋은 것이다.

---

🧪 프로그램 예제

아래 예제는 지금까지 배운 최적화 기법 적용 전·후의 성능 차이를 이해하기 위한 기저 코드이다.
현재 상태에서는 코드 구조상 불필요한 함수 호출과 메모리 접근이 포함되어 있어,
컴파일러가 충분히 최적화하지 못한다.

🔶 벡터 추상 자료형

int get_vec_element(vec_ptr v, long index, data_t *dest)
{
	if (index < 0 || index >= v->len)
		return 0;
	*dest = v->data[index];
	return 1;
 }

• if (index < 0 || index >= v->len) : 안전한 장치이기는 하나 매번 인덱스 검사를 하기 때문에 함수 호출 오버헤드를 발생시키고 있다.

🔶 결합 연산 예시

void combine1(vec_ptr v, data_t *dest) {
    *dest = IDENT;
    for (long i = 0; i < vec_length(v); i++) {
        data_t val;
        get_vec_element(v, i, &val);
        *dest = *dest OP val;
    }
}

• vec_length() : 벡터 길이가 변할 일이 없는데 매번 길이를 계산하는 함수를 호출함으로써,
  함수호출오버헤드 및 불필요한 메모리 접근을 발생시키고 있다.

• *dest = *dest OP val; : 매번 메모리에서 해당 변수의 위치를 읽고 매번 다시 쓰면서
  불필요한 메모리 접근을 발생시키고 있다.

---

⁉️ 다음은?

이처럼 단순한 추상 자료형 기반 구현에서도,
작은 설계 선택들이 함수 호출 오버헤드와 불필요한 메모리 접근을 만들 수 있다.
다음 글에서부터 이 기저 코드를 바탕으로 구체적인 최적화 기법을 적용하고,
CPE와 같은 지표로 성능 향상을 측정하는 과정을 살펴보려고 한다.