Section by Anand Shimpi

NCSU에 다니는 컴퓨터 엔지니어들은 의무적으로 프로그램 수업을 수강해야 합니다. 그리고 제 아버지가 컴퓨터 과학과의 교수님이셔서 전 항상 프로그래밍에 노출되어 있었습니다. 하지만 저는 제가 이 쪽을 잘한다고는 생각하지 않습니다. 제가 지금 하드웨어쪽으로 오게 된 이유가 소프트웨어에 대한 일종의 반항 때문이었다고 생각합니다. 하지만 저는 Swift를 이해하기 위해서는 코딩이 필요하다는 알고 있습니다. 한 가지 문제라면 제가 iOS를 위한 Objective-C 를 써본 어떤 경험도 없다는 것입니다. 그리고 제게는 Objective-C 수업을 듣고 있을 시간이 없습니다.

저는 C로 작동하는 코드를 갖고 있습니다, 하지만 저는 이것을 iPhone에서 실행하고 쉽게 결과를 확인할 수 있도록 포팅해야 했습니다. 저는 유능한 개발자 친구의 도움을 받았습니다. 그는 저와 비슷한 시기에 NCSU를 졸업한 Nirdhar Khazanie입니다. Nirdhar은 수 년째 모바일 개발 업무를 맡고 있습니다. 그는 순식간에 혼란스러운 C 코드를 제가 원하는 대로 iPhone에서 우아하게 작동하도록 만들어냈습니다. 그리고 그는 저에게 다양한 명령어와 데이터 셋 사이즈를 적용시킬 수 있는 프레임워크도 주었습니다. 이것은 제가 뒤에서 보여드릴 일련의 실험들을 가능하게 해줬습니다. 언제나 좋은 프로그래머를 안다는 것은 근사한 일입니다. 

그래서 Nidhar가 만든 앱이 어떤 일을 했냐고요? 한번 시작해 봅시다. ARM의 Cortex A9은 두 개의 독립적인 정수 연산유닛을 가지고 있습니다. 과연 Swift에는 더 많은 연산 유닛이 탑재되었을까요? 이 가설을 검증하기 위해 저는 독립적인 정수연산 루프를 만들어냈습니다. 각각의 변수들은 모두 독립적이며 이는 엄청난 수준의 명령어 레벨의 병렬성을 가능하도록 해 줍니다. 코드는 계속 반복해서 실행되고, 쉽게 예측할 수 있습니다. 제가 사용하는 코드는 초당 수백만의 연산을 수행하고 이를 추적할 수 있습니다. 그리고 저는 한 루프가 반복되는데 걸리는 평균 시간 역시 측정할 수 있습니다.

우리는 여기서 9.8% 정도의 성능 향상을 확인할 수 있습니다. 평균 레이턴시는 2 클럭 정도가 줄어들었습니다. 하지만 우리는 여기서 세 번째 연산유닛이 추가되었다면 쉽게 관측되었을 명령어 수준의 병렬성 증가를 찾지 못했습니다. 약간의 성능 향상이 있었던 것은 몇 가지 이유가 있을 수 있습니다. 애플의 자체 문서를 잠깐 보았는데 이는 몇 가지 사실을 확인해 줬습니다. Swift는 두 개의 정수연산유닛을 가지고 있으며 3개의 명령어를 사이클마다 발행해 줄 수 있습니다.(3-wide 디코더가 적용되었습니다.) 단지 이 변화가 정수 성능 향상의 전부인지는 잘 모르겠습니다.

부동소수점 연산 성능은 어떨까요? ARM의 Cortex A9은 부동소수점 연산에 단 하나의 이슈 포트만이 할당되어 있고, 이는 부동소수점 성능에 매우 심한 방해물이 됩니다. 앞에서 사용했던 코드를 조금 손봐서 단정밀도, 배정밀도 부동소수점 연산을 하도록 만들었습니다.

