(논문) Tiered Memory Management: Access Latency is the Key!, SOSP'24 (5. Evaluation)

본 글은 논문 Tiered Memory Management: Access Latency is the Key! (SOSP 2024) 를 읽고 정리한 글입니다.

별도의 명시가 없는 한, 본 글의 모든 그림은 위 논문에서 가져왔습니다.

목차

• 1. Introduction
• 2. Motivation
• 3. Colloid
• 4. Colloid with Existing Memory Tiering Systems
• 5. Evaluation (현재 글)
• 6-7. Related Work and Conclusion

5.0. Setup §

NXSECTION

• 5.0 은 evaluation setup 으로, 논문에는 이런 section 은 없다.

• 본 section 에서는 HeMem, MEMTIS, TPP 에 Colloid 를 적용했을 때와 안했을 때에 대한 evaluation 결과를 설명한다.
• 실험 setting 은:
  • 일단 Section 2.1. 에서와 동일한 환경이고
  • 설정값들은 별도 명시가 없는 한 전부 기본값으로 되어 있으며
  • TPP + Colloid 의 경우에는 Transparent Hugepages 를 활성화한 결과이고, 비활성화한 것은 여기 에 있다고 한다 ¹.
  • 그리고, $ϵ=0.01$ 으로, $\delta =0.05$ 로 세팅하였다. 이때, 이 값을 변화시키며 실험한 것도 여기 에 있다고 한다 ².
• 실험에서 집중한 metric 은:
  • Steady-state 일때의 application throughput
  • Workload 혹은 memory interconnect contention 의 변화에 대한 convergence time
  • 그리고 real-world application 에 대해서는, 해당 application 에 specific 한 metric 이다.

5.1. Steady-state Throughput §

5.1.0. Result §

NXSECTION

• 5.1.0 은 실험 결과로, 논문에는 이런 section 은 없다.

• Section 2.2.0. 와 동일한 그래프를 그려보면 다음과 같다.
• 일단 아래의 그림이 Section 2.2.0. 의 그래프이고,

• 그리고 이 그림이 Colloid 를 추가했을 때의 그래프이다.

• 보면 일단 전체적으로 Colloid 를 활성화시켰을 때 성능이 대폭 향상하는 것을 알 수 있다.
• $0\times$ 일 때는 모든 system 이 Colloid 가 있을 때와 없을 때에 동일한 성능을 보이고, best case 와도 유사한 성능을 보여주는 것을 알 수 있다.
• 근데 memory interconnect contention 이 증가함에 따라, benefit 이 Colloid 가 없을 때에 비해 훨씬 두드러지는 것을 볼 수 있다. 각각:
  • HeMem 은 $1.2\times$ ~ $2.3\times$,
  • TPP 는 $1.35\times$ ~ $2.35\times$,
  • MEMTIS 은 $1.29\times$ ~ $2.3\times$ 배의 throughput 이득이 있다.
• 또한 memory interconnect contention 과는 무관하게, Colloid 를 사용했을 경우 best case 와 유사한 성능을 보여준다. 각각 best case 와:
  • HeMem + Colloid 는 3%,
  • TPP + Colloid 는 8%,
  • MEMTIS + Colloid 는 13% 이내의 차이를 보여준다.

5.1.1. Understanding Colloid benefits. §

• 그럼 Section 2.2.1. 의 그래프도 비교를 해보자. 아래놈이 Section 2.2.1. 의 그래프이고,

• 이놈은 Colloid 를 추가했을 때에 대한 그래프이다.

• Section 2.2.1. 에서와는 달리, 이제는 HeMem, TPP, MEMTIS 에서도 memory interconnect contention 이 증가함에 따라 alternate tier 에 더 많은 hot page 들을 위치시키는 것을 알 수 있다.
• 그리고 Section 2.2.2. 의 그래프도 비교를 해보자. 아래의 그래프가 Section 2.2.2. 의 것이고,

• 이놈은 Colloid 를 추가했을 때에 대한 그래프이다.

• 보면 일단 default tier 와 alternate tier 간의 latency 차이가 확연하게 줄어든 것을 볼 수 있다.
• $0\times$ 일 때는 hot page 의 전부가 default tier 로 가있게 되는데, 이때에도 둘 간의 latency 차이를 줄이지 못해 여전히 default tier 의 latency 가 좀 더 낮은 것을 볼 수 있고,
• $1\times$ 일 때는 default 와 alternate tier 간의 balance 가 맞은 것이며
• $2\times$ 와 $3\times$ 일 때는 alternate tier 에 모든 hot page 를 배치해도 여전히 latency 차이가 줄어들지 못해 alternate tier 의 latency 가 좀 더 낮은 것을 볼 수 있다.

