ARM Linux Kernel Hacks

rousalome.egloos.com

포토로그 Kernel Crash


통계 위젯 (화이트)

201239
1625
172598


[ARM] ARM 프로세서의 특징을 활용한 최적화는 왜 중요할까? 이제는 ARM의 시대

이번 포스팅에서는 'ARM 프로세서의 특징을 활용한 최적화는 왜 중요할까?'에 대해서 이야기하려고 합니다.
본론에 들어가기 앞서 일반적인 SW 개발자들이 최적화에 대해 어떻게 생각하는지 짚어 보겠습니다.   

생각보다 성능과 최적화는 중요하다

대부분 SW 개발자들은 주어진 스팩을 구현하기 위해 프로그램을 작성합니다.

화면을 꾸미는 프론트 엔드 개발자들은 화면이 제대로 구성됐는지, 메뉴나 폰트가 제대로 보이는 지 체크를 합니다. 네트워크 개발자들은 데이터 패킷이 제대로 전달이 됐는지 테스트를 할 것입니다.

프로그래머는 주로 주어진 스팩을 만족하면서 버그가 없도록 프로그래밍을 합니다. 하지만 프로그램이 스팩 내에서 올바르게 실행되도록 결함을 찾아 다듬는 것만으로는 충분하지 않을 수 있습니다.

고객이 사용하는 하드웨어 다비이스의 종류에 따라 프로그램이 느려질 수 있고, 가격을 후려치기 위해 하드웨어 팀에서 저사양 부품을 교체할 수 있으니까요. 혹은 예상치 않은 네트워크 시스템에 과부하가 걸려 웹 서버가 터지는 재앙을 맞이하기도 하죠.

그리고 프로젝트의 수주를 따기 위해 코드 처리량이나 화면 당 프레임 수를 기준으로 다른 업체와 경쟁을 하는 상황에 직면할 수 있습니다. 

생각보다 성능은 중요합니다. 성능은 어느 제품이던 성공과 실패의 척도가 될 수 있기 때문이죠.

최적화를 하지 말라는 충고

하지만, 많은 분들이 최적화를 논할 때 '최적화를 하지 말라'라고 경고합니다. 유명한 과학자(도널드 커누스)의 커멘트를 언급하면서 말이죠.

     * 작은 효율은 잊어버려라. 섣부른 최적화는 만약의 근원이다.
     출처: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.103.6084

월리엄 울프는 다음과 같이 논문에서 최적화에 대한 부정적인 의견을 펼쳤습니다.

     * 우리는 최적화나 효율성이란 이름으로 많은 죄악을 저질렀다.
     * 반드시 효율성을 달성하는 것도 아니면서 말이다.
출처:
Wulf, W. A. “A Case Against the GOTO.” Proceedings of the 25th National ACM Conference, August 1972: 791–97.

최적화에 대한 논의를 할 때 이런 논문 자료를 언급하는 개발자들은 생각보다 많다고 합니다. 제가 봤을 때 그 이유는 다음과 같다고 생각합니다.

    * 나약한 개발 습관에 대해 변명할 꺼리를 찾는다.
    * 더 빠른 코드를 구현하려는 노력을 조금도 하지 않으려는 게으름에 대한 핑계꺼리를 찾는다.

최적화를 하지 말라는 조언을 그대로 아무런 비판 없이 받아들이면 다음과 같은 결과를 초래합니다.

    * ARM 코어의 CPU 사이클이 낭비된다.
    * 사용자의 불편을 초래한다.
    * 프로젝트의 막바지엔 코드를 수정하는데 많은 시간이 소요된다.
    * 성능 문제가 발생해 고객사에게 패널티를 부과한다.

가장 심각한 케이스를 말하자면, 수주한 프로젝트의 성능 문제로 인해 아예 회사가 문을 받는 비극적인 상황을 맞이하기도 합니다.

최적화를 할 필요없다는 이유: 프로세서의 속도가 빠르다

SW 개발 세계에서 '최적화가 무의미하다'라는 소리를 종종 듣습니다. 그 이유는;

    * 코드의 실행 속도가 느리더라도 시간이 지날수록 프로세서가 빨라지기 때문에 성능 문제를 공짜로 해결할 수 있다는
      겁니다.

음, 과연 맞는 이야기일까요? 제 귀에는 펜스까지 120m까지 거리인 야구장에서 맨날 홈런을 두두려 맞는 투수가 '200m 짜리 펜스의 야구장이 있으면 홈런이 아니라 플라이로 잡힐 것이다'라는 소리로 들리네요.

이쯤되면 '이제 내가 나서서 이야기할 타이밍이군'이라고 생각하면서 임베디드 개발자가 나서기 시작합니다.
임베디드 디바이스에서는 부품 가격이나 메모리 공간이 한정돼 있기 때문에... 어쩌구...저쩌구...

