SanzSkuy: Created page with "Di mesin NUMA, performa program OpenMP ditentukan dua hal yang '''tidak kelihatan di kode''': di core mana tiap thread berjalan ('''affinity'''), dan di node memori mana tiap data tinggal ('''first-touch'''). Kode yang sama persis bisa beda kecepatan 2× hanya karena dua hal ini tidak selaras. Artikel ini membahas cara mengontrol keduanya — dan kenapa keduanya harus diatur ''bersama-sama''. Prasyarat: OpenMP: Parallel For & Scheduling dan konsep NUMA. = L..."

2026-07-11T06:18:17Z

Created page with "Di mesin NUMA, performa program OpenMP ditentukan dua hal yang '''tidak kelihatan di kode''': di core mana tiap thread berjalan ('''affinity'''), dan di node memori mana tiap data tinggal ('''first-touch'''). Kode yang sama persis bisa beda kecepatan 2× hanya karena dua hal ini tidak selaras. Artikel ini membahas cara mengontrol keduanya — dan kenapa keduanya harus diatur ''bersama-sama''. Prasyarat: OpenMP: Parallel For & Scheduling dan konsep NUMA. = L..."

New page

Di mesin [[NUMA]], performa program OpenMP ditentukan dua hal yang '''tidak kelihatan di kode''': di core mana tiap thread berjalan ('''affinity'''), dan di node memori mana tiap data tinggal ('''first-touch'''). Kode yang sama persis bisa beda kecepatan 2× hanya karena dua hal ini tidak selaras. Artikel ini membahas cara mengontrol keduanya — dan kenapa keduanya harus diatur ''bersama-sama''.

Prasyarat: [[OpenMP: Parallel For & Scheduling]] dan konsep [[NUMA]].

= Latar: NUMA dalam Satu Paragraf =

Node cluster modern umumnya punya ≥2 socket CPU, dan tiap socket punya memory controller + RAM sendiri. Semua RAM tergabung dalam satu address space, tapi aksesnya tidak seragam: core di socket 0 mengakses RAM socket 0 ('''lokal''') lebih cepat daripada RAM socket 1 ('''remote''', lewat interconnect antar-socket seperti Intel UPI / AMD Infinity Fabric). Bedanya tipikal 1.5–2× di latensi, dan bandwidth interconnect jauh lebih kecil dari bandwidth memori lokal. Pertanyaannya: siapa yang menentukan sebuah data tinggal di RAM socket mana?

= First-Touch: Memori Dialokasikan Saat Disentuh =

Jawabannya kebijakan default Linux: '''first-touch'''. <code>malloc</code>/<code>new</code> hanya memberi alamat ''virtual'' — belum ada halaman (page) fisik sama sekali. Halaman fisik baru dialokasikan saat pertama kali '''ditulis''', dan ditempatkan di node memori tempat '''thread yang menulisnya''' sedang berjalan.

Konsekuensinya brutal untuk pola kode yang paling umum:

<syntaxhighlight lang="cpp">
double *a = new double[N];

for (long i = 0; i < N; ++i) // init serial oleh thread master...
a[i] = 0.0; // ...SEMUA halaman jatuh di node 0

#pragma omp parallel for
for (long i = 0; i < N; ++i) // 16 thread di 2 socket mengeroyok...
a[i] = berat(a[i]); // ...RAM node 0. Interconnect macet.
</syntaxhighlight>

<pre>
INIT SERIAL: INIT PARALEL:
Socket 0 Socket 1 Socket 0 Socket 1
[RAM: a semua] [RAM: kosong] [RAM: a paruh 1] [RAM: a paruh 2]
^ ^ | | ^ ^ ^ ^
T0 T1 ......... T8 T9 T0 T1 T8 T9
semua lewat sini lokal lokal
(interconnect = leher botol)
</pre>

Perbaikannya satu baris: inisialisasi dengan loop paralel yang '''pembagiannya sama''' dengan loop komputasi:

<syntaxhighlight lang="cpp">
#pragma omp parallel for schedule(static)
for (long i = 0; i < N; ++i) // thread yang menyentuh duluan =
a[i] = 0.0; // thread yang memakai nanti -> semua akses lokal
</syntaxhighlight>

