도커 빌드부터 떠먹여주는 강의

• 미래의 나를 위해
• 까먹는다.

C++17 execution 이란?

• C++의 표준알고리즘의 첫번째 인자로 병렬처리 policy (seq, unseq, par, par_unseq 중 하나) 지정해주면, 컴파일러가 알아서 멀티코어를 활용하는 실행파일을 생성해주는 문법을 의미한다.
• 자세한 설명은 웹에 많으니 생략한다.
• 대신 직접 실험하려면 어떻게 해야 하는지에 대한 연말휴가기록.

실습

• 냅다 실습해보자.
  • 모든 파일들은 여기에: C++17 execution policy practice with oneTBB
• 차례대로 알아보자.

1. 모든 실습의 시작은 도커이미지 굽기 부터

• 후술하겠지만 gcc version 에 따라 빌드가 되기도 안되기도 한다.
• 따라서 기본적으로 모든 실습의 기본은 환경 격리를 선호하도록 하자.
• 도커를 활용하자.
  • 도커에 대한 자세한 설명은 생략한다.
• Dockerfile.22.04 이란 이름의 파일에 다음과 같이 입력하자.
  • ps. 확장자는 있어도 되고 없어도 된다. Dockerfile 이라고 무확장자로 이름짓는 게 가장 기본적인 규칙이지만 맘대로 지어도 상관없다.

      FROM ubuntu:22.04
    
      # 필수 패키지 설치
          RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y \
          build-essential \
          g++ \
          cmake \
          git
    
      # 작업 디렉토리 설정
      WORKDIR /usr/src/myapp
    

    • 추후에 몇 가지 필요한 것을 더 설치할 예정이다.
      • 그것들을 원래 Dockerfile 안에 모두 기입하여 원샷으로 더 편하게 하면 좋겠지만
      • 스텝바이스텝으로 보여주기 위해 일단 가장 기본적인 내용만 구웠다.
      • 이 정도 베이스로만 구우면 빨리 구워지고 용량도 작아서 좋다. 이번 실험외에 평소에도 다양한 실험들을 깨끗하게 시작해보고 싶을 때 공통적인 미니멀한 베이스로 쓰기 좋 다.
  • 그나저나 C++ project 를 수행할 때에는 자신의 C++ 생태계에 대해서도 잘 알아야 한다 (== C++보다 좋은 언어가 나왔다고 해서 거기로 바로 갈 수 없는 이유).
    • 특히 텍스트를 바이너리로 바꿔주는 건 컴파일러(와 링커) 인 g++ 이기 때문에, g++ 버전이 몇인지 습관적으로 체크하도록 하자.
      • 그리고 이 모든 버전들은 디폴트 조합들이 존재한다.
        • 예를 들어 위에서처럼 간단히 g++ 라고 하면 OS 버전에 따라서 디폴트 버전을 잡는 것이 다르다.
          • FROM ubuntu:22.04 할 경우 (g++ -v 해보면) 기본적으로 11.4를 설치한다.
          • FROM ubuntu:20.04 할 경우 기본적으로 9.4를 설치한다.
• 터미널에서 이렇게 하면 이미지가 구워진다.

  $ docker buildx build -f ./Dockerfile.22.04 -t cpp-experiment:22.04 .
  

  • 마지막에 . 은 Dockerfile.22.04 이란게 현재 디렉토리에 있음을 의미한다.
• $ docker images라고 하면 구워진 이미지를 볼 수 있다.
  • 예시

      REPOSITORY         TAG          IMAGE ID       CREATED         SIZE
      cpp-experiment     22.04        f5621b4b7d84   10 hours ago    1.24GB
    

2. 도커 컨테이너 띄우기