5.1.2. Impact of alternate tier unloaded latency. §

• 추가적으로 다양한 상황들에 대한 evaluation 을 진행해 다양한 상황에서 Colloid 가 주는 이점에 대해 실험했는데,
  • Section 5.1.2. 은 alternate tier 의 unloaded latency 에 변화를 주었을 때 Colloid 가 어떻게 반응하는지에 대한 실험이고,
  • Section 5.1.3. 은 object size 를 (원래는 64byte 였는데) 바꿨을 때 Colloid 가 어떻게 반응하는지에 대한 실험이다.
  • 그리고 여기 에 application 이 사용하는 core 개수를 변화시켰을 때 ³ 와 read-write ratio 를 변화시켰을 때 ⁴ 의 실험 결과가 있다고 한다.
• 일단 CXL 을 사용하게 되면, DRAM memory 보다 대략 latency 가 2배정도 차이난다고 한다. 그래서 지금까지의 실험에서는 default tier 와 alternate tier 간의 latency 가 1.9 배 차이나도록 하고 있었다고 한다.
• 근데 이 unloaded latency 를 바꾸기 위해, 이 실험에 대해서만 uncore frequency 를 조정해 alternate tier 의 latency 를 1.9 배에서 2.7 배 까지 변화시킬 수 있었다고 한다.
  • 근데 이렇게 uncore frequency 를 건드는 것은 alternate tier 의 bandwidth 를 줄이는 side-effect 도 있다고 한다.
  • 따라서, 제시되는 값들은 “보수적인 수치” 라고 할 수 있다: 실제로는 해당 latency 를 가지는 alternate tier 의 bandwidth 는 이것보다 클 것이기 때문에, memory bandwidth saturation 에 의한 latency 의 증가가 이것보다는 더 적을 것이기 때문이다.
• 그래서 실험 결과는 다음과 같다:

• 일단 HeMem, TPP, MEMTIS 에 대한 실험 결과이고, 가로축은 unloaded latency 의 변화, 그리고 세로축은 memory interconnect contention intensity 의 변화이며 heatmap 의 각 cell 은 각 상황에 대한 throughput 증가 비율이다.
• 한눈에 볼 수 있는 것은 전반적으로 Colloid 를 사용했을 때가 더 좋다는 것이다.
• 구체적으로 두개의 관점에서 변화를 살펴보자.
  • 일단 동일한 unloaded latency 상에서는 (즉, 가로축은 고정하고 세로축의 변화만 보면) intensity 가 심해짐에 따라 Colloid 의 benefit 이 더 증가하는 것을 볼 수 있다 (위로 갈수록 색이 진해지니까).
    • 이것은 Section 5.1.0. 에서 본 것처럼 memory interconnect contention 이 심해질수록 hot page 를 alternate tier 에 두는 것이 더 좋기 때문이다.
  • 그리고 동일한 intensity 상에서는 (즉, 세로축은 고정하고 가로축의 변화만 보면) unloaded latency 가 증가함에 따라 Colloid 의 benefit 이 감소한다 (옆으로 갈수록 색이 옅어지니까).
    • 이것은 alternate tier 의 latency 가 워낙에 크기 때문에 default tier 의 latency 가 점점 증가해도 hot page 를 alternate tier 로 옮기기가 힘들기 때문이다.
    • 즉, alternate tier 의 latency 가 크기 때문에 평균 latency 가 더 높은 수준에서 형성되기 때문인 것.
    • 결과적으로 Colloid 의 “hot page 를 alternate tier 에 배치하는 것에서 오는 이점” 을 살리기 힘들어 이런 낮은 성능 향상을 보여주게 되는 것이다.
    • 그럼에도 불구하고, unloaded latency 가 가장 클 때에도, HeMem 은 $1.01\times$ ~ $1.76\times$ 의 성능 향상을, TPP 는 $1.03\times$ ~ $1.76\times$ 의 성능 향상을, MEMTIS $1.01\times$ ~ $1.63\times$ 의 성능 향상을 보여준다.

5.1.3. Impact of object size. §