Kuncinya <code>schedule(static)</code> di '''kedua''' loop: pembagiannya deterministik, jadi thread t menyentuh dan memakai elemen yang sama. <code>dynamic</code>/<code>guided</code> merusak jaminan ini (pembagian berubah tiap run) — di mesin NUMA, beban timpang pun sering lebih murah ditangani dengan <code>static,chunk</code> daripada kehilangan lokalitas.

= Benchmark: Membuktikannya =

Triad ala [[Benchmark: STREAM|STREAM]] (a = b + s·c), bandingkan init serial vs paralel:

<syntaxhighlight lang="cpp">
#include <cstdio>
#include <cstring>
#include <omp.h>

// Bandingkan: ./firsttouch serial vs ./firsttouch paralel
int main(int argc, char **argv) {
const long N = 1L << 26; // 3 array x 512 MiB = 1.5 GiB
const bool paralel = (argc > 1 && strcmp(argv[1], "paralel") == 0);

double *a = new double[N]; // alokasi virtual: belum ada halaman fisik
double *b = new double[N];
double *c = new double[N];

if (paralel) {
// first-touch oleh thread yang sama yang nanti memakainya
#pragma omp parallel for schedule(static)
for (long i = 0; i < N; ++i) { a[i] = 0.0; b[i] = 1.0; c[i] = 2.0; }
} else {
// first-touch semuanya oleh thread master -> semua halaman di node 0
for (long i = 0; i < N; ++i) { a[i] = 0.0; b[i] = 1.0; c[i] = 2.0; }
}

double best = 1e99;
for (int ulang = 0; ulang < 5; ++ulang) {
double t0 = omp_get_wtime();
#pragma omp parallel for schedule(static)
for (long i = 0; i < N; ++i)
a[i] = b[i] + 3.0 * c[i];
double t1 = omp_get_wtime();
if (t1 - t0 < best) best = t1 - t0;
}

// triad: baca b, baca c, tulis a = 24 byte per iterasi
printf("init %-7s : %.4f s per triad, %5.1f GB/s\n",
paralel ? "paralel" : "serial", best, 24.0 * N / best / 1e9);

delete[] a; delete[] b; delete[] c;
return 0;
}
</syntaxhighlight>

Hasil nyata di laptop (i5-13450HX, '''1 socket, 1 NUMA node''', 16 thread):

<pre>
init serial : 0.0634 s per triad, 25.4 GB/s
init paralel : 0.0644 s per triad, 25.0 GB/s
</pre>

'''Tidak ada bedanya — dan itu memang seharusnya.''' Satu node NUMA berarti semua memori sama jauhnya; first-touch tidak mengubah apa-apa. Ini pelajaran penting: first-touch adalah masalah ''mesin multi-socket''. Di node cluster 2-socket, benchmark yang sama tipikalnya menunjukkan init serial kehilangan hampir '''setengah bandwidth''' (semua thread mengantre ke satu memory controller + interconnect), sedangkan init paralel mendekati jumlah bandwidth kedua socket. Jalankan program di atas saat pertama kali dapat akses cluster — angkanya jauh lebih meyakinkan daripada artikel ini.

== Jebakan C++: std::vector ==

<syntaxhighlight lang="cpp">
std::vector<double> v(N); // konstruktor MENG-NOL-KAN semua elemen...
// ...secara serial, di thread master.
// First-touch sudah terlanjur terjadi!
</syntaxhighlight>

<code>std::vector<double> v(N)</code> melakukan value-initialization — itu sudah "menyentuh" seluruh array dari satu thread. Loop init paralel setelahnya percuma: halaman sudah punya rumah. Untuk array besar di mesin NUMA, pakai <code>new double[N]</code> / <code>std::unique_ptr<double[]></code> (tidak menginisialisasi, tidak menyentuh) lalu sentuh pertama kali lewat loop paralel — atau tulis custom allocator.

= Affinity: Mengikat Thread ke Core =

First-touch mengatur di mana ''data'' tinggal. Percuma kalau ''thread''-nya sendiri berpindah-pindah: default-nya OS scheduler bebas memigrasikan thread antar core, dan begitu thread pindah socket, semua data yang tadinya lokal jadi remote — plus isi cache-nya ditinggal. Affinity = mengikat thread ke tempat tertentu. Dua environment variable utama (OpenMP ≥ 4.0):