• docker run 어쩌구 하면 도커 이미지로부터 컨테이너를 인스턴스화 할 수 있다.
• 근데 뒤에 붙는 argument들을 매번 치는 게 귀찮기 때문에 스크립트화 하자.
  • 예를 들어서, run_tbb.22.04.sh라고 하고 다음과 같이 써준다.

      echo Using 0 to $1 cores 
    
      docker run -ti --rm \
          --cpuset-cpus="0-$1" \
          --name my-running-app-2204 \
          -v $PWD:/usr/src/myapp \
          cpp-experiment:22.04 \
          bash
    

    • 이번 실험 (후술) 에서 코어 개수에 따른 성능차이를 보기 위해 이렇게 편하게 받도록 하였다. 터미널에서 $ ./run_tbb.22.04.sh 5 이런식으로 두번째 인자로 숫자를 준다. 5라고 하면 0번 코어부터 5번코어까지 사용한다는 뜻이다.
    • docker run 할 때 --cpuset-cpus 옵션을 주면 컨테이너에 할당할 호스트 CPU를 명시적으로 지정해줄 수 있다. 즉 라이브러리 환경의 격리뿐 아니라 자원의 격리를 세팅해줄 수도 있다.
  • 그래서 현재 폴더에 이런것들이 있을 때,

      ╰─$ pwd    
      /home/gskim/Documents/cpp17execution/blog
    
      ╰─$ ls
      Dockerfile.22.04  main.cpp  run_tbb.22.04.sh
    

  • 터미널에서 이 위치에서, $ chmod +x run_tbb.22.04.sh 한 다음에 $ run_tbb.22.04.sh 3 이렇게 해주면 CPU 코어 개수를 제한하여 도커 컨테이너 터미널 속으로 들어갈 수 있다.
    • 도커빌드할 때 WORKDIR /usr/src/myapp라고 지정했기 때문에, 도커 컨테이너 터미널로 들어가면 바로 /usr/src/myapp 라는 위치에 존재하게 된다. 그래서 편의상, -v $PWD:/usr/src/myapp라고 해서, 소스코드가 있는 현재 호스트의 디렉토리를 도커이미지의 /usr/src/myapp 에 마운트해주었다.

3. 빌드 및 실행: 1차시도

• 위 경로에 있는 실험파일인 main.cpp는 다음과 같다.
  • 이 코드는 내가 짠 것은 아니고 cppreference에 있는 것을 거의 그대로 가져온 것이다.
    • 이유: 가장 기본적인 실습에는 항상 변인이 통제되면 좋기 때문이다 (즉, 세팅은 모두 제대로 했지만 내가 직접 짠 코드에 존재하는 결함으로 병렬실행실험이 제대로 안될 수도 있으므로).

      #include <algorithm>
      #include <chrono>
      #include <cstdint>
      #include <iostream>
      #include <random>
      #include <string>
      #include <vector>
    
      #ifdef PARALLEL
      // clang-format off
      #include <execution>
      // clang-format on
      namespace execution = std::execution;
      #else
      enum class execution { seq, unseq, par_unseq, par };
      #endif
    
      void measure([[maybe_unused]] auto policy, const std::string policy_name,
                   std::vector<std::uint64_t> v) {
          const auto start = std::chrono::steady_clock::now();
      #ifdef PARALLEL
          std::sort(policy, v.begin(), v.end());
      #else
          std::sort(v.begin(), v.end());
      #endif
          const auto finish = std::chrono::steady_clock::now();
          auto duration =
              std::chrono::duration_cast<std::chrono::milliseconds>(finish - start);
          std::cout << policy_name << ": " << duration.count() << " milliseconds"
                    << std::endl;
      };
    
      int main() {
          std::vector<std::uint64_t> v(1'000'000);
          std::mt19937 gen{std::random_device{}()};
          std::ranges::generate(v, gen);
    
      #ifdef PARALLEL
          measure(execution::seq, "seq      ", v);
          measure(execution::unseq, "unseq    ", v);
          measure(execution::par_unseq, "par_unseq", v);
          measure(execution::par, "par      ", v);
      #else
          measure(execution::seq, "No execution policy", v);
      #endif
    
          return 0;
      }
    

• 일단 모든 코어를 다 사용했을 때 얼마나 성능이득이 있는지 확인하자
  • core 20개 짜리인 i7-13700H 에서 테스트 하였다.
  • 19 라고 해서 0번부터 19번 코어까지 다 할당해보자.

      $ run_tbb.22.04.sh 19
    

1. 1차시도-1 (no par)
   • 일단 시도1에서는 의도적으로 빌드할 때 -DPARALLEL option 을 인자로 주지 않아 본다 (위 코드의 #ifdef 블록 참고).
     • 때문에 아마 성능 이득이 없을 것이다.
   • 1차시도 1a: no par no opt
     • 방금 19개 코어를 할당하여 들어온 도커 컨테이너 속 터미널에서 이렇게 입력해서 빌드해주자.

         $ g++ -std=c++20 main.cpp -o main
       

       • ps: cpp20부터 도입 된 ‘The big four’ 중 하나인 range 를 활용하고 있어서 c++20 으로 빌드해주었다.
     • $ ./main 해서 실행 (3번) 해주면 이런 결과가 나왔다.

         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 479 milliseconds
       
         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 460 milliseconds
       
         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 529 milliseconds
       

     • 그런데 마이크로벤치마크 할 때 -O3 를 넣지 않고 하는 것은 의미없다.
   • 1차시도 1b: no par (O3 opt as default)
     • 다음과 같이 다시 빌드해서 실행해보자.

         $ g++ -std=c++20 -O3 main.cpp -o main
       

     • $ ./main 해서 실행 (3번) 해주면 이런 결과가 나왔다.

         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 170 milliseconds
       
         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 156 milliseconds
       
         root@82b404f8eac1:/usr/src/myapp# ./main 
         No execution policy: 144 milliseconds
       

   • 이로부터 우리는 다음과 같은 사실을 알 수 있다.
     1. 일단 당연히 컴파일러최적화 (O3) 는 걸어주어야 한다.
     2. 병렬처리 하지 않으면 저정도 나온다. (베이스라인 확보)
        • 물론 n 마다, 머신마다 다르기 때문에 항상 자기 머신에서 측정한 결과로만 말해야 한다.
2. 1차시도-2 (par)
   • 이제 베이스라인 실험결과가 확보되었기 때문에 병렬처리 결과를 얻어보자.
     • ps. O3 는 항상 걸어준다.
   • -DPARALLEL 인자를 넣어서 빌드한다.

       $ g++ -std=c++20 -O3 main.cpp -DPARALLEL -o main
     

   • 마찬가지로 3번 정도 실행해보면

       root@82b404f8eac1:/usr/src/myapp# ./main 
       seq      : 135 milliseconds
       unseq    : 142 milliseconds
       par_unseq: 164 milliseconds
       par      : 148 milliseconds
     
       root@82b404f8eac1:/usr/src/myapp# ./main 
       seq      : 153 milliseconds
       unseq    : 151 milliseconds
       par_unseq: 131 milliseconds
       par      : 129 milliseconds
     
       root@82b404f8eac1:/usr/src/myapp# ./main 
       seq      : 146 milliseconds
       unseq    : 136 milliseconds
       par_unseq: 132 milliseconds
       par      : 144 milliseconds
     

   • ❓❓❓
     • 전혀 병렬처리가 안되고 있음을 알 수 있다.
   • 앞서 원래 코드예시였던 cppreference 에 단서가 있을 지 다시 가보자.

     

   • 아하
     • -ltbb 와 같이 tbb 를 링크해주어야 한다.
       • gcc는 (저 예제에서는 gcc13을 사용하고 있음) c++17 execution policy의 text code를 binary로 변환하기 위해 내부적으로는 tbb를 사용하고 있는 듯하다.
   • -ltbb라고 넣어서 빌드를 시도하면, 즉:

       $ g++ -std=c++20 -O3 main.cpp -DPARALLEL -ltbb -o main
     

   • 이렇게 못찾겠다고 링크 에러가 뜬다.

       /usr/bin/ld: cannot find -ltbb: No such file or directory
       collect2: error: ld returned 1 exit status
     

4. 2차시도: TBB 라이브러리 설치

• tbb 를 따로 설치를 해주어야 한다는 것을 알 수 있다.

1. 방법 1: apt-get 이용

    $ apt-get install libtbb-dev
   

   • 이렇게 하면 이 글 작성 기준, 버전은
     • 20.04 에서는 libtbb-dev is already the newest version (2020.1-2) 가
     • 22.04 에서는 libtbb-dev is already the newest version (2021.5.0-7ubuntu2) 가 기본으로 설치된다.
   • 확인 방법
     • 위의 apt-get install 설치 후 해당 명령어를 한번 더 입력하면 위와 같이 출력이 나오고,
     • 혹은 코드 상에서 /* #include <tbb/tbb.h> */ std::cout << "TBB Version: " << TBB_VERSION_MAJOR << "." << TBB_VERSION_MINOR << std::endl; 와 같이 해주어도 버전을 볼 수 있겠다.
   • 첨언
     • 굳이 (이제 2024년에) Ubuntu 18.04 에서 하는 것을 추천하지는 않는다.
       • 뭔가 이것을 시도하는 사람들의 노력이 눈물겹다.
     • 그나저나 tbb release notes 를 보면 2020년 초 이름이 Threading Building Blocks 에서 oneTBB 로 변경되었다. 그 사이 호환성 문제도 있을까?

       

       • 암튼 그 이유는 공식 리드미에 따르면 에코시스템에 편입됨 어쩌구

         

2. 방법 2: 직접 빌드
   • 공식 깃허브 리드미 를 참고해서 빌드해주면 된다.
     • 직접 빌드할 때의 장점은 특정 버전을 콕 집어서 사용해줄 수 있다는 것이다.
   • 빌드 및 라이브러리 설치과정을 하나하나 다 적어보자면
     • 일단 $ run_tbb.22.04.sh 19 해서 도커 컨테이너로 들어온다.
       • 19는 대충 맥스 코어 숫자 (현재 예시에서는 20개 코어 CPU사용 중이므로). 각자 머신에 맞게 하면 된다. oneTBB library를 빌드 할 때 빠르게 빌드하려면 -j option을 주어야 하는데 이를 위해 코어를 많이 물고 들어가야 한다.
     • 그 다음부터 아래처럼 해주자.

         $ git clone https://github.com/oneapi-src/oneTBB
         $ cd oneTBB
         $ mkdir build 
         $ cmake -DTBB_TEST=OFF .. // test까지 빌드할 필요는 없다. 이걸 빌드하고 있으면 시간이 매우 오래  걸린다.
         $ cmake --build . -j
         $ cmake --install .
       

   • 현재 이 글을 작성하고 있는 시점에서 git clone 해서 master branch의 최신을 당겨왔더니 TBB Version: 2021.12 로 출력되었다.
     • 참고로 앞서 ubuntu22.04 를 베이스이미지로 해서, 디폴트로 apt-get install 로 설치된 것의 버전은 TBB Version: 2021.5 였다.
   • 사용하는 입장에서 그 차이를 느낄 기능을 쓰고 있지는 않지만, 직접 빌드해보는 실습을 해보았다.
   • 첨언
     • ubuntu20.04 를 베이스이미지로 해서 master branch의 최신을 당겨와서 (즉, TBB Version: 2021.12) 직접 소스코드를 빌드하려고 하면 컴파일 에러들이 나타난다.
       • ubuntu20.04 에서 apt-get install g++ 하면 기본적으로 version 9.4 가 설치되는데 이게 최신 oneTBB 를 빌드할 수 없는 듯 하다.
         • g++ 버전을 11로 강제로 업그레이드 해주고 빌드를 수행하니 최신 TBB버전을 빌드할 수 있었다.
           • 이런 조합은 검색해도 잘 안나오기 때문에 코드가 문제가 있나라고 잘못 의심하느라 시간을 많이 낭비할 수 있다. 컴파일러 버전 호환성도 늘 의심해보자. 그리고 몇 개 조합을 직접 수행해서 되는 조합을 실험적으로 찾고 기록하자.

• 설치확인
  • 이렇게 하면 tbb가 어디에 어떻게 설치되었는지 확인해볼 수 있다.

      $ find /usr/include /usr/local/include -name '*tbb*'
    

    • tip. bat이라고 cat보다 좋은 툴이 있는데 이거 설치 후 $ batcat [파일명] 과 같이 입력하면 터미널에서 파일을 볼 때 좀 더 편안하고 예쁘게 볼 수 있다.

5. Application 빌드

• 앞서 ubuntu 22.04 기준,
  • g++ version 11.4 를 이용해서,
  • TBB (oneTBB) version 2021.5 혹은 2021.12 를 무사히 설치하였다.
    • ps. 이렇게 설치한 변경점들을 안 날려먹기 위해서는 docker commit [컨테이너이름] [이미지이름:태그] 해주어야 저장이 된다.
      • 혹은 이런 설치과정들을 위의 Dockerfile 파일에 모두 합쳐두는 게 좋다.
• 이것은 라이브러리를 빌드 및 설치 한 것이고,
• 이제 우리의 어플리케이션을 빌드 및 실행해보자.

1. 방법 1: 스크립트로 빌드
   • 앞서 얘기했듯, 이렇게 하면 한줄컷이다.
     • 도커 컨테이너 안으로 들어온 다음,

         $ g++ -std=c++20 -O3 main.cpp -DPARALLEL -ltbb -o main
       

     • ps. g++ version 9 에서는 c++20이라고 하면 못알아 듣고 c++2a 라고 해야 알아 듣는다.
   • 그러면 바이너리가 생성되고 $ ./main 이라고 하면 실행된다.
2. 방법 2: cmake 기반 빌드
   • 사실 파일 하나 짜리 프로젝트가 (당연히) 아닐 때에는, 이게 정석이다.
   • cmake 같은 게 (CMakeLists.txt 파일 작성하는 게) 따로 시간내서 공부하기 되게 귀찮고 까다로운데
   • ChatGPT4 시대가 오면서 해피해졌다. ‘해 줘’ 라고 하면 이렇게 해준다.

     

   • 물론 사용자가 검증은 해야겠지만, 경험적으로 이런 work은 대체로 잘 한다.
   • 저렇게 CMakeLists.txt 파일을 작성한 뒤 하던대로 하면 되겠다.
     • 즉, 도커 컨테이너 안으로 들어온 다음,

         $ mkdir build 
         $ cd build 
         $ cmake ..
         $ make -j
       

   • 그러면 바이너리가 생성되고 $ ./main 이라고 하면 실행된다.

6. 실행 결과

• 이제 병렬처리가 잘 된다. 5번 실행해보면 일관되게 par 사용 시 개선이 있음 (코어 20개 사용) 을 알 수 있다.

    root@65461ff9d981:/usr/src/myapp/build# ./main 
  
    seq      : 147 milliseconds
    unseq    : 145 milliseconds
    par_unseq: 24 milliseconds
    par      : 24 milliseconds
  
    root@65461ff9d981:/usr/src/myapp/build# ./main 
    seq      : 138 milliseconds
    unseq    : 131 milliseconds
    par_unseq: 20 milliseconds
    par      : 21 milliseconds
  
    root@65461ff9d981:/usr/src/myapp/build# ./main 
    seq      : 146 milliseconds
    unseq    : 136 milliseconds
    par_unseq: 22 milliseconds
    par      : 21 milliseconds
  
    root@65461ff9d981:/usr/src/myapp/build# ./main 
    seq      : 132 milliseconds
    unseq    : 132 milliseconds
    par_unseq: 20 milliseconds
    par      : 21 milliseconds
  
    root@65461ff9d981:/usr/src/myapp/build# ./main 
    seq      : 129 milliseconds
    unseq    : 129 milliseconds
    par_unseq: 22 milliseconds
    par      : 25 milliseconds
  

7-1. Ablation 1: core 수 달리해보며

• 그럼 이제 코어수를 1개부터 20개까지 달리해가며 실험해보자.
  • 실험 환경은 i7-13700H
• 근데 매번 도커 컨테이너 들어갔다가 빌드 새로 했다가 나왔다가 하기 귀찮으니 자동화 해보자
• 먼저 실험 한 번의 수행을 하나의 스크립트화를 한다.

    docker run -ti --rm \
        --cpuset-cpus="0-$1" \
        --name my-running-app-2204 \
        -v $PWD:/usr/src/myapp \
        cpp-experiment:22.04 \
        /bin/bash -c "cd /usr/src/myapp/build && \
            rm -rf * && \
            cmake .. && \
            make -j$num_cores && \
            ./main"
  
    echo ""
    echo We used 0 to $1 cores 
  

  • 이렇게 하면 도커컨테이너 진입 후 bash 터미널에서 대기하는 것이 아니라 main을 빌드하고 실행하고 종료하고 빠져나온다.
    • --rm 옵션을 주었기 때문에 컨테이너는 할일을 다하고 종료 후 삭제된다.
  • 이 스크립트를 run_tbb.22.04_auto.sh 라고 하자.
• 그 다음 이렇게 한다음 이걸 실행하고 커피한모금 마시고 오면 된다.

    #!/bin/bash
  
    # 0부터 19까지 반복
    for i in {0..19}
    do
        echo "Running with 0 to $i cores"
        ./run_tbb.22.04_auto.sh $i
        echo ""
    done
  

• 그 다음 terminal 에 출력된 텍스트 결과물을 대충 복사해서 ChatGPT에게 그려줘라고 말하면

  

  • 해석
    • note: 일단 각 가로축 데이터포인트마다 여러번 실행해서 평균낸게 아니라 한번만 실행했기 때문에 + 다른 프로세스도 많이 돌고 있는 상태에서 그냥 실행했기 때문에 노이즈가 있을 수 있다 (예: x=19).
    • 전체적인 경향만 보면 그래도 확연히 보인다.
    • par 이득이 확실히 있었다.
    • unseq (검정) 은 seq에 비해 대충 plot이 아래에 경향이 위치하긴 하지만 비슷해보인다.
      • ps. unseq (~ simd) 자체는 single core 에서 작동하는 것으로 알고 있다. 이 태스크가 vectorized 되기에 적합한 태스크인지 아닌지는 잘 모르겠고 일단 실험적으로 이렇게 검증해보고 넘어가는 수밖에… 없지만 추후에 공부해보도록 하자.
    • 코어 1개에서 2개, 3개가 될 때까지는 정직하게 n 배에 가까운 이득을 보았다.
      • 물론 이는 태스크마다 다를 수 있으니 측정을 통해 판단해야 되겠다.
      • 코어를 20개 쓴다고 해서 들인 노력대비 20배의 이득이 있지는 않음을 의미한다.

7-2. Ablation 2: core 수 달리해보며 on 다른 예제

• 500만개 포인트의 좌표를 변환해보자.

    #include <array>
    #include <chrono>
    #include <execution>
    #include <iostream>
    #include <valarray>
  
    struct Point3D {
        std::valarray<double> coordinates;
  
        Point3D(double x, double y, double z) : coordinates({x, y, z}) {}
    };
  
    using Matrix3x3 = std::array<std::valarray<double>, 3>;
  
    Point3D applyTransformation(const Point3D& point,
                                const Matrix3x3& rotationMatrix,
                                const Point3D& translation) {
        std::valarray<double> rotated(3);
        for (int i = 0; i < 3; ++i) {
            rotated[i] = (rotationMatrix[i] * point.coordinates).sum();
        }
        return Point3D(rotated[0] + translation.coordinates[0],
                       rotated[1] + translation.coordinates[1],
                       rotated[2] + translation.coordinates[2]);
    }
  
    int main() {
        // 예제 데이터: n개 3D 포인트
        std::vector<Point3D> points(5'000'000, Point3D(1.0, 2.0, 3.0));
  
        // 회전 행렬 및 이동 벡터 정의
        Matrix3x3 rotationMatrix = {std::valarray<double>{0, -1, 0},
                                    std::valarray<double>{1, 0, 0},
                                    std::valarray<double>{0, 0, 1}};
        Point3D translation(1.0, 2.0, 3.0);
  
        // 변환 시작 시간 측정
        auto start = std::chrono::high_resolution_clock::now();
  
        // 모든 포인트에 대해 변환 적용
  
        std::for_each(std::execution::par /* CHANGE HERE! */, 
                      points.begin(), points.end(),
                      [&rotationMatrix, &translation](auto& point) {
                          point = applyTransformation(point, rotationMatrix,
                                                      translation);
                      });
  
        // 변환 종료 시간 측정
        auto end = std::chrono::high_resolution_clock::now();
  
        // 소요된 시간 계산 및 출력
        auto duration =
            std::chrono::duration_cast<std::chrono::milliseconds>(end - start)
                .count();
        std::cout << "Transformations completed in " << duration << " ms"
                  << std::endl;
  
        return 0;
    }
  

• 결과

  

  • 이 실험에서는 vectorization 을 시도하는 것 (== unseq) 이 시간을 더 잡아먹었다.
  • par 사용시 역시 초반 3-4 코어 정도까지 선형적인 성능이득이 있고 이후에는 under linear 하다.

7-3. Ablation 3: 다른 머신

• AMD Ryzen™ 5 7530U 노트북에서도 TBB가 잘 설치되었다.
  • 위의 어플리케이션들에서 성능 이득을 역시 관찰할 수 있었다.

결론

• C++17에 도입된 execution policy는 c++ 의 functional 한 algorithm에 결합하여 사용하기 좋다.
  • 사용자가 들이는 코드 작성에서의 노력은 거의 없으면서 멀티코어 이득을 쉽게 챙길 수 있다.
• (gcc의 경우) execution policy를 컴파일 하기 위해서는 tbb 라이브러리를 링크해야 한다.
  • gcc 버전과 tbb 버전을 잘 맞춰주자. 혹은 apt-get 으로 설치했더라도 gcc 와 tbb 버전이 각각 어떠한지 습관적으로 관찰하고 넘어가자.
• 그리고 이렇게 설치한 TBB 라이브러리가 실제로 잘 작동하는지 기본적인 벤치마크 테스트코드들 (위에서는 두 개를 소개) 을 직접 구성하고 실험해보았다.
• 실습 2편에서는 oneTBB의 다른 기능들 및 병렬처리에 관한 좀 더 이론적인 부분에 대해 알아보자.