고레벨 언어에서는 비슷하게 보이는 명령도 어셈블리로 컴파일 되면 오퍼랜드에 따라 명령어의 속도와 길이가 달라집니다.
; Default
mov ebx, [mem1] ; byte 6 latency 3 RT 1/2
add ebx, [mem2] ; byte 6 latency 1 RT 1/2
; Optimized Code
mov edx, mem1 ; byte 5 latency 1 RT 1/3
mov ebx, [edx] ; byte 2 latency 1 RT 1/3
add ebx, [edx + mem2 - mem1] ; byte 3 latency 1 RT 1/3
위의 코드는 ebx = mem1 + mem2 (ebx- 레지스터, mem1, mem2- 메모리 변수)를 2가지 방식으로 구현한 것입니다.
Default는 12바이트를 차지하고 Optimized Code는 edx를 temp 변수처럼 사용하여 명령이 하나 더 많지만 10바이트를 차지합니다.
간단히 한 성능 테스트로 위는 2,215, 아래는 1,810이 나왔습니다.
테스트 결과값은 시작과 종료에 걸린 시간을 나타내므로 아래가 코드 한줄 더 들어갔지만 크기와 속도 전부 앞선다는 것을 알 수 있습니다.
; Default
mov eax, 0 ; byte 5, Latency 1 RT 1/3
; Optimized Code
xor eax, eax ; byte 2, Latency 1 RT 1/3
위의 코드는 eax에 0을 대입하는 2가지 방식 입니다.
속도는 두 코드 동일하지만 Optimized Code가 3바이트 적게 메모리를 차지 합니다.
; Default
mov eax, -1 ; byte 5, Latency 1 RT 1/3
; Optimized Code
or eax, -1 ; byte 3, Latency 1 RT 1/3
위의 코드는 eax에 -1를 대입하는 2가지 방식입니다.
크기는 Optimized Code가 2바이트 작고 제가 갖고 있는 표에는 둘이 동일한 속도로 나오는데 성능 테스트 결과 Default가 842, Optimized Code가 1,685로 2배 정도의 속도차이를 보여줬습니다.
표가 틀렸던지 제가 엉뚱한 표를 읽은 건지 둘 중에 하나겠죠.
어찌됐던 위의 Optimized Code는 크기는 줄었지만 성능은 감소했습니다.
성능최적화와 크기최적화 하나를 선택해야 겠지만 어셈블리 실행파일의 크기는 타 언어 실행파일과는 비교가 되지 않을 정도로 작습니다.
성능을 떨어뜨려가면서 크기최적화를 해야 할 이유가 없겠죠.
실제로 일반적으로 사용되는 라이브러리들은 성능과 크기를 선택해야할 경우 성능에 초점을 맞추고 최적화를 합니다.
위의 예들은 어셈블리 최적화의 아주 단순한 예들로 실제로는 매우 다양한 최적화 방법들이 있고 고레벨 언어로는 똑같이 보이는 걸 어떻게 최적화 하냐에 따라 성능과 크기가 달라집니다.
요즘 최적화에 관심을 갖게 된게 제가 만든 라이브러리가 언어와 비슷한 형태에 가까워 질수록 실제 프로그래밍에서 어셈블리 명령을 사용하지 않기 때문에 훌륭한 컴파일러들이 최적화를 알아서 해주듯이 최적화를 자동으로 해주기 위해서 입니다.
그래서 일반적인 코드와 최적화한 코드 성능 테스트 할 수 있는 간단한 프로그램 만들고 기록하고 있습니다.
크기 최적화, 성능 최적화 선택할 수 있게 하려다 지나친 욕심 같아서 성능 최적화에만 초점을 맞추고 있습니다.
최적화의 대부분은 조건문, 연산문, 대입문에 맞춰져 있습니다.
어셈블리 최적화까지 해야 할 경우는 극히 희박하지만 어셈블리와 최적화에 익숙해지면 컴파일러가 어떤 식으로 작동하는지 훨씬 잘알게 되고 고레벨 언어에서도 자연스럽게 최적화해서 프로그래밍 할 수 있게 됩니다.