; <code>OMP_PLACES</code> — mendefinisikan "tempat" yang tersedia
: <code>threads</code> = satu hardware thread per place; <code>cores</code> = satu core fisik per place (hyperthread sesaudara jadi satu); <code>sockets</code> = satu socket per place. Bisa juga eksplisit: <code>{0:8},{8:8}</code>.

; <code>OMP_PROC_BIND</code> — mengatur cara thread dipetakan ke places
: <code>false</code> = tidak diikat (default GCC — thread bebas migrasi!); <code>true</code> = diikat, pemetaan terserah implementasi; <code>close</code> = rapat: thread berurutan di place bertetangga; <code>spread</code> = disebar merata ke seluruh places; <code>master</code> = semua di place yang sama dengan master. Bisa juga per-region lewat klausa: <code>#pragma omp parallel proc_bind(spread)</code>.

Untuk melihat hasil pemetaannya, tidak perlu menebak — minta runtime melapor dengan <code>OMP_DISPLAY_AFFINITY=true</code>. Demo nyata di laptop 16 CPU (10 core: 6 P-core ber-hyperthread + 4 E-core), 4 thread:

<pre>
$ export OMP_DISPLAY_AFFINITY=true OMP_AFFINITY_FORMAT="thread %n -> core %A"
$ OMP_NUM_THREADS=4 OMP_PLACES=cores OMP_PROC_BIND=close ./program
thread 0 -> core 0-1
thread 1 -> core 2-3 <- rapat: 4 place pertama, semua P-core bertetangga
thread 2 -> core 4-5
thread 3 -> core 6-7

$ OMP_NUM_THREADS=4 OMP_PLACES=cores OMP_PROC_BIND=spread ./program
thread 0 -> core 0-1
thread 1 -> core 6-7 <- disebar ke seluruh chip,
thread 2 -> core 12 sampai kena E-core (12, 14 tanpa hyperthread)
thread 3 -> core 14
</pre>

(Notasi <code>0-1</code> berarti place-nya satu core fisik dengan 2 hyperthread.)

== close atau spread? ==

{| class="wikitable"
! Situasi !! Pakai !! Alasan
|-
| Memory-bound, thread < core, mesin multi-socket || <code>spread</code> || Menyebar thread = memakai memory controller & cache L3 semua socket
|-
| Thread banyak berbagi data / sinkronisasi intensif || <code>close</code> || Tetangga cache = komunikasi murah
|-
| Hybrid MPI+OpenMP, satu rank per socket || <code>close</code> per rank || Rank sudah dipisah per socket; thread-nya jangan nyebrang
|-
| Thread = jumlah core || dua-duanya sama || Semua place terisi; yang penting '''diikat''' (bukan <code>false</code>)
|}

Resep standar yang aman untuk hampir semua kasus:

<pre>
export OMP_PLACES=cores
export OMP_PROC_BIND=spread # atau close; yang penting BUKAN false
export OMP_NUM_THREADS=<jumlah core fisik>
</pre>

<code>OMP_PLACES=cores</code> (bukan <code>threads</code>) berarti satu thread OpenMP per core fisik — untuk kode HPC yang memory/FPU-bound, hyperthreading jarang membantu dan sering mengganggu.

= Menyelaraskan Semuanya =

Tiga komponen harus konsisten satu sama lain — lepas satu, dua lainnya ikut rusak:

# '''Affinity''': thread diikat ke core (<code>OMP_PROC_BIND</code> ≠ false) → pemetaan thread→socket stabil.
# '''First-touch''': array disentuh pertama kali oleh loop paralel → pemetaan data→socket mengikuti thread.
# '''Schedule''': <code>schedule(static)</code> di loop init ''dan semua'' loop komputasi → pemetaan iterasi→thread sama terus, dari init sampai timestep terakhir.

Pola lengkapnya dalam kode simulasi tipikal:

<syntaxhighlight lang="cpp">
double *u = new double[N]; // jangan std::vector untuk grid besar

#pragma omp parallel for schedule(static)
for (long i = 0; i < N; ++i) // "init paralel" — pemanasan first-touch
u[i] = kondisi_awal(i);

for (int step = 0; step < STEPS; ++step) {
#pragma omp parallel for schedule(static) // pembagian SAMA dengan init
for (long i = 0; i < N; ++i)
u_baru[i] = update(u, i);
std::swap(u, u_baru);
}
</syntaxhighlight>

= Alat Diagnosa =

