AVR 컴파일러 최적화와 변수 사용방법이 동작속도에 주는 영향

임베디드 개발의 기본: 메모리를 아껴라

프로그램을 작성하다 보면 필연적으로 변수를 사용할 일이 생긴다. PC처럼 기본 메모리가 넉넉하고, 메모리가 부족하면 운영체제가 알아서 가상 메모리까지 챙겨주는 환경에서는 변수를 선언하는 데 그다지 신경을 쓸 일이 없다.

하지만 AVR 같은 마이크로컨트롤러에서도 그런 식으로 변수를 마구 선언하다 보면, 메모리 용량의 절대적 한계에 부딪혀 더 이상 변수를 하나도 추가할 수 없는 상황을 마주하게 된다.

때문에 임베디드 환경에서는 어떻게든 사용할 수 있는 메모리의 양을 확보하기 위해 메모리를 쪼개서 할당하는 경우가 많다. 또한, 컴파일된 바이너리도 메모리를 차지하기 때문에 컴파일러도 최적화를 위한 여러 옵션들을 제공한다.

그렇다면 메모리 걱정 없이 변수를 넉넉하게 선언해 사용하는 방식과, 비트 단위로 쪼개 메모리를 아껴 쓰는 방식 사이에는 실제로 어느 정도의 성능 차이가 있을까? (앞의 방식을 펑펑모드, 뒤의 방식을 쫄쫄모드라 하겠다. 특별한 이유는 없다. 그냥 본 필자 맘이다.)

또, 컴파일러를 이용해 최적화를 진행하는 것은 얼마나 큰 차이를 만들어 낼까?

이 궁금증을 해결하기 위해 ATmega2560을 사용해 두 방식의 실행 속도와 코드 크기를 비교해 보고, 컴파일러 최적화 옵션(-O0, -O1 등)의 변화에 따라 어떤 차이가 발생하는지 확인해 보기로 했다.

시험 방법

• 마이크로컨트롤러: ATmega2560
• 개발 환경: Microchip Studio (구 Atmel Studio)
• 컴파일러: AVR-GCC
• 측정 방법:
  • 코드 시작 부분에서 PORTA를 0xFF로 켠다.
  • 조건문 블록을 모두 실행한 뒤 마지막에 PORTA를 다시 0x00으로 내린다.
  • 오실로스코프로 PORTA의 펄스 폭을 측정하면, 그 구간에 코드가 실행되는 데 걸린 시간을 알 수 있다.
• 반복 수행:
  • 각 조건에서 동일한 코드를 3번씩 루프 실행한다.
  • 이 과정을 총 10회 반복한 뒤, 측정값의 평균을 구한다.

추가로, 컴파일러 옵션에 따른 바이너리 코드의 크기 차이와 실행 시간을 비교하기 위해, 마이크로칩 스튜디오(Microchip Studio)의 컴파일 옵션에서 -O0 옵션과 -O1 옵션을 적용해 동일한 코드를 컴파일한 후, 바이너리 파일을 생성해 AVR에 업로드 하고 각각의 동작 시간을 측정해 본다.

시험 코드 작성

8비트를 저장하기 위해 8개의 변수를 사용하는 펑펑모드

int main(void)
{
  DDRA=DDRB=0xFF;
	unsigned char a=0, b=0, c=0, d=0, e=0, f=0, g=0, h=0;
	a=b=c=d=e=f=g=h=rand();
	PORTA=0XFF;
	if (a==1)	{	PORTB=0x00;	}
	if (b==1)	{	PORTB=0x00;	}
	if (c==1)	{	PORTB=0x00;	}
	if (d==1)	{	PORTB=0x00;	}
	if (e==1)	{	PORTB=0x00;	}
	if (f==1)	{	PORTB=0x00;	}
	if (g==1)	{	PORTB=0x00;	}
	if (h==1)	{	PORTB=0x00;	}
	... 2번 반복 ...
	PORTA=0x00;
}

이 방식은 8비트를 저장하기 위해 8비트 변수 8개를 사용한다. 즉, 상태값 8개를 저장하는 데 총 64비트를 사용하는 구조이다. AVR 입장에서 보면, 각 if 문은 변수에 저장된 값을 1과 비교하고, 조건이 맞으면 분기하는 비교적 단순한 흐름을 따른다.

1개의 변수에 8비트를 저장하는 쫄쫄모드

int main(void)
{
  DDRA=DDRB=0xFF;
	unsigned char a=0;
	a=rand();
	PORTA=0XFF;
	if (a & (1<<0))	{	PORTB=0x00;	}
	if (a & (1<<1))	{	PORTB=0x00;	}
	if (a & (1<<2))	{	PORTB=0x00;	}
	if (a & (1<<3))	{	PORTB=0x00;	}
	if (a & (1<<4))	{	PORTB=0x00;	}
	if (a & (1<<5))	{	PORTB=0x00;	}
	if (a & (1<<6))	{	PORTB=0x00;	}
	if (a & (1<<7))	{	PORTB=0x00;	}
	... 2번 반복 ...
	PORTA=0x00;
}

이 방식은 8비트를 저장하기 위해 8비트 변수 1개만 사용한다. 즉, 상태값 8개를 하나의 변수 안에 비트 단위로 나누어 저장하는 구조이다. 메모리 사용량만 보면 64비트에서 8비트로 줄어들기 때문에 훨씬 효율적이다.

다만 코드의 양은 비슷해 보여도, 각 if 문을 실행하기 전에 특정 비트가 켜져 있는지 확인하기 위한 비트 연산이 추가된다. 따라서 메모리는 아낄 수 있지만, 실제 실행 속도에서는 이 추가 연산이 영향을 주게 된다.

시험 결과

