아래 글은 원래 2002년에 Robert Lee의 홈페이지인 http://www.optimalcode.com 라는 사이트에 실렸던 “Delphi Optimization Guideline”이라는 글의 일부입니다. 지금 이 사이트는 없어진 상태이고 원래의 필자도 전혀 연락이 안되는 상태입니다. 하지만 최근에 예전의 컨텐츠들을 http://delphitools.info 에서 되살렸습니다. 델파이 개발자분들께 도움이 될 부분이 많을 것 같아서 번역을 시작해봅니다. 전체는 4개의 시리즈로 되어 있으며, 이 글은 그중 마지막인 Floating Point Optimization Guideline 입니다. 

원문 : http://delphitools.info/OptimalCode/float.htm

스타일 가이드라인

절대적으로 필요한 경우가 아니면 extended를 사용하지 말라

extended의 정밀도(80비트)는 내부적으로 FPU가 계산을 수행하기는 하지만 로드와 저장에 있어 그다지 효율적이지 못합니다. 따라서 extended 타입을 사용하는 것은 단순한 산술 연산(+, -, *)의 전체 실행 시간을 두배까지 늘릴 수 있습니다. 이것은 연산 자체를 수행하는 데 들어가는 추가 시간 때문이 아니라 extended 값을 로드하고 저장하는 데 들어가는 추가 시간입니다. 또한, extended 타입 변수의 크기의 불편함(10바이트,
doubleword 정렬에서 12바이트를 차지) 때문에 캐시 라인에도 비효율적이 될 가능성이 높아지며 그로 인해 성능 손실이 생기게 됩니다.

마지막으로, 델파이 버전 2에서 4까지에서는, extended 타입의 지역 변수는 할당된 12바이트(3 dword) 중 첫 10바이트가 아니라 뒤의 10바이트로 정렬되는 문제가 있습니다. 이것은 extended가 지역 변수로서는 잘못 정렬된다는 뜻입니다. 이 문제는 델파이 5 버전에서 픽스되었지만, 아직도 컴파일러가 생성한 임시 변수들에서는 문제가 남아있습니다.

부동소수점 타입들을 섞지 말라

기본적인 문제는, 두 가지 경우에 불필요한 타입 변환 단계를 강제하게 된다는 것입니다. 1) 한 변수를 다른 변수에 대입, 2) 변수를 파라미터로 전달. 이런 경우, 한 변수의 두 인스턴스가 FP 스택에 로드되어야 하며 그냥 복사되는 대신 새로운 타입으로 저장되게 됩니다. 이로 인해 3, 4배 시간을 더 소모하게 됩니다.

각 대입문에서 함수 호출은 한번으로 제한하도록 노력하라

FPU(부동소수점 유닛)의 레지스터 스택은 8개 밖에 없습니다. 따라서 스택이 넘치는 것을 막기 위해, 하나의 표현식 내의 함수 호출이 일어나면 호출을 실행하기 전에 레지스터 스택을 먼저 비워야 합니다. 오직 하나의 예외는 인자들이 결정된 직후 그리고 나머지 표현식의 나머지 부분이 평가되기 전에 호출될 수 있어서 표현식 내의 첫번째 함수 호출이 이런 비우기 작업과 무관할 경우입니다. 델파이는 모든 저장된 값들을 임시적인(그리고 보이지 않는) extended 변수에 저장함으로써 스택을 비웁니다. 앞에서 설명했던 것처럼, extended는 성능이 낮으므로, 개발자가 스스로 임시 변수를 만들고 한 변수 대입마다 하나의 함수 호출만 일어나도록 표현식을 나누어야 합니다. 이 규칙은 System 유닛에 있는 컴파일러 “매직” 함수에서도 볼 수 있는데, Abs나 Sqr 함수 등입니다. 이것은 “중첩된” 호출을 포함하지 않는데, 파라미터 표현식에 포함된
함수 호출이 다른 함수 호출을 가지는 경우를 말합니다. 부동소수점 파라미터는 항상 스택을 통해 전달되므로, 각 파라미터 표현식은 분리된 표현식을 나타냅니다.

부동소수점 상수

부동소수점 상수는 실행 파일 내에 특정 타입으로 저장됩니다 (single, double or extended). 기본적으로, 정수 부분만으로 된 상수는 single로 저장되고 소수점 아래 부분이 있는 상수는 extended로 저장됩니다. 앞에서 언급한대로, extended를 사용하는 것은 높은 비용이 들기 때문에, 타입 지정 상수(typed constant)로 만들어서 지정된 크기(single or double)가 되도록 해야 합니다. 해당 값은 어떤 식으로든 바이너리에 포함되므로 전체 실행파일의 크기는 늘어나지 않습니다. 예를 들어봅시다.

위 코드는 extended 타입을 사용하는 코드보다 빠를 뿐만 아니라 더 작습니다(double은 8바이트만 사용). $J+ 지시어를 사용하면 타입 지정 상수의 값도 변경할 수 있다는 점도 기억해둡시다.

또한, 컴파일러는 컴파일 중에 가능하다면 상수들을 결합합니다. 두 상수 사이의 연산이 그 상수들과 변수들, 변수 표현식 등이 관련된 다른 다른 연산들보다 우선순위에서 높을 경우, 그 상수들은 상수 폴딩(constant folding)이 됩니다. 추가로, 델파이 2와 3에서는 상수로 나누는 나눗셈은 항상 곱셈으로 바뀝니다. 불행히도 이 기능은 4 버전에서 없어졌습니다. 따라서, 예를 들면 델파이 2와 3에서 다음의 문장은,

실제로는 아래와 같이 계산됩니다.

델파이 4에서는 위의 문장은 아래와 같이 계산됩니다.

변수들보다 상수를 앞에 두면 상수 폴딩의 효과가 더 나아집니다.

위 코드는 실제로는 아래와 같이 계산됩니다.

 

컨트롤 워드 정밀도를 적절한 레벨로 설정하라

부동소수점 나눗셈과 제곱근 명령은 상당한 시간을 소모합니다. 하지만, 최대의 정확도가 필요한 경우가 아니라면 일정 시간을 아낄 수 있습니다. FPU의 컨트롤 워드를 변경하면 정확도의 수준을 바꿀 수 있습니다. 델파이 런타임 라이브러리에 의해 초기화되는 기본 정확도는 가장 느리지만 가장 정밀합니다(즉, extended). 델파이는 Set8087CW 프로시저와 전역 변수 Default8087CW를 통해 FPU의 컨트롤 워드에 대한 직접 변경을 지원합니다. 컨트롤 워드를 다른 정밀도 레벨로 바꾸려면 다음과 같이 하면 됩니다.

컨트롤 워드를 변경하면 나눗셈의 실행 시간만 달라지며, 펜티엄 II와 펜티엄 III 프로세서에서는 제곱근의 실행시간도 영향을 받습니다. 델파이 6 이후로는 간단히 SetPrecisionMode()를 호출하면서 적절한 정밀도 레벨 상수(pmSingle, pmDouble, pmExtended)를 넘겨주기만 하면 됩니다.

Trunc보다 Round를 선호하라

 

함수보다는 var 파라미터를 가진 프로시저를 선호하라

이것은 오버헤드 관리 이슈이며, 따라서 전체 처리 시간에서 오버헤드가 더 많은 비율을 차지하는 작은 함수들의 경우에 적용됩니다. 다음의 예에서,