부동소수점 단정밀도 연산 성능을 보시면 성능이 약간 저하되는 현상이 관측되었습니다. 사실 이는 800MHz에서 1.3GHz로 성능 스케일이 완벽히 되지 않기 때문입니다. 이는 적어도 부동소수점 단정밀도 연산에 있어서 Swift는 Cortex A9과 별 차이가 없다는 뜻입니다. 반면 배정밀도 연산에서는 큰 성능 향상이 있었는데, Swift에 ARM의 VFPv4 확장이 지원되고, 애플이 FMA나 배정밀도 연산성능을 향상시키는 두 번째 부동소수점 연산 유닛을 Swift에 투입한 것으로 보입니다. 저는 같은 테스트를 FP 덧셈 연산에 대해서 수행해 봤고 위와 별 차이 없는 결과를 얻었습니다.

Sanity Check with Linpack & Passmark

Section by Anand Shimpi

제 코드를 전적으로 신뢰할 수는 없기에 Swift architecture 아키텍쳐를 이해하기 위해서는 추가적인 실험값이 필요했습니다. 먼저 Linpack의 iOS 버전을 이용해서 부동소수점 연산성능과 그 크기에 대한 상관관계를 그래프로 그렸습니다.

제가 테스트를 수백번 반복해서 돌렸지만 커브가 제가 원하는 것만큼 깔끔하게 나오지 않았습니다. 하지만 그것과 상관없이 결과값이 일관적으로 보여주고 있는 사실이 있습니다. Swift는 엄청난 성능 향상을 항상 보여주었습니다. 물론 메인 메모리로 이행할 때 발생하는 성능 하락이 있습니다만 역시 Cortex A9에 비해 개선되었습니다. 아래 표는 보정되지 않은 iPhone 4S에서 얻은 결과값과 Swift를 비교한 것입니다.

간단하게 말해서 Swift는 Cortex A9에 비해 메모리 레이턴시를 줄이는 데 성공했습니다. 부동소수점 연산과 메모리 연산이 동시에 실행되는 상황에서도 Swift는 이를 매우 잘 처리해 냈습니다.

마지막으로 테스트 값을 교차검증하기 위해 범용 iOS 마이크로벤치마크인 Passmark를 사용했습니다. 

정수 연산 테스트는 큰 데이터 셋을 이용해 다수의 덧셈, 뺄셈, 곱셈과 나눗셈을 실행했습니다. 데이터셋의 크기는 코어당 240KB였습니다. 이것은 이 프로세서의 L2캐시에 부하를 주기에 충분한 수준입니다. 여기서 Cortex A9에 비해 47%의 성능 향상이 있었다는 것을 주목해 주십시오.

부동소수점 연산 테스트는 정수 연산 테스트와 동일합니다.(사이즈를 포함해서) 하지만 이것은 32비트와 64비트 부동소수점 값으로 작동합니다. 여기서 관찰된 성능 향상은 Swift에 여러 개의 부동소수점 연산 파이프라인이 있다는 것을 다시 한 번 확인해 줍니다.

Primality 벤치마크는 많은 분기예측 연산과 많은 부동소수점 연산이 들어갑니다. 다시 한 번 우리는 Cortex A9에 비해 엄청난 성능향상을 확인할 수 있습니다.

qsort 테스트는 많은 정수연산과 매우 많은 분기예측이 필요합니다. 이 테스트에서 메인 메모리 사용량은 5MB에 달했습니다. 하지만 여기서 Swift는 다른 곳에서 보여준 것보다 큰 성능 향상을 보이지는 못했습니다. Swift가 분기 예측 실패시 그 패널티가 A9에 비해 더 크다고 생각해볼 수 있습니다.

암호화 테스트는 매우 작은 데이터셋으로 이뤄지고, L1 캐시 내에서 충분히 접근할 수 있습니다. 하지만 매우 많은 연산이 필요합니다. 여기서는 꽤나 큰 성능향상이 있었습니다, 일반 정수연산 결과의 반복이라고 볼 수 있겠습니다.

마지막으로 압축 테스트는 가장 적은 성능 향상을 보여줍니다. 물론 이 하나의 결과만으로 Swift가 Cortex A9에 비해 성능향상이 크지 않다고 말할 수는 없을 것입니다.