임베디드 관점을 떠나 이런 사고 방식의 문제점은 바로 '프로세스가 빠를수록 낭비되는 명령어가 더 쌓이게 된다'라는 점입니다.
프로세서가 빠르다고 믿고 최적화에 대한 아무 고민없이 50% 정도 불필요한 코드(어셈블리 관점)가 실행이 된다고 가정합시다.

    * 불필요한 코드의 실행 속도가 아무리 빨라도 이를 삭제하는 것보다는 느릴 겁니다.

'밥을 먹으면 배부르다'와 같이 당연한 소리처럼 들리겠지만, 아예 불필요한 코드가 최적화로 제거되면 2배 빠르게 프로그램이 실행되니까요.

ARM 프로세서에서 최적화된 코딩을 해야 하는 결정적인 이유

ARM 프로세서에서 최적화된 코드를 작성해야 하는 가장 중요한 이유를 이야기하겠습니다. ARM 아키텍처나 ARM 코어의 동작 원리를 알면 그 이유를 알 수 있는데요. 결정적인 이유는 '메모리에 접근하는 비용은 ARM 프로세서의 다른 비용을 압도한다'라는 점입니다. 

또 다른 이유는 MCU나 SoC에 실장된 메인 메모리는 ARM 코어 내부에 있는 게이트와 레지스터보다 매우 느리다는 점입니다. 

이제는 하드웨어에서 물리학적인 관점으로 설명를 더 드리면요. 마이크로프로세서 칩에서 전자를 꺼내 상대적으로 광활한 구리 회로판 트레이스에 쏟아 넣고 그 트레이스를 몇 센티미터 아래에 있는 메모리 칩으로 이동시키는 일은, 마이크로프로세서 내부에서 트렌지스터를 분리하며 전자를 이동하는 작업보다 수천 배의 시간이 걸립니다.

결국, 메모리에 접근하는 비용은 프로세서의 다른 비용을 압도합니다.

'mov r0, r1' 와 같이 ARM 코어에 내장돼 있는 레지스터를 연산하는 일보다, 'ldr r1, [r0, #0x8]' 명령어와 같이 메모리 접근하는 동작이 더 많은 비용일 든다는 것입니다.

자, 여기서 'ldr r1, [r0, #0x8]' 명령어를 실행하면 ARM 코어에서 어떤 동작을 실행하는지 조금 더 짚어 봅시다.

'ldr r1, [r0, #0x8]' 명령어를 통해 접근한 데이터가 캐시에 있으면 그나마 다행일 겁니다. 운이 좋지 않게도 캐시에 데이터가 없으면 캐시 메모리 콘트롤러는 캐시 데이터 메모리 블록을 불러오고, 캐시 라인을 업데이트할 것입니다.

이 과정에서 AMBA와 같은 메모리 버스에 접근해 몇 가지 동작을 수행하게 됩니다. 여러 가지 복잡한 과정 중 Bus Transaction, Bus Transfer와 같은 일을 하게 됩니다.

여기서 제가 말하고 싶은 가장 중요한 포인트는 다음과 같습니다. 

    * ARM 코어와 같이 프로세서의 속도가 아무리 빨라져도 메인 메모리에 접근하는 인터페이스의 속도를 더 빠르게 만드는 
      경우는 거의 없다는 것입니다.

이해를 돕기 위해 자동차를 예를 들겠습니다. 자동차의 속도가 200km에서 400km로 늘어났다고 가정합시다. 어느 도로를 차가 달려도 건널목과 신호등들이 있기 마련일 것입니다. 자동차는 빨간 신호등을 보면 공회전을 하며 기다릴 수 밖에 없죠.

스피드를 개선하기 위해 코어의 갯수를 4개에서 8개로 늘려도 마찬가지입니다. ARM 코어끼리 메인 메모리에 접근하는 버스의 사이클을 얻기 위해 더 많은 경쟁(기다림)이 일어 날 꺼니까요. 

이런 성능의 한계를 메모리 장벽(Memory Barrier)라고 합니다.

정리

이번 포스팅에서는 '최적화가 왜 필요한지'에 대해 제 생각을 말씀드렸습니다.
앞으로는 ARM 프로세서의 특징을 활용한 C 코드 최적화 기법에 대해서 다루겠습니다.

---
"이 포스팅이 유익하다고 생각되시면 공감 혹은 댓글로 응원해주시면 감사하겠습니다. 
"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"

​Thanks,
Guillermo Austin Kim(austindh.kim@gmail.com)
---

덧글

  • 소여물 2020/07/05 12:35 # 삭제 답글

    어셈블리/C언어를 몰라도 무엇을 이야기하려는지 논점이 머리에 꽂히네요 감사합니다!!!
    농사꾼 독자 드림
  • AustinKim 2020/07/05 16:25 #

    네, 응원해주셔서 감사합니다.
    즐거운 주말 보내세요.
  • 2020/07/05 16:25 # 답글 비공개

    비공개 덧글입니다.
댓글 입력 영역