* <code>numactl --hardware</code> — berapa node, core mana milik siapa, RAM bebas per node.
* <code>numastat -p <PID></code> — halaman milik proses ada di node mana; cara paling langsung memergoki first-touch yang salah.
* <code>numactl --interleave=all ./program</code> — paksa halaman disebar round-robin; obat instan (bukan optimal) untuk program orang lain yang init-nya serial.
* <code>OMP_DISPLAY_ENV=true</code> — cetak semua setting OpenMP efektif saat program mulai.
* <code>lstopo</code> (hwloc) — gambar topologi mesin: socket, cache, core.
* <code>likwid-pin</code> / <code>likwid-perfctr</code> — binding + pengukuran per-socket, lihat [[Profiling: likwid]].

Satu catatan sistem: Linux punya '''automatic NUMA balancing''' (<code>/proc/sys/kernel/numa_balancing</code>) yang diam-diam memigrasikan halaman mendekati thread yang mengaksesnya. Ini bisa menutupi dosa first-touch setelah beberapa detik — tapi dengan overhead page-fault, dan tidak bisa diandalkan. Saat benchmark serius, sadari fitur ini ada.

= Jebakan Umum =

* '''Lupa bahwa default-nya tidak diikat.''' Tanpa <code>OMP_PROC_BIND</code>, GCC membiarkan thread migrasi. Semua kerja keras first-touch bisa hangus saat OS memindahkan thread ke socket sebelah.
* '''<code>std::vector(N)</code>, <code>calloc</code>, <code>memset</code> setelah alokasi''' — semuanya menyentuh array secara serial sebelum sempat di-first-touch paralel.
* '''Memory pool / allocator yang mendaur ulang.''' Halaman yang sudah pernah disentuh '''tetap di node lamanya''' — <code>free()</code> lalu <code>malloc()</code> lagi belum tentu memberi halaman perawan. Program panjang yang alokasinya didaur ulang tidak bisa mengandalkan first-touch begitu saja.
* '''Granularitas halaman: 4 KiB = 512 double.''' First-touch bekerja per halaman, bukan per elemen. Array kecil atau pembagian yang tidak sejajar halaman → beberapa halaman di perbatasan jadi "milik bersama". Untuk array raksasa ini noise; jangan pusing.
* '''Menguji di laptop lalu heran tidak ada efeknya''' — seperti hasil benchmark di atas: 1 node NUMA = tidak ada remote access. Fenomena ini baru hidup di mesin multi-socket.
* '''Hybrid MPI+OpenMP''': <code>mpirun</code> sering membatasi cpuset tiap rank. Aturan mainnya: satu rank per socket/NUMA-node, OpenMP mengisi core di dalamnya dengan <code>close</code>. Detail di [[OpenMP: Hybrid MPI+OpenMP]].

= Ringkasan =

* Halaman memori tinggal di node tempat thread yang '''pertama menulisnya''' — bukan yang <code>malloc</code>.
* Init serial = semua data numpuk di node 0 = semua thread socket lain antre di interconnect. Obatnya: '''init paralel''' dengan <code>schedule(static)</code> yang sama dengan loop komputasi.
* Ikat thread-nya: <code>OMP_PLACES=cores</code> + <code>OMP_PROC_BIND=spread/close</code>. Tanpa binding, first-touch cuma janji manis.
* Verifikasi, jangan percaya: <code>OMP_DISPLAY_AFFINITY=true</code> untuk thread, <code>numastat</code> untuk data.
* Efeknya baru terasa di mesin multi-socket — laptop single-node tidak akan menunjukkannya (dibuktikan di atas: 25.4 vs 25.0 GB/s).

= Lihat Juga =

* [[NUMA]] — konsep dasarnya
* [[OpenMP: Parallel For & Scheduling]] — kenapa <code>schedule(static)</code> deterministik itu penting di sini
* [[OpenMP: False Sharing]] — masalah lokalitas di skala cache line, saudara kecil masalah ini
* [[Benchmark: STREAM]] — benchmark bandwidth yang jadi template percobaan di atas
* [[Profiling: likwid]] — likwid-pin & pengukuran bandwidth per socket
* [[OpenMP: Hybrid MPI+OpenMP]] — pembagian socket antara MPI rank dan thread
* [[Cache line]]

[[Kategori:HPC]]
[[Kategori:OpenMP]]

OpenMP: Affinity & First-Touch - Revision history