Menguasai Pemrograman dan Debugging Multicore: Strategi untuk Performa dan Keandalan
Dalam artikel ini kita meninjau evolusi prosesor multicore, prevalensi yang semakin meningkat, dan pertimbangan desain, performa, dan debugging yang menyertainya.
Performa Sistem
Peningkatan performa dalam sistem tertanam dapat dicapai melalui optimasi kompiler yang canggih, arsitektur perangkat keras yang efisien, dan, semakin banyak, eksekusi paralel di seluruh beberapa inti. Sementara algoritma kompiler cerdas dapat mengecilkan kecepatan tambahan dari kode single-threaded, asumsi yang berdiri lama bahwa frekuensi jam akan terus melipat ganda setiap beberapa tahun telah menjadi tidak dapat dipertahankan. Batas performa modern terletak dalam rentang gigahertz angka satu-digit rendah, menjadikan paralelisme jalur yang paling viable untuk menskala.
Parallelisme
Tidak semua tugas sama mudahnya untuk diparalelkan. Satu orang harus membor lubang dalam, jadi menambahkan lebih banyak pekerja ke lubang tersebut tidak mempercepat pekerjaan; justru itu dapat menghambat kemajuan. Sebaliknya, menggali parit sangat paralel: beberapa pekerja dapat menggali berdampingan, masing-masing mencakup fraksi dari total upaya.
Ilustrasi itu menggambarkan MIMD (Multiple Instruction, Multiple Data), di mana setiap pekerja (inti) dapat melakukan operasi yang berbeda. Dengan empat pekerja independen, tugas yang akan mengambil satu inti satu penuh menit dapat selesai dalam sekitar 15 detik.
Sedangkan, SIMD (Single Instruction, Multiple Data) mengeksekusi instruksi yang sama di seluruh banyak elemen data secara bersamaan. SIMD ideal untuk beban kerja dengan operasi teratur dan berulang—seperti pemfilteran citra atau matematika vektor—tetapi kurang fleksibel untuk komputasi umum.
Pertimbangan ini mendasari kemunculan prosesor multicore: dengan menyematkan beberapa subsistem CPU penuh pada satu die, desainer dapat menskala performa secara linier, asalkan perangkat lunak ditulis untuk mengeksploitasi paralelisme.
Berbagai Jenis Pemrosesan Multicore
Prosesor dapat menggabungkan inti dengan berbagai cara, mempengaruhi bagaimana beban kerja didistribusikan dan bagaimana inti berkomunikasi.
Multicore homogen – Dua atau lebih inti identik, masing-masing dengan register, unit fungsional, dan seringkali cache L1 pribadi. Komunikasi inti biasanya terjadi melalui memori bersama atau mekanisme kotak surat. Karena setiap inti dari jenis yang sama, biner yang sama dapat berjalan pada salah satunya.
Multicore heterogen – Campuran dari jenis inti yang berbeda, masing-masing dioptimalkan untuk beban kerja tertentu. Contohnya, kontroler Bluetooth mungkin menyematkan satu inti untuk penanganan protokol sementara inti kedua mengelola logika aplikasi tingkat lebih tinggi. Arsitektur ini umum dalam SoC seluler dan kontroler industri.
Pola distribusi inti lebih membedakan desain multicore:
Multiprosesing simetris (SMP) – Beberapa inti identik mengeksekusi biner yang sama, dikoordinasi oleh sistem operasi real-time (RTOS). Scheduler mendistribusikan pekerjaan di seluruh inti, dan biner dikompilasi untuk satu jenis inti.
Multiprosesing asimetris (AMP) – Setiap inti menjalankan biner sendiri yang khusus. Inti dapat homogen atau heterogen. Komunikasi bersifat opsional dan biasanya ditangani melalui memori bersama atau primitif pesan.
Karena SMP memerlukan satu biner, ia memandati inti homogen. AMP dapat diimplementasikan pada sistem homogen atau heterogen, menjadikannya ideal untuk aplikasi yang memerlukan beban kerja yang berbeda dan khusus.
Alasan Menggunakan Multicore
Seiring melambatnya hukum Moore, jalur yang paling efektif untuk performa yang lebih tinggi adalah memadatkan lebih banyak inti pada die. Sementara kecepatan jam telah stagnan dalam rentang gigahertz angka satu-digit rendah, kepadatan transistor terus meningkat, memungkinkan interkoneksi yang lebih kaya dan cache on-chip yang lebih besar. Desain multicore membuka potensi penuh dari pemadatan ini.
AMP heterogen sangat kuat untuk beban kerja real-time dan terfokus throughput. Dengan mengisolasi fungsi kritis waktu pada inti khusus, desainer dapat memenuhi jaminan latensi ketat tanpa mengorbankan throughput keseluruhan sistem. Pemisahan ini juga menyederhanakan sertifikasi, karena komponen real-time dapat diverifikasi secara independen dari logika aplikasi.
Tantangan Menggunakan Multicore
Mengadopsi arsitektur multicore memperkenalkan serangkaian tantangan perangkat lunak dan sistem:
• Granularitas tugas – Aplikasi monolitik seringkali tidak dapat menggunakan beberapa inti secara efisien. Pengembang harus merespon kode menjadi tugas independen yang dapat berjalan secara bersamaan. Desain thread yang buruk dapat menyebabkan pemanfaatan yang kurang atau kontensi.
• Bottleneck sinkronisasi – Struktur data bersama dan perangkat I/O memerlukan kunci (mutex, spinlock, read-write lock, dll.). Pengunci yang terlalu agresif atau kontensi tinggi dapat serialize pekerjaan dan meniadakan keuntungan paralel.
• Ketidakseimbangan beban – Jika satu inti menyelesaikan pekerjaannya lebih awal sementara yang lain tertinggal, inti yang menganggur mewakili siklus komputasi yang terbuang. Memecah pekerjaan besar menjadi potongan yang lebih kecil dan berukuran seragam adalah penting.
• Keterbatasan real-time – Dalam sistem SMP, scheduler RTOS harus menyeimbangkan latensi dan throughput. Memilih antara partisi data (setiap thread memproses blok data) dan partisi fungsi (setiap thread melakukan tahapan berbeda dari pipeline) tergantung pada profil beban kerja.
Debugging dalam Lingkungan Multicore
Debugging yang efektif bergantung pada visibilitas komprehensif dari semua inti:
• Kontrol terkoordinasi – Debugger harus memungkinkan penghentian, langkah, dan penyesuaian breakpoint secara bersamaan atau independen di seluruh inti.
• Trace multicore – Menangkap data trace dari beberapa inti secara bersamaan membutuhkan transport bandwidth tinggi (misalnya, port SWD dan TPIU CoreSight) dan penyaringan yang cerdas untuk menghindari overload data.
(Sumber: IAR Systems, diagram curhat dari Arm Ltd.)
Arsitektur debug CoreSight Arm mengintegrasikan antarmuka trigger lintas (CTI) dan matriks trigger lintas (CTM), memungkinkan debugger untuk menghentikan atau memicu tindakan pada inti mana dalam respons terhadap peristiwa dari inti lain. Kemampuan ini penting untuk mendiagnosis race condition dan deadlock.
Debugger C-SPY IAR Embedded Workbench mendukung konfigurasi SMP dan AMP. Untuk SMP, pengguna menentukan jumlah inti dan debugger secara otomatis terhubung ke setiap inti. Dukungan AMP memerlukan dua instance IDE (Master dan Node) saat inti menjalankan biner terpisah.
Pada tampilan kanan, kluster SMP 4-inti Cortex-A9 ditampilkan: inti 2 terhenti sementara yang lain terus mengeksekusi.
Untuk sistem heterogen seperti ST STM32H745/755 (Cortex-M7 + Cortex-M4), debugger meluncurkan jendela terpisah IDE untuk setiap inti. Setiap jendela menunjukkan status inti dan, secara opsional, inti lain, memungkinkan pengembang untuk mengamati interaksi antar inti secara real-time.
Dua CTI (tingkat sistem, Cortex-M4, dan Cortex-M7) dihubungkan oleh CTM, memberikan debugger kontrol yang terperinci atas breakpoint dan trigger trace.
(Sumber: IAR Systems, diagram curhat dari STMicroelectronics dari Manual Referensi M0399)
Aplikasi biasanya menggunakan antarmuka memori bersama dan RTOS ringan (misalnya, FreeRTOS) untuk bertukar pesan antara inti. Dari perspektif setiap inti, komunikasi tampak sebagai pesan tugas sederhana, mengabstraksi mekanika antar inti yang mendasarinya.
Di penjelajah workspace, dua proyek (Cortex-M7 dan Cortex-M4) terlihat, dan pengguna dapat beralih fokus di antara mereka. Proyek master secara otomatis meluncurkan instance IDE kedua, menyederhanakan debugging AMP.
Ringkasan
Arsitektur multicore menyediakan performa yang diperlukan seiring melambatnya hukum Moore, tetapi mereka menuntut desain perangkat lunak yang disiplin dan alat debugging yang canggih. Setelah lingkungan debug dikonfigurasi, pengembang menemukan bahwa debugging multicore ternyata cukup sederhana, terutama dibandingkan dengan tantangan yang sering dilaporkan oleh mereka yang hanya bekerja dengan sistem mono-inti.
Perangkat keras modern dan alat perangkat lunak terintegrasi kini membuatnya praktis untuk memanfaatkan performa multicore sambil mempertahankan keandalan dan pelacakan.
Catatan: Gambar figure oleh IAR Systems kecuali dinyatakan lain.
Aaron Bauch adalah Senior Field Application Engineer di IAR Systems yang bekerja dengan pelanggan di Amerika Serikat Timur dan Kanada. Aaron telah bekerja dengan sistem tertanam dan perangkat lunak untuk perusahaan termasuk Intel, Analog Devices, dan Digital Equipment Corporation. Desainnya mencakup berbagai aplikasi termasuk instrumentasi medis, navigasi, dan sistem perbankan. Aaron juga telah mengajar sejumlah kursus tingkat perguruan tinggi termasuk Desain Sistem Tertanam sebagai profesor di Southern NH University. Tuan Bauch memiliki gelar Sarjana dalam Teknik Elektro dari The Cooper Union dan Magister dalam Teknik Elektro dari Columbia University, keduanya di New York, NY.
Konten Terkait:
Memastikan perilaku timing perangkat lunak dalam sistem tertanam berbasis multicore yang kritis
Sistem multicore, hypervisor, dan framework multicore
Komputasi tertanam berkinerja tinggi – Parallelisme dan optimasi kompiler
Anda pikir perangkat lunak Anda bekerja? Buktikan!
Penelusuran perangkat lunak di perangkat yang diterapkan di lapangan
Kompiler dalam dunia asing keamanan fungsional
Untuk lebih banyak Embedded, berlangganan newsletter email mingguan Embedded.