SanzSkuy: Created page with "'''#pragma omp parallel for''' adalah konstruksi OpenMP yang paling sering dipakai: satu baris pragma yang membagi iterasi loop ke banyak thread. Artikel ini membahas cara kerjanya, aturan data sharing, dan yang paling sering disepelekan padahal menentukan performa: '''kebijakan scheduling''' — siapa mengerjakan iterasi yang mana. Prasyarat: OpenMP: Setup & Hello World. Semua contoh di sini di-compile dengan:

 g++ -O2 -fopenmp -o program program..."

2026-07-11T06:10:44Z

Created page with "'''<code>#pragma omp parallel for</code>''' adalah konstruksi OpenMP yang paling sering dipakai: satu baris pragma yang membagi iterasi loop ke banyak thread. Artikel ini membahas cara kerjanya, aturan data sharing, dan yang paling sering disepelekan padahal menentukan performa: '''kebijakan scheduling''' — siapa mengerjakan iterasi yang mana. Prasyarat: OpenMP: Setup & Hello World. Semua contoh di sini di-compile dengan: <pre> g++ -O2 -fopenmp -o program program..."

New page

'''<code>#pragma omp parallel for</code>''' adalah konstruksi OpenMP yang paling sering dipakai: satu baris pragma yang membagi iterasi loop ke banyak thread. Artikel ini membahas cara kerjanya, aturan data sharing, dan yang paling sering disepelekan padahal menentukan performa: '''kebijakan scheduling''' — siapa mengerjakan iterasi yang mana.

Prasyarat: [[OpenMP: Setup & Hello World]]. Semua contoh di sini di-compile dengan:

<pre>
g++ -O2 -fopenmp -o program program.cpp
OMP_NUM_THREADS=8 ./program
</pre>

= Dasar: parallel for =

Contoh paling sederhana, SAXPY (y = a·x + y):

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

int main() {
const int N = 10'000'000;
std::vector<double> x(N, 1.0), y(N, 2.0);
const double a = 3.0;

#pragma omp parallel for
for (int i = 0; i < N; ++i)
y[i] = a * x[i] + y[i]; // tiap iterasi independen — syarat mutlak

printf("y[0] = %.1f, y[N-1] = %.1f\n", y[0], y[N-1]);
return 0;
}
</syntaxhighlight>

Yang terjadi di balik pragma itu:
# Runtime membentuk '''team of threads''' (fork), biasanya sebanyak core / nilai <code>OMP_NUM_THREADS</code>.
# Ruang iterasi <code>0..N-1</code> '''dibagi''' ke thread-thread sesuai kebijakan schedule.
# Di akhir loop ada '''implicit barrier''': semua thread saling tunggu, baru program lanjut (join).