생성된 바이너리 코드의 크기와 실행에 걸린 시간을 측정한 결과는 다음과 같다.

두 조건을 비교하면 코드 크기는 544B, 실행 시간은 약 17973.2µs, 즉 약 18ms 차이가 발생했다. 메모리를 아끼기 위한 비트 단위 저장 방식보다, 변수를 넉넉하게 사용하고 컴파일러 최적화 옵션을 적용하는 방식이 실행 속도와 코드 크기 모두에서 더 유리한 결과를 보였다.

결론적으로 가장 빠르고 코드 크기도 작았던 조건은 -O1 최적화를 적용한 펑펑모드였다. 반대로 가장 느리고 코드 크기도 컸던 조건은 최적화를 적용하지 않은(-O0) 쫄쫄모드였다.

어셈블리 코드를 통해 보는 차이의 이유

변수 사용 방식(펑펑모드 vs 쫄쫄모드)에 따라 실행 속도가 크게 달라지는 가장 큰 원인은 컴파일된 어셈블리 코드의 구조가 완전히 다르기 때문이다. 여기에 컴파일러 최적화 옵션(-O0, -O1 등)까지 더해지면, 동일한 코드라도 명령어 수, 레지스터 사용량, 분기 방식이 크게 변하며 그 결과 실제 성능이 눈에 띄게 달라진다.

if (a & (1<<0)) { PORTB = 0x00; }
11e: 8c 01        movw  r16, r24	; 1CLK
120: 01 70        andi  r16, 0x01	; 1CLK
122: 11 27        eor   r17, r17	; 1CLK
124: 80 fd        sbrc  r24, 0		; 1~3CLK
126: 15 b8        out   0x05, r1	; 1CLK
if (a & (1<<1)) { PORTB = 0x00; }

if (a == 1) { PORTB = 0x00; }
11e: 81 30        cpi   r24, 0x01	; 1CLK
120: c1 f4        brne  .+48		; 1~2CLK
122: 15 b8        out   0x05, r1	; 1CLK
if (b == 1) { PORTB = 0x00; }

컴파일러 최적화 옵션

결론

이번 시험을 통해 변수 사용 방식과 컴파일러 최적화 옵션이 AVR 코드의 성능에 얼마나 큰 영향을 미치는지 확인할 수 있었다. 같은 기능을 수행하는 코드라도 구조가 단순한 펑펑모드는 빠르게, 레지스터 조작이 복잡해지는 쫄쫄모드는 상대적으로 느리게 동작한다.

또한 -O0와 -O1 사이에서처럼, 최적화 옵션 하나만으로도 실행 속도가 수 배에서 10배 이상 차이 날 수 있다. 특별한 이유가 없다면 최소한 -O1 정도의 최적화 옵션은 사용하는 것이 좋다.

선택의 기준은 단순하다. 메모리를 아끼려면 쫄쫄모드, 속도가 중요하고 메모리가 허락한다면 펑펑모드. 프로젝트의 특성과 목적에 따라 두 방식 중 가장 자연스러운 방향을 선택하면 된다.

결국, 메모리가 받쳐준다면 막 써대는 게 좋다는 결론이다. 문제는 메모리는 하드웨어이고, 하드웨어는 돈이다. 그렇다, 결론은, 돈 많으면 다 된다.

FAQ

AVR-GCC는 무엇인가?

AVR-GCC는 C 언어를 이용해 작성한 코드를 AVR용 실행 바이너리 코드로 컴파일 해 주는 컴파일러로, 공개 컴파일러인 GCC를 기반으로 만들어진 AVR 전용 컴파일러이다.

AVR-GCC 이외에 다른 컴파일러도 있는가?

AVR에서 사용할 수 있는 다른 컴파일러도 존재한다. 하지만 별도의 비용이 발생하거나 특정한 목적으로만 사용할 수 있는 등 제약이 있는 경우가 많다. 컴파일러마다 부가 기능이나 특화된 분야는 다를 수 있지만, 일반적인 AVR 개발에서는 AVR-GCC만으로도 대부분의 작업을 충분히 수행할 수 있다.

AVR 개발시 메모리 부족은 자주 발생하는 문제인가?

소규모 코드에서는 흔한 문제는 아니다. 하지만 코드 규모가 커지면 AVR처럼 메모리가 제한된 마이크로컨트롤러에서는 생각보다 자주 마주하게 된다. 나중에 메모리 부족이 발생하면 이미 작성한 코드의 변수 사용 방식이나 데이터 구조를 다시 바꿔야 할 수 있으므로, 처음 설계할 때 대략적인 메모리 필요량을 계산해 두는 것이 좋다. 본 필자의 개인적인 의견으로는, 임베디드 환경에서는 일단 메모리를 아끼는 방향으로 접근하는 편이 안전하다.

-O1, -Os 같은 옵션은 모든 컴파일러에서 동일하게 사용되는가?

아니다. 최적화 옵션의 이름과 동작 방식은 컴파일러마다 다를 수 있다. 이 글에서 설명한 -O1, -Os 같은 옵션은 AVR-GCC에서 사용하는 최적화 옵션이다. 다른 컴파일러를 사용할 경우에는 해당 컴파일러의 설명서를 참고해야 한다.

컴파일러 최적화로 인한 문제를 막기 위한 방법은 무엇인가?

컴파일러 최적화로 인해 필요한 변수 접근이나 반복문이 제거되는 것을 막기 위해서는 volatile 키워드를 사용할 수 있다. volatile로 선언된 변수는 하드웨어 레지스터, 인터럽트, 외부 요인 등에 의해 값이 바뀔 수 있다고 컴파일러에 알려 주기 때문에, 컴파일러가 해당 변수 접근을 임의로 생략하거나 최적화하지 않도록 만드는 데 도움이 된다.