• 위 그림은 접근하는 object size 만을 64byte 에서 4096byte 로 단계적으로 바꿨을 때의 그래프이다.
  • 그래프의 각 축과 heatmap 이 의미하는 바는 가로축만 object size 를 64, 256, 1024, 4096 byte 로 바꾼 것이고 나머지는 Section 5.1.2. 와 동일하다.
• 일단 object size 가 256byte 보다 클 때, $0\times$ intensity 에서도 Colloid 를 사용하는 것이 더 성능이 좋은 것을 확인할 수 있다:
  • HeMem 는 $1.17\times$ ~ $1.31\times$,
  • TPP 는 $1.18\times$ ~ $1.35\times$,
  • MEMTIS 는 $1.21\times$ ~ $1.35\times$ 배의 성능 향상이 있었다.
• 이것은 object size 가 커짐에 따라 workload 가 점점 더 memory intensive 해지기 때문이다.
  • 즉, 점점 더 memory intensive 해지기 때문에 $0\times$ 에서도 memory interconnect contention 이 발생하여 Colloid 가 benefit 을 주게 된다는 것 ^{5 6}.
  • 가령 4096byte 의 object size 를 사용하여 HeMem 실험을 하였더니 memory interconnect contention intensity 가 $0\times$ 일 때에도 default tier 의 latency 가 alternate tier 의 latency 에 비해 1.77 배 더 컸다고 한다.
• 다만 intensity 가 클 때 object size 도 증가시키면 Colloid 의 benefit 이 점차 줄어드는 것으로 결과가 나왔다.
  • 이것은 alternate tier 의 BW 도 saturate 되기 때문이다.
  • 즉, default tier 뿐 아니라 alternate tier 의 latency 도 커져서 default tier 에 체류하는 hot page 의 수가 좀 더 많아지고 따라서 Colloid 에서의 “hot page 를 alternate tier 에 배치함으로써 오는 benefit” 이 적어지기 때문이다.
  • 가령 object size 가 64byte 일 때는 alternate tier 의 BW utilization 이 53% 정도였지만, 4096byte 일 때는 BW utilization 이 96% 까지 올라가게 된다고 한다.

5.1.4. Colloid CPU overheads. §

• Colloid 에서는 latency measurement 와 page placement algorithm 때문에 추가적인 CPU cycle 을 필요로 한다.
• Section 5.1.0 에서는 이 CPU overhead 를 확인할 수 있는데, HeMem 와 MEMTIS 는 모두 2% 미만의 overhead 를 보여줬다고 한다.
  • 다만 TPP 에서는 4% ~ 6.5% 의 overhead 를 보여주었고, 이것은 Section 4.3. 에서 말한 것 처럼 latency measurement 을 위해 추가적인 core 를 사용하기 때문이라고 한다.
  • 이것은 그래프에서는 $0\times$ intensity 에서의 TPP 의 throughput 에서 보여진다고 생각된다; 이때 throughput 은 TPP 보다 TPP + Colloid 에서 조금 더 떨어지는데, 이게 위와 같은 이유에서인 것으로 보인다.

5.2. Convergence Time §

5.2.0. Overview §

NXSECTION

• 5.2.0 은 overview 로, 논문에는 이런 section 은 없다.

• Workload 가 바뀌는 것은 tiered memory system 에서 항상 challenge 였다고 한다: 만약에 tiered memory system 이 workload 의 변화에 따라가지 못하면 최적의 성능을 내지 못하기 때문.
• 그래서 Section 5.2. 에서는 이런 workload 변화에 따라 Colloid 가 어떻게 대응하는지 실험한다. 구체적으로는, workload 를 다음의 두 변화로 나누어서 분석한다:
  • Section 5.2.1. 에서는 Section 3.2.2.3. 처럼 workload 의 access pattern 이 바뀌었을 때에 대한 evaluation 이고,
  • Section 5.2.2. 에서는 Section 3.2.2.4. 처럼 memory interconnect contention 이 바뀌었을 때에 대한 evaluation 에 대해 설명한다.

5.2.1. Dynamism due to change in access pattern. §

NXSECTION

• 5.2.1.x 은 편의를 위해 주인장이 임의로 구분지은 section 이다.

5.2.1.1. 0x intensity scenario §

• 일단 위에가 $0\times$ 의 memory interconnect contention 에서 access pattern 을 바꿨을 때의 결과이다.
  • 이전처럼 15개의 core 에 GUPS workload 를 돌리고 steady state 가 될 때까지 기다린 다음,
  • $t=100$ 에서 기존에 hot page 였던 애들을 전부 cold page 로 만들고, 기존에 cold page 였던 애들 중 랜덤하게 골라 hot page 로 만들며 access pattern 을 바꾸었다.
• 그래서 그 결과는 모든 system (HeMem, TPP, MEMTIS) 에서 workload 가 바뀌었을 때 잠깐 throughput 이 떨어졌다가 원래대로 돌아오는 모습을 보인다.
  • 이것은 생각해 보면 당연한 것이다: hot page 가 바뀌어서 hot page 들이 alternate tier 에 있게 되었는데 $0\times$ 에서는 alternate tier 의 latency 가 더 크므로 throughput 이 줄어드는 것.
  • 그리고 이후에 이 hot page 들이 default tier 로 움직이며 원래의 throughput 으로 돌아오는 것이다.
• 또한 Colloid 를 사용했을 때에도 기존의 system 과 동일한 양상을 보여준다.
  • 당연히 $0\times$ 일 때는 Colloid 를 사용하든 말든 모든 hot page 가 default tier 에 들어가기 때문.
• 다만 TPP 의 경우에는 100초 정도로 convergence time 이 더 오래 걸리는 것을 알 수 있다.
  • 이것은 TPP 가 page table scan 을 하며 protection bit 를 키고, 이것에 의한 hint fault 를 이용하기 때문에 page table scan overhead 로 변화를 감지하는데 오래걸리기 때문이다.
  • TPP + Colloid 에서는 이러한 방식을 동일하게 사용하기 때문에 TPP 에서와 마찬가지로 오래걸리게 되는 것.

• 위의 그래프는 HeMem 와 HeMem + Colloid 에서 page migration rate 를 보여준 것이다.
• 일단 당연히 $t=100$ 에서 access pattern 이 바뀌었으므로 이때 page migration 이 진행되며 migration rate 도 커지는 것을 볼 수 있다.
• 이때 HeMem 와 HeMem + Colloid 의 차이점은 크게 두 가지로 볼 수 있다:

1. 우선 HeMem 보다 HeMem + Colloid 일 때 최대 migration rate 은 더 작고 convergence time 은 조금 더 오래 걸리는 것을 볼 수 있다.
   • 이것은 Colloid 의 Dynamic migration limit 때문이다.
   • Colloid 에서는 migration overhead 를 줄이기 위해 $min(\Delta p(R_D+R_A),M)$ 으로 migration limit 을 정하기 때문에, 최대 migration rate 은 $M$ 을 넘지 못해 HeMem 에 비해 최대 migration rate 이 좀 더 작게 나오게 된다.
   • 또한, convergence 에 가까워지게 되면 $\Delta p(R_D+R_A)$ 으로 migration limit 이 정해져 조금 더 천천히 converge 하게 된다.
     • 따라서 이렇게 천천히 converge 하는 것은 hot page 의 크기와는 무관하게 된다: 만약에 hot page 의 크기가 커서 migration 할 것이 많다고 하더라도, $\Delta p(R_D+R_A)$ 에 의한 gradual convergence 는 convergence point 에 가까워져야만 활성화 되기 때문.
2. 그리고 HeMem 보다 HeMem + Colloid 일 때 steady state 일 때의 migration rate 이 살짝 더 높은 것을 알 수 있다.
   • 이것은 Colloid 에서 steady state 일 때에도 balance 를 맞추기 위해 조금씩 page migration 을 하기 때문인 것으로 보인다.
   • 하지만 이것이 application performance 에 미치는 영향은 아주 작다: 이 steady state 일 때의 page migration rate 이 application throughput 에 미치는 영향은 0.7% 미만으로 아주 작다고 한다.

5.2.1.2. 3x intensity scenario §

• 위 그래프는 Section 5.2.1.1. 와 동일한 실험이지만, $3\times$ 의 memory interconnect 일 때의 실험 결과이다.
• 보면 일단 전반적으로 Colloid 를 사용했을 때가 더 throughput 이 좋게 나온다; 앞서 계속 말한 대로 이 때는 hot page 를 alternate tier 에 배치하는 것이 더 좋기 때문.
• $t=100$ 에 access pattern 이 바뀌었을 때, Colloid 를 사용했을 때와 사용하지 않았을 때 각기 다른 양상을 보인다:
  • 일단 Colloid 를 사용했을 때는 일시적으로 throughput 이 감소하게 되는데, 이것은 access pattern 이 바뀌어 hot page 의 일부가 default tier 에 있기 때문이다.
    • 따라서 이놈들을 다시 alternate tier 로 옮기며 throughput 이 원상복귀된다.
  • 반면 Colloid 를 사용하지 않았을 때는 일시적으로 throughput 이 증가하게 되는데, 이것은 access pattern 이 바뀌어 hot page 의 일부가 alternate tier 에 있기 때문이다.
    • 즉, 일시적으로 Colloid 를 사용했을 때와 유사해지며 throughput 이 증가하게 된다.
    • 근데 다시 이놈들을 default tier 로 옮기며 throughput 이 감소하게 된다.
• 위와 같은 양상은 HeMem (+ Colloid) 와 TPP (+ Colloid) 에서 모두 보여주고, TPP 에서만 조금 더 convergence 에 오래걸리는 것을 확인할 수 있다.
  • TPP 에서 좀 더 오래걸리는 것은 Section 5.2.1.1. 에서 말한 대로 TPP 에서의 page table scan overhead 때문이다.
• 다만, MEMTIS + Colloid 에서는 throughput 이 감소하지 않는 것을 알 수 있다.
  • 이것은 MEMTIS 에서는 default tier 에 공간이 많이 있어도 cold page 들을 alternate tier 로 적극적으로 옮기기 때문에, access pattern 이 바뀌었을 때 이미 바뀐 hot page 들이 alternate tier 로 옮겨져 있었기 때문이다.

5.2.2. Dynamism due to change in memory interconnect contention. §

• 위 그래프는 이번에는 access pattern 은 그대로 두고, memory interconnect contention 을 $0\times$ 에서 $3\times$ 로 바꿨을 때의 실험 결과이다.
• HeMem, TPP, MEMTIS 모두 바꾸기 전에는 Colloid 를 사용하던 말던 비슷한 throughput 을 보여준다.
• Colloid 를 사용하지 않았을 때는 intensity 가 변한 이후 throughput 이 크게 떨어지고 그대로 유지되는 것을 볼 수 있다.
  • 이것은 HeMem, TPP, MEMTIS 모두 이러한 변화에 대응하는 logic 이 없기 때문이다.
• 하지만 Colloid 를 사용했을 때는 intensity 가 변한 이후 throughput 이 떨어졌다가, 바뀐 intensity 에 대한 optimal throughput 으로 찾아가는 것을 볼 수 있다.
  • Intensity 가 바뀐 이후에의 throughput 은 Section 5.1.0. 에서의 best case 의 $3\times$ throughput 과 일치한다고 한다.
• 그리고 이 때의 convergence time 은 Section 5.2.1.1. 에서와 유사하다: HeMem + Colloid 이 10초, MEMTIS + Colloid 이 25 초 정도로 빠른 convergence time 을 보여줬고, 비효율적인 detection 을 보여주는 TPP + Colloid 는 100 정도로 느린 convergence time 을 보여줬다.

• 그리고 이것은 migration rate 에서도 나타난다: HeMem 의 경우에는 migration 을 하지 않기 때문에 migration rate 에 변화가 없고, HeMem + Colloid 의 경우에는 optimal 을 찾아가며 migration rate 가 일시적으로 높아지는 것을 볼 수 있다.

5.3. Real Applications §

5.3.0. Overview §

NXSECTION

• 5.3.0 은 overview 로, 논문에는 이런 section 은 없다.

• 여기서는 다양한 access pattern 을 보여주는 real world application 세개에 대한 evaluation 을 보여준다.
• 그리고 이놈들에 대해 15개의 core 에 실행시키고, 나머지 core 에서 memory interconnect contention 을 변화시켜서 발생시켜가며 실험했다고 한다.

5.3.1. Graph processing (GAPBS). §

• 이놈은 여러 in-memory graph 에 대한 processing algorithm 을 구현한 application 이다.
• 실험 환경은:
  • 사용한 algorithm 은 google 의 PageRank 이고, 사용한 graph 는 Twitter graph 라고 한다.
  • 여기에서 graph node 의 skewness 에 의해 hot page 가 결정된다고 한다 ⁷.
  • Default tier 의 크기는 전체 working set 의 $1/3$ 크기인 12.5GB 정도라고 한다.
  • 그리고 16번을 실행해서 실행시간 평균을 내었다고 한다.
• 그리고 이때의 결과는 다음과 같다.

• 가로축은 memory interconnect contention intensity 를 나타내고, 세로축은 이때의 정규화된 성능 향상 정도이다.
• 예상하다시피, intensity 가 높아질 수록 성능 향상 정도가 좋았다:
  • HeMem + Colloid 는 $1.05\times$ ~ $1.92\times$,
  • TPP + Colloid 는 $1.05\times$ ~ $1.48\times$,
  • MEMTIS + Colloid 는 $1.12\times$ ~ $2.12\times$ 의 성능 향상이 있었다.
• 이때 TPP 의 성능 향상 정도가 낮은 이유는 앞에서 계속 말한 것처럼 page table scan overhead 때문이다.

5.3.2. In-memory transaction processing (Silo). §

• 여기에서는 in-memory transaction processing KV store 인 Silo 를 YCSB-C 로 돌린 결과이다. 실험 환경은:
  • 64byte key 와 100byte value pair
  • 4억 (400 million) 개의 KV: 총 크기는 대략 60GB
  • Default tier 의 크기는 전체 크기의 $1/3$ (대략 20GB)
  • 1500만 (15 million) 번의 zipfian distribution lookup
• 이때의 실험 결과는 다음과 같다:

• 그래프는 마찬가지로 가로축은 intensity, 세로축은 정규화된 성능향상 정도이다.
• 결과는 성능 향상이 있긴 했지만, 그닥 많이 좋아지지는 않았다:
  • HeMem + Colloid 는 $1.13\times$ ~ $1.25\times$,
  • TPP + Colloid 는 $1.09\times$ ~ $1.17\times$,
  • MEMTIS + Colloid 는 $1.08\times$ ~ $1.17\times$ 의 성능 향상이 있었다.

5.3.3. In-memory key-value cache (Cachelib). §

• 마지막으로는 facebook 의 in-memory KV cache 인 Cachlib 에 대한 evaluation 이다.
• 실험 환경은:
  • Benchmark tool: CacheBench, workload: HeMemKV
  • Key: 64byte, value: 4byte
  • 20% 의 KV pair 가 hot, 나머지는 cold
  • Hot KV 는 90% 의 확률로 접근, cold KV 는 10% 의 확률로 접근
  • GET-UPDATE 비율은 9:1
  • 1500만 (15 million) KV 쌍을 준비: 대략 75GB
  • Default tier 는 working set (75GB) 의 $1/3$: 대략 25GB
  • 100만 (1 million) operation 실행
  • Metric 은 throughput (측정 시간동안 수행한 operation 수)
• 일때 실험 결과는 다음과 같다:

• 그래프는 마찬가지로 가로축은 intensity, 세로축은 정규화된 성능향상 정도이다.
• 실험 결과는 intensity 가 높아짐에 따라 성능이 잘 나왔다:
  • HeMem + Colloid 는 $1.37\times$ ~ $1.74\times$,
  • TPP + Colloid 는 $1.42\times$ ~ $1.79\times$,
  • MEMTIS + Colloid 는 $1.48\times$ ~ $1.93\times$ 의 성능 향상이 있었다.

Footnotes §

1. 확인해 보자. ↩

2. 이것도 확인해 보자. ↩

3. 이것도 ↩

4. 그리고 이것도 ↩

5. 이부분에 대해 본문에서는 access pattern 이 점점 더 sequential 으로 바뀌고, 따라서 HW prefetcher 가 더 효율적으로 작동하기 떄문이라고 한다. 그러나 이러한 변화는 Colloid 뿐 아니라 HeMem 이나 TPP 에 대해서도 동일하게 적용되는 것이라 성능 향상의 이유를 설명하기에는 어려워 보인다. ↩

6. 추가적으로 이런 설명도 덧붙인다: CHA 와 L3 의 cache miss 의 비율이 per-core parallelism 의 척도가 되고, 이것은 object size 가 커짐에 따라 증가하기 때문에 object size 가 커짐에 따라 효율적이라는 것이다. 근데 cache miss 가 증가하는 것이 왜 효율적임을 방증하는 것인지 이해는 안된다. ↩

7. 이게 뭔소린지는 PR 을 잘 몰라서 모른다. ↩