Dalam bahasa [[Work-Span Model & Brent's Theorem|work-span]]: badan loop yang independen berarti span-nya Θ(1) — parallelism Θ(N), ini kasus terbaik ("embarrassingly parallel").

== parallel vs for: dua konstruksi berbeda ==

<code>parallel for</code> sebenarnya gabungan dua hal: <code>parallel</code> (bikin team) dan <code>for</code> (bagi iterasi ke team yang sudah ada). Memisahkannya berguna kalau ada beberapa loop berurutan — team dibuat sekali saja, tidak fork-join berulang:

<syntaxhighlight lang="cpp">
#pragma omp parallel // fork sekali
{
#pragma omp for nowait // loop 1; nowait = hapus barrier di akhirnya
for (int i = 0; i < N; ++i)
a[i] = f(i);

#pragma omp for // loop 2; barrier di sini tetap ada
for (int i = 0; i < M; ++i)
b[i] = g(i);
} // join sekali
</syntaxhighlight>

<code>nowait</code> hanya aman kalau loop berikutnya '''tidak membaca''' hasil loop sebelumnya dari iterasi milik thread lain. Kalau ragu, biarkan barrier-nya.

= Syarat Loop: Canonical Form =

Tidak semua loop bisa ditempeli <code>parallel for</code>. OpenMP menuntut '''canonical loop form''': jumlah iterasi harus bisa dihitung ''sebelum'' loop jalan.

* Variabel loop bertipe integer (atau random-access iterator C++).
* Kondisi berbentuk <code>i < n</code>, <code>i <= n</code>, dsb. — batas tidak berubah selama loop.
* Increment tetap: <code>++i</code>, <code>i += k</code>.
* Tidak ada <code>break</code> atau <code>return</code> keluar dari loop (<code>continue</code> boleh).
* <code>while</code> dan loop linked-list tidak bisa — untuk itu pakai [[OpenMP: Tasking]].

Dan satu syarat semantik yang jadi tanggung jawab kita, bukan compiler: '''tidak ada loop-carried dependency''' — iterasi i tidak boleh butuh hasil iterasi lain. Compiler tidak memeriksa ini; pragma adalah janji kita ke compiler. Janji palsu = hasil salah tanpa peringatan.

<syntaxhighlight lang="cpp">
// TIDAK BISA diparalelkan begitu saja: iterasi i butuh hasil iterasi i-1
for (int i = 1; i < N; ++i)
prefix[i] = prefix[i-1] + x[i]; // DAG-nya rantai lurus, span Θ(N)
</syntaxhighlight>

(Kasus prefix sum ini punya solusi khusus — lihat [[Parallel Prefix Sum (Scan)]].)

= Data Sharing: shared, private, firstprivate, lastprivate =

Aturan default: variabel yang dideklarasikan '''di luar''' region paralel = <code>shared</code> (satu untuk semua thread), yang '''di dalam''' = private per thread. Variabel loop-nya sendiri otomatis private.

Klausa untuk mengatur eksplisit:

{| class="wikitable"
! Klausa !! Arti
|-
| <code>shared(v)</code> || Satu <code>v</code> untuk semua thread. Aman dibaca bersama; menulis bersama = race.
|-
| <code>private(v)</code> || Tiap thread dapat salinan <code>v</code> sendiri, '''tidak diinisialisasi'''.
|-
| <code>firstprivate(v)</code> || Seperti private, tapi salinannya diinisialisasi dari nilai <code>v</code> sebelum loop.
|-
| <code>lastprivate(v)</code> || Seperti private, tapi nilai dari '''iterasi terakhir''' disalin balik keluar loop.
|-
| <code>default(none)</code> || Wajib deklarasi eksplisit semua variabel. '''Selalu pakai ini''' — memaksa mikir, menangkap race saat compile.
|}

Contoh dengan <code>default(none)</code>:

<syntaxhighlight lang="cpp">
double skala = 2.5;
std::vector<double> v(N);

#pragma omp parallel for default(none) shared(v) firstprivate(skala)
for (int i = 0; i < (int)v.size(); ++i) // hati-hati: size() perlu di-cast/di-hoist
v[i] = skala * i;
</syntaxhighlight>

Lupa satu variabel saja dengan <code>default(none)</code> → error compile. Jauh lebih murah daripada race yang muncul sekali tiap seribu run.

= Race Condition: Bug Nomor Satu =

Program lengkap yang menunjukkan kenapa menulis ke variabel <code>shared</code> itu fatal:

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

int main() {
const int N = 1000000;
long salah = 0, benar = 0;

#pragma omp parallel for
for (int i = 0; i < N; ++i)
salah += 1; // RACE: semua thread menulis variabel yang sama

#pragma omp parallel for reduction(+:benar)
for (int i = 0; i < N; ++i)
benar += 1; // tiap thread punya salinan, digabung di akhir

printf("salah = %ld (harusnya %d)\n", salah, N);
printf("benar = %ld\n", benar);
return 0;
}
</syntaxhighlight>

Output nyata (16 thread):

<pre>
salah = 937500 (harusnya 1000000)
benar = 1000000
</pre>

<code>salah += 1</code> itu tiga operasi (baca–tambah–tulis); dua thread yang interleave saling menimpa hasil. Perbaikannya '''bukan''' <code>critical</code> atau <code>atomic</code> di dalam loop (itu menserialisasi lagi, kadang lebih lambat dari sekuensial) tapi klausa <code>reduction</code>. Detail di [[OpenMP: Reduction & Sinkronisasi]].

= Scheduling: Siapa Mengerjakan Iterasi yang Mana =

Sintaks: <code>schedule(jenis[, chunk])</code>. Ilustrasi 16 iterasi, 4 thread:

<pre>
static T0:[ 0 1 2 3] T1:[ 4 5 6 7] T2:[ 8 9 10 11] T3:[12 13 14 15]
blok kontigu sama besar, ditentukan di awal

static,2 T0:[0 1][8 9] T1:[2 3][10 11] T2:[4 5][12 13] T3:[6 7][14 15]
chunk 2 iterasi, dibagi round-robin, tetap ditentukan di awal

dynamic,2 T0:[0 1][6 7]... T1:[2 3][10 11].. <- siapa cepat dia dapat
thread yang selesai ambil chunk berikutnya dari antrean

guided [0..5][6..9][10..12][13 14][15] <- chunk mengecil
mulai besar (sisa/p), makin lama makin kecil, diambil dinamis
</pre>

; <code>schedule(static)</code> — default di kebanyakan implementasi
: Pembagian ditentukan sebelum loop jalan, '''overhead nol''', deterministik. Bonus besar: kalau loop yang sama dijalankan berulang (misal tiap timestep), thread yang sama pegang elemen yang sama → data masih hangat di cache-nya, dan cocok dengan pola first-touch di sistem [[NUMA]] (lihat [[OpenMP: Affinity & First-Touch]]).

; <code>schedule(static, chunk)</code>
: Sama-sama ditentukan di awal, tapi interleaved. Berguna kalau beban naik/turun secara ''teratur'' sepanjang ruang iterasi.

; <code>schedule(dynamic, chunk)</code>
: Thread ambil chunk dari antrean bersama tiap kali selesai. Menyeimbangkan beban timpang, tapi tiap pengambilan ada overhead sinkronisasi. <code>dynamic,1</code> (chunk default) = load balancing terbaik, overhead terburuk; chunk besar = sebaliknya. Lokalitas cache juga hancur karena pembagian berubah tiap run.

; <code>schedule(guided, chunk)</code>
: Seperti dynamic tapi chunk mengecil eksponensial (mulai ≈ sisa_iterasi/jumlah_thread, minimum <code>chunk</code>). Kompromi: sedikit pengambilan di awal, granularitas halus di akhir buat menambal ketimpangan.

; <code>schedule(auto)</code>
: Terserah compiler/runtime.

; <code>schedule(runtime)</code>
: Baca dari environment variable <code>OMP_SCHEDULE</code> (misal <code>OMP_SCHEDULE="dynamic,64"</code>) atau <code>omp_set_schedule()</code>. Emas buat eksperimen: ganti kebijakan tanpa recompile.

= Benchmark: Membandingkan Semua Schedule =

Program lengkap. Bebannya sengaja timpang — iterasi ke-i mengerjakan i putaran, jadi iterasi akhir jauh lebih berat (beban segitiga). Trik <code>schedule(runtime)</code> + <code>omp_set_schedule()</code> dipakai supaya satu binary bisa menguji semua kebijakan:

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

// Kerja per iterasi sengaja dibuat timpang:
// iterasi ke-i mengerjakan i putaran, jadi iterasi akhir jauh
// lebih berat dari iterasi awal (beban berbentuk segitiga).
double kerja(long i) {
double s = 0.0;
for (long j = 0; j < i; ++j)
s += std::sin(j * 1e-9);
return s;
}

void jalankan(omp_sched_t jenis, int chunk, const char *nama, long n) {
omp_set_schedule(jenis, chunk);
double total = 0.0;

double t0 = omp_get_wtime();
#pragma omp parallel for schedule(runtime) reduction(+:total)
for (long i = 0; i < n; ++i)
total += kerja(i);
double t1 = omp_get_wtime();

printf("%-16s : %6.3f s (checksum %.4f)\n", nama, t1 - t0, total);
}

int main() {
const long N = 30000;
printf("threads = %d, N = %ld\n\n", omp_get_max_threads(), N);

jalankan(omp_sched_static, 0, "static", N);
jalankan(omp_sched_static, 100, "static,100", N);
jalankan(omp_sched_dynamic, 1, "dynamic,1", N);
jalankan(omp_sched_dynamic, 100, "dynamic,100", N);
jalankan(omp_sched_guided, 0, "guided", N);
return 0;
}
</syntaxhighlight>

Hasil nyata di mesin 16 thread (angka pasti beda-beda tiap mesin, polanya yang penting):

<pre>
threads = 16, N = 30000

static : 0.259 s (checksum 4499.5500)
static,100 : 0.191 s (checksum 4499.5500)
dynamic,1 : 0.183 s (checksum 4499.5500)
dynamic,100 : 0.192 s (checksum 4499.5500)
guided : 0.181 s (checksum 4499.5500)
</pre>

Analisisnya:
* <code>static</code> paling lambat (~40% di belakang): thread terakhir kebagian blok iterasi terberat, thread lain selesai duluan lalu '''nganggur menunggu barrier'''. Waktu loop = waktu thread paling sial.
* <code>static,100</code> sudah hampir menyelesaikan masalah: interleaving meratakan beban segitiga, tanpa overhead dinamis.
* <code>dynamic,1</code> menang di sini karena badan iterasinya besar (ribuan sin), jadi overhead ambil-chunk tenggelam. Kalau badan loop-nya cuma beberapa instruksi, <code>dynamic,1</code> justru bisa lebih lambat dari sekuensial.
* Checksum harus identik di semua kebijakan — schedule mengubah ''pembagian kerja'', bukan hasil. Kalau checksum berubah-ubah, ada race.

= Panduan Memilih =

{| class="wikitable"
! Situasi !! Pakai
|-
| Beban tiap iterasi seragam (SAXPY, stencil, matmul) || <code>static</code> — overhead nol, cache & NUMA friendly
|-
| Beban bervariasi tapi polanya teratur (segitiga, dsb.) || <code>static,chunk</code>
|-
| Beban tak tertebak, badan iterasi besar (Mandelbrot, ray tracing, simulasi partikel) || <code>dynamic,chunk</code> — mulai dari chunk sedang (32–128), tuning
|-
| Beban tak tertebak, mau kompromi tanpa tuning || <code>guided</code>
|-
| Belum tahu / mau eksperimen || <code>runtime</code> + <code>OMP_SCHEDULE</code>
|}

Prinsipnya trade-off tiga arah: '''load balance''' vs '''overhead scheduling''' vs '''lokalitas cache'''. <code>static</code> mengorbankan yang pertama demi dua sisanya; <code>dynamic,1</code> kebalikannya; sisanya ada di tengah.

= collapse: Loop Bersarang =

Kalau loop luar iterasinya sedikit (misal N=8 baris di mesin 16 thread), separuh thread nganggur. <code>collapse(2)</code> menggabungkan dua ruang iterasi jadi satu:

<syntaxhighlight lang="cpp">
// tanpa collapse: hanya N iterasi dibagi ke thread → N=8, 16 thread = rugi
// dengan collapse(2): N*M iterasi dibagi ke thread
#pragma omp parallel for collapse(2)
for (int i = 0; i < N; ++i)
for (int j = 0; j < M; ++j)
c[i][j] = a[i][j] + b[i][j];
</syntaxhighlight>

Syarat: kedua loop harus ''perfectly nested'' (tidak ada statement di antara <code>for i</code> dan <code>for j</code>) dan batas loop dalam tidak boleh bergantung pada loop luar. Kalau loop luar sudah punya iterasi jauh lebih banyak dari jumlah thread, <code>collapse</code> tidak perlu — malah bisa merusak lokalitas akses baris.

= Jebakan Umum =

* '''Pragma adalah janji.''' Compiler percaya begitu saja bahwa iterasi independen. Loop-carried dependency tidak terdeteksi — hasil salah, tanpa error, kadang cuma sesekali.
* '''Loop terlalu kecil.''' Fork-join dan barrier itu ada harganya (orde mikrodetik). Loop 1000 iterasi ringan bisa lebih lambat diparalelkan. Ukur dulu, paralelkan loop yang memang makan waktu. Bisa juga pakai klausa <code>if(N > 10000)</code> supaya paralel hanya untuk masalah besar.
* '''Menulis elemen bertetangga dari thread berbeda.''' Benar secara logika, lambat secara hardware — dua thread menulis ke cache line yang sama saling melempar line-nya bolak-balik. Lihat [[OpenMP: False Sharing]] dan [[Cache line]].
* '''Memanggil fungsi yang tidak thread-safe''' di dalam loop (<code>rand()</code>, <code>strtok()</code>, ...). Pakai versi reentrant atau state per thread.
* '''<code>std::vector::push_back</code> di dalam parallel for.''' Mengubah struktur container dari banyak thread = race. Pre-allocate lalu tulis via indeks.
* '''Nested parallelism tak sengaja''' — <code>parallel for</code> di dalam fungsi yang dipanggil dari <code>parallel for</code> lain. Default-nya region dalam jalan serial (aman), tapi kalau <code>OMP_NESTED=true</code> bisa terjadi ledakan thread.

= Ringkasan =

* <code>parallel for</code> = fork team + bagi iterasi + implicit barrier. Syaratnya: canonical form dan iterasi benar-benar independen.
* Selalu <code>default(none)</code>; akumulasi pakai <code>reduction</code>, bukan menulis ke <code>shared</code>.
* Schedule = trade-off load balance vs overhead vs lokalitas: <code>static</code> untuk beban rata, <code>dynamic/guided</code> untuk beban timpang, <code>runtime</code> untuk eksperimen.
* Waktu loop paralel = waktu thread paling lambat; barrier membuat semua orang menunggu si paling sial.

= Lihat Juga =

* [[OpenMP: Setup & Hello World]] — prasyarat
* [[OpenMP: Reduction & Sinkronisasi]] — kelanjutan langsung dari klausa <code>reduction</code>
* [[OpenMP: Tasking]] — untuk kerja yang tidak berbentuk loop canonical
* [[OpenMP: False Sharing]] — kenapa hasil benar tapi lambat
* [[OpenMP: Affinity & First-Touch]] — interaksi schedule dengan [[NUMA]]
* [[Work-Span Model & Brent's Theorem]] — teori di balik "iterasi independen = parallelism maksimal"
* [[Parallel Prefix Sum (Scan)]] — cara menangani loop yang punya dependency

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

OpenMP: Parallel For & Scheduling - Revision history