• 비교할 성능을 측정한다. 최적화가 제대로 되고 있는지 판단 및 성능 개선 효과 비교 측정용. 디버그 빌드 대신 릴리즈 빌드를 이용하여 측정한다.

• 인텔 VTune을 이용하여 가장 많은 시간이 걸리는 함수를 찾아낸다. 가장 많은 시간이 걸리는 함수가 가장 먼저 최적화를 수행할 부분이다. 이 부분을 최적화하는 것이 가장 효과적이다. 일반적으로 가장 많은 시간이 걸리는 몇 개의 함수만 최적화 한다. 보통 전체 수행 시간의 10% 이상되는 함수.

• “벡터화 보고서” 기능은 각 루프가 벡터화가 되었는지 아닌지 알려준다. 자동 벡터화 기능을 사용하기 위해서는 컴파일러 옵션 Level2나 Level3(-O2 또는 –O3)를 사용하여야 한다. 단계 2에서 찾은 핫스팟이 벡터화를 사용하고 있는지 아닌지 확인. 만약 벡터화가 안되어 있다는 메시지가 나오게 되면 왜 안 되는지 분석.

• 컴파일러 옵션 –vec-report2 또는 /Qvec-report2

• 인텔 컴파일러 GAP(Guided Auto-parallelization) 보고서 기능을 실행하여 컴파일러가 루프 벡터화를 어떻게 하는지 제안 내용을 봄. 

• 컴파일러 옵션 –guide 또는 /Qguide 

• 결과값이 변하지 않도록 주의하여 GAP에 의한 조언 및 제안 적용

• 원하는 성능까지 반복.

오프로드 모델을 위한 거대 페이지 설정

• MIC_USE_2MB_BUFFERS       2M 페이지 사용. 애플리케이션 실행시(Runtime) 포인터 기반의 변수값 길이가 설정되는 지금 이 값을 초과하면 거대 페이지에 할당될 것임.

#include <assert.h> 
#include <stdlib.h> 
#include <sys/mman.h> 

#define HUGE_PAGE_SIZE (2 * 1024 * 1024) 
#define ALIGN_TO_PAGE_SIZE(x) \ 
   (((x) + HUGE_PAGE_SIZE - 1) / HUGE_PAGE_SIZE * HUGE_PAGE_SIZE) 

void *malloc_huge_pages(size_t size) 
{ 
   // Use 1 extra page to store allocation metadata 
   // (libhugetlbfs is more efficient in this regard) 
   size_t real_size = ALIGN_TO_PAGE_SIZE(size + HUGE_PAGE_SIZE); 
   char *ptr = (char *)mmap(NULL, real_size, PROT_READ | PROT_WRITE, 
      MAP_PRIVATE | MAP_ANONYMOUS | 
      MAP_POPULATE | MAP_HUGETLB, -1, 0);
   if (ptr == MAP_FAILED) { 
      // The mmap() call failed. Try to malloc instead
      ptr = (char *)malloc(real_size);
      if (ptr == NULL) return NULL;
      real_size = 0;
} 

   // Save real_size since mmunmap() requires a size parameter 
   *((size_t *)ptr) = real_size; 

   // Skip the page with metadata 
   return ptr + HUGE_PAGE_SIZE; 
} 

void free_huge_pages(void *ptr) 
{ 
   if (ptr == NULL) return; 
   // Jump back to the page with metadata 
   void *real_ptr = (char *)ptr - HUGE_PAGE_SIZE; 
   // Read the original allocation size 
   size_t real_size = *((size_t *)real_ptr); 

   assert(real_size % HUGE_PAGE_SIZE == 0); 

   if (real_size != 0) 
      // The memory was allocated via mmap()
      // and must be deallocated via munmap() 
      munmap(real_ptr, real_size);
   else 
      // The memory was allocated via malloc() 
      // and must be deallocated via free()
      free(real_ptr);
}

왜 데이터 배치가 효율적인 벡터 처리에 영향을 미치는가?

• 메모리에서의 데이터 배치, 정렬 및 팩(Packed). 단정도 부동소수점 덧셈을 생각해 보자. c = a + b. 16개의 값을 각 입력 레지스터에 가져와야 한다. 이때, 메모리에 있는 데이터들이 동일 선상에 있고 512비트에 정렬이 잘 되어 있다면 한번의 벡터 읽기로 모든 데이터를 가져올 수 있다. 만약 정렬이 되어 있지 않다면 추가적인 명령어가 필요해서 더 많은 시간이 걸리게 된다. 컴파일러는 정렬을 강제하거나 변수들의 정렬을 위한 지시어들과 커멘드 라인 옵션을 제공한다. 
• 데이터 지역성
• 메모리가 아닌 캐시에서 데이터 읽기. 데이터는 궁극적으로 메모리에 있다. 그렇지만 벡터 읽기 명령어가 수행될 시점에 데이터들이 실행 유닛과 더 가까운 곳에서 읽혀 진다면 속도가 훨씬 더 빠를 것이다. 데이터들은 실제로 메모리에서 L2 캐시로 그리고 다시 L1 캐시로 이동된다. 이상적으로 이러한 동작은 데이터에서 L2 캐시로 미리 가져와지고(프리페치), 다시 L2에서 L1으로 그리고 마지막으로 L1 캐시에서 읽기(Load)명령어에 의해 데이터가 읽혀진다. 프리페치는 하드웨어 프리페치에 의해 시작되거나 컴파일러가 자동으로 아니면 프로그래머에 의해 수동으로 소프트웨어 프리페치에 의해 시작된다.
• 데이터 재사용. 만약 프로그램이 한 번 이상 사용되는 데이터를 캐시로 가져온다면 그런 데이터들은 서로 가까운 곳에서 있어야 한다. 이것을 임시 지역 참조성이라 한다. 데이터가 자주 재사용되는 것을 확실히 해주면 실제로 사용되기 전에 데이터가 캐시에서 밖으로 보내지는 것을 낮춰준다.
• Streaming Stores. 만약 프로그램이 나중에 다시 사용되지 않을 데이터를 쓴다면 Streaming Stores가 사용되게 하는 것이 중요하다. Streaming Store는 캐시 사용율을 높인다.

1. 데이터 정렬

2. 프리페치(Prefetching)

4가지 종류의 프리페치

1. 하드웨어가 자동으로 L2 캐시로 프리페치.
2. 컴파일러가 자동으로  L1 캐시로 프리페치하는 소프트웨어 명령어 생성
3. 프로그래머에 의해 지시를 받아서 컴파일러에 의해 생성된 프리페치 명령어
4. 프로그래머에 의한 수동 프리페치 명령어. L1, L2 모든 곳에서 프리페치사용 가능

컴파일러 prefetch

수동 프리페치(vprefetch0 과 vprefetch1 사용)

3. Streaming stores

Streaming Store의 성능 효과

컴파일러 옵션

-opt-streaming-stores keyword (리눅스, OS X)

/Qopt-streaming-stores: keyword (윈도우즈)

• 자동 벡터화: 컴파일러에 의해 자동화를 맡김 약간의 코드 변경이 필요할 수도 있으나 컴파일러 옵션으로 처리
• 수학 함수(MKL, IPP) 사용: 이미 라이브러리 회사의 엔지니어가 벡터화뿐만 아니라 병렬화 및 기타 다른 모든 가능한 최적화 방법을 이용하여 모든 컴퓨팅 자원을 활용하여 최적의 성능을 낼 수 있도록 만들어 놨음. 향후 아키텍처를 위해 코드의 변경 등이 필요 없음. 인텔® MKL(Math Kernel Library) 및 인텔® IPP(Integrated Performance Primitives)는 병렬화 및 벡터처리를 모두 구현한 라이브러리의 좋은 두 가지 예. 분산 메모리 병렬 컴퓨터를 위한 MPI와 같은 병렬 프로그래밍 모델도 라이브러리로 제공됨.
• SIMD 지시어: SIMD지시어는 벡터화를 수행하도록 하는 간단하고 효과적인 방법. 프로그래머가 모든 것을 제어함. 그렇지만 아무 루프나 병렬화 하면 위험할 수 있으며 값이 달라질 수 있으니 주의해서 사용하여야 함.
• 배열 표기법(Array Annotation): 프로그래머의 의도를 반영하는 직관적인 구문. 포트란에서는 배열 표기법을 지원해왔으나 C/C++에서는 확장언어인 실크 플러스에서 지원함. 실크 플러스의 배열 표기법은 병렬화를 위한 유연하고 아주 강력한 방법임.
• 실크 플러스의 벡터 함수 사용: C/C++의 확장 언어로서 안정적이며 예측 가능한 언어이다. 실크 플러스의 벡터 함수 사용 장점은 기존의 코드가 병렬로 벡터처리가 가능했지만 한번에 한번의 처리를 해 왔었다면, 이 코드들을 유지하면서 병렬화를 할 수 있다는 것이 커다란 장점임.

• A + B = C

벡터와 스칼라의 도식적 비교

1. 효율적인 벡터화
코드는 제온 파이에 있는 512비트 벡터를 효율적으로 사용할 수 있어야 한다. 입력 데이터 집합이 보조 프로세서가 사용할 수 있을 정도의 충분한 작업 양을 제공해야 한다.

• 입력 배열 크기가 충분히 길어야 한다
• 메모리에 있는 작업 데이터 집합들이 최적의 벡터 읽기(Load)와 쓰기(Store)가 되도록 적절하게 정렬(aligned) 되어야 한다
• 작업 데이터들은 하나의 덩어리로 구성되어야 한다. 따라서 캐시 라인을 채울 때 연속적인 영역에서 연속적인 데이터들이어야 한다. 여러 곳에 있는 데이터로부터 가져오려면 성능 저하가 따른다


2. 확장성이 있는 병렬화
코드는 모든 가용 코어에 확장할 수 있어야 함. 모든 스레드에 확장되도록 하면 더욱 좋다. 스레드 수준에서 벡터화를 해야 할 뿐만 아니라 애플리케이션의 알고리즘이 많은 수의 스레드에 확장할 수 있어야 한다.


3. 최적의 캐시 재활용
최적의 캐시 재활용은 메모리 대역폭의 제한을 극복하고 실질 Flops/Byte를 증가시켜준다. 각 데이터 구조는 최적의 캐시 재사용을 위해 다음 특성을 가져야 한다.
• 가능하면 보조 프로세서에서 동작하는 모든 스레드가 한번에 데이터를 접근하기 위해 배열의 구조를 정렬된 배열 구조로 바꿔라(Data Align).
• 데이터 구조를 단위로 묶어라. 데이터는 캐시에 맞게 동작할 수 있기 위해 기본 단위로 나뉠 수 있어야 한다.

• Streaming Stores
• Scatter/Gather
• 거대 페이지 (2MB)
• 프리패치 분석 / 튜닝

오프로드 MPI 모델

오프로드 MPI 모델

보조 프로세서만의 MPI 모델

보조 프로세서 MPI 모델

대칭 MPI 모델

대칭 MPI 모델

인텔 제온 보조 프로세서 프로그래밍 모델

• 멀티 코어 호스팅 모델: 멀티 코어, 즉 CPU에서 범용의 직렬과 병렬 컴퓨팅 코드들이 실행되는 모델이다. 현재 대다수의 프로그램들이 이 경우에 속한다. Main() 함수와 작업 함수인 Foo() 함수가 멀티 코어 CPU에서만 수행 된다. 프로그램의 병렬화와 벡터화가 여려울 때 CPU에서 돌리는 것이 성능측면에서 좋다.

• 오프로드 모델: 보통 많은 코드가 직렬인 부분과 병렬적인 코드가 섞여 동작하는 프로그램이 많다. 이때 직렬적인 코드들은 직렬 코드 처리의 효율성이 더 좋은 CPU에서 작업 하고 병렬성이 높은 코드를 보조 프로세서에게 작업을 일임하는 모델이다. 특정 작업을 그 일을 잘하는 전문가에게 맡기는 경우라고 할 수 있다. 그림에서 Foo()함수가 병렬성이 아주 좋은 코드이고 계산의 많은 부분을 차지하는 코드라면 이 부분을 좀 더 효율성이 높은 보조 프로세서에서 처리하게 하는 것이 전반적인 성능을 높일 수 있다. MPI 함수를 통해서 다른 시스템 간의 통신을 한다.

• 균등 분산 모델: 모든 코드가 CPU와 보조 프로세서에서 독립적으로 함께 동작하는 모델이다. 제온 파이도 하나의 별도 독립된 시스템으로 간주하고 각각 CPU와 보조 프로세서에서 실행을 함으로써 프로그램의 최대 성능을 얻는 모델이다. 병렬화와 벡터화가 잘 돼있는 코드가 최적의 성능을 얻을 수 있다. 이 모델은 기존의 CPU 기반의 클러스터를 위한 MPI 애플리케이션 사용자에게 가장 끌리는 모델이다. 왜냐하면 데이터 오프로드를 위해 코드의 재 구성없이 보조 프로세서를 사용할 수 있고 또한 HPC 애플리케이션의 성능 향상을 얻을 수 있기 때문이다.

• 매니코어 호스팅: 일반적으로 네이티브 모드라고 하는 모델이다. 모든 코드가 제온 파이 보조 프로세서에서 동작을 한다. 역시 모든 코드들이 병렬화와 벡터화가 잘 되어 있어야만 좋은 성능을 얻을 수 있다. 컴파일 옵션으로 코드를 쉽게 만들 수 있다. CPU만에서 동작하는 코드를 포팅할 때 코드의 특성을 보기 위해 한 번 쉽게 해볼 수 있는 모델이다.