- The Art of HPC adalah seri buku ajar komputasi berkinerja tinggi yang dibuat oleh Victor Eijkhout dari TACC, yang merangkai dasar-dasar komputasi ilmiah hingga pemrograman paralel dan alat pengembangan dalam satu alur
- Volume pertama adalah buku latar belakang komputasi ilmiah yang membahas bagaimana arsitektur komputer, aritmetika, aljabar linear, serta ODE/PDE saling terkait dalam komputasi skala besar
- Volume kedua menjelaskan pemrograman paralel dengan fokus pada MPI dan OpenMP, serta mencakup secara singkat PETSc, Kokkos, Sycl, dan Co-array Fortran
- Volume ketiga membahas C++17 dan Fortran2008 yang digunakan dalam pemrograman sains dan rekayasa, dan dapat dibaca baik oleh pemula maupun pemrogram C
- Volume keempat memperkenalkan alat workflow pengembangan yang diperlukan dalam pekerjaan HPC nyata, seperti compiler, build system, dan manajemen kode sumber
Susunan buku ajar The Art of HPC
- The Art of HPC adalah seri buku ajar komputasi berkinerja tinggi yang dibuat oleh Victor Eijkhout dari TACC
- Seri ini membagi pembahasan tentang latar belakang komputasi ilmiah, pemrograman paralel, bahasa pemrograman ilmiah, dan ekosistem pengembangan HPC ke dalam tiap volume
Cakupan per volume
-
Volume 1: The Science of Computing
- Membahas pengetahuan latar belakang umum yang diperlukan untuk memahami komputasi ilmiah
- Mencakup arsitektur komputer, arsitektur komputer paralel, aritmetika komputer, aljabar linear, serta ODE/PDE
- Menjelaskan bagaimana tiap elemen digabungkan dalam komputasi skala besar, dan bersama Volume 2 membentuk bagian “apa/mengapa” dan “bagaimana” dari HPC
-
Volume 2: Parallel Programming for Science and Engineering
- Volume yang membahas pemrograman paralel, yang penting dalam komputasi ilmiah
- Memperkenalkan terutama versi modern MPI dan OpenMP
- Juga mencakup bagian singkat tentang PETSc, Kokkos, Sycl, dan Co-array Fortran
- MPI dan OpenMP dibahas dalam C, Fortran, dan C++, sementara MPI juga mencakup Python
-
Volume 3: Introduction to Scientific Programming
- Mengajarkan C++17 dan Fortran2008 modern dengan latar C/C++ dan Fortran, yang banyak digunakan dalam pemrograman sains dan rekayasa
- Mengambil pendekatan yang lebih memilih C++17 daripada C
- Dapat dibaca sebagai buku pengantar pemrograman ilmiah dari nol, maupun sebagai buku belajar C++ untuk pemrogram C
- Mencakup beberapa proyek pemrograman yang panjang
-
Volume 4: HPC Carpentry
- Berfokus pada fakta bahwa ekosistem komputasi ilmiah tidak hanya terdiri dari bahasa pemrograman dan sistem pemrograman paralel
- Memperkenalkan elemen yang diperlukan dalam workflow ilmiah, seperti compiler, build system, dan manajemen kode sumber
- Lebih mendekati kumpulan pengantar yang disesuaikan untuk workflow ilmiah daripada referensi yang mencakup semuanya
1 komentar
Pendapat di Hacker News
Sisi perangkat keras/pusat data dari topik ini juga sama menariknya
Dulu saya bekerja di AWS di sisi perangkat lunak/layanan, dan sesekali diam-diam ikut mendengarkan presentasi tim pusat data
Pencerahan terbesar saya adalah bahwa meningkatkan daya komputasi di pusat data sebenarnya lebih mirip masalah termodinamika daripada komputasi itu sendiri. Kepadatan node menjadi terlalu tinggi, sehingga memasok daya dan membuang panas—ditambah berbagai bentuk redundansi—menjadi luar biasa sulit. Bahkan ketika menemukan inefisiensi, itu juga bukan sesuatu yang bisa diperbaiki seperti pembaruan perangkat lunak
Ini cerita sekitar 10 tahun lalu, jadi mungkin sekarang ada hal-hal yang sudah berubah, tetapi tetap mengejutkan bahwa Amazon, yang berawal sebagai toko buku internet, berada di garis depan pemecahan masalah termodinamika
Pada Cray-2, ia mengambil pendekatan yang lebih ekstrem: menggunakan struktur pendinginan yang merendam tumpukan papan sirkuit padat dalam cairan nonkonduktif khusus bernama Fluorinert™: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
Air memiliki kapasitas panas yang sangat besar, dan dapat mendinginkan volume besar dengan cepat hingga suhu optimal. Kipas dan AC tetap diperlukan untuk membuang panas dari komponen yang tidak bisa memakai pendinginan cair, tetapi pada komponen dengan konsumsi daya besar seperti CPU atau GPU/mesin komputasi, panas dalam jumlah sangat besar bisa dibuang dengan cepat dan langsung
Kompleksitas dan risiko kebocoran memang menjadi masalah, tetapi untuk pusat data berskala Amazon rasanya itu bukan kekhawatiran yang begitu besar
Saya penasaran seperti apa teknologi pendinginan mutakhir saat ini
Menarik ketika HPC kadang terlihat cukup terabstraksi dari perangkat keras
Buku-buku tampaknya banyak membahas pemrograman SPMD, algoritma dan struktur data, paralelisme tugas, sinkronisasi, dan sebagainya, tetapi detail arsitektur komputer seperti subsistem memori superkomputer, interkoneksi bandwidth tinggi seperti CXL, atau struktur GPU tampak lebih sedikit
Saya juga penasaran apakah abstraksi dan alatnya sudah cukup baik sehingga detail seperti ini tidak perlu dipedulikan, atau apakah para praktisi HPC banyak mengutak-atik knob black box untuk memeras performa
Sebagai prinsip umum, untuk skalabilitas optimal, topologi perangkat lunak harus sebisa mungkin selaras dengan topologi perangkat keras. Perangkat lunak HPC yang efisien sangat dipengaruhi karakteristik perangkat keras
Saat menulis kode untuk perangkat keras HPC baru, orang-orang selalu terkejut ketika saya meminta dokumen sistem perangkat keras dan arsitektur, bukan dokumen pemrograman. Jika memahami desain perangkat keras, bagaimana perangkat lunak harus dirancang di atasnya menjadi jelas dari prinsip pertama. Dokumen pemrograman berisi cukup banyak kebenaran setengah-setengah yang membuatnya tampak lebih mudah bagi pengembang daripada kenyataannya
Beberapa platform HPC, agar tampak “mudah digunakan”, terus-menerus keliru menyampaikan apa yang perlu dilakukan pengembang untuk mendapatkan performa maksimum, dan ketika perangkat lunak ditulis sesuai cara yang diisyaratkan pemasaran, hasilnya gagal besar karena tidak mencapai performa yang mampu diberikan silikon
Kode HPC bisa ditulis di atas abstraksi, dan memang banyak yang melakukannya, tetapi kerugian performa dan skalabilitas sering kali berada pada tingkat kelipatan bilangan bulat yang tak terhindarkan. Seperti perangkat lunak lain, kerugian seperti ini sering dianggap dapat diterima jika memungkinkan pengembang yang kurang ahli merancang kodenya
HPC juga sama seperti perangkat lunak lain: meski secara jabatan disebut pengembang profesional, banyak orang sulit menghasilkan hasil yang baik secara konsisten. Sebagian besar perangkat keras mahal yang dipakai di HPC ada untuk meredam kehilangan performa akibat desain perangkat lunak yang buruk
Jika menginginkan performa maksimum, tidak ada jalan pintas selain benar-benar memahami bagaimana perangkat keras bekerja. Tidak berbeda dari perangkat lunak biasa; di HPC, sistem perangkat kerasnya hanya lebih besar dan lebih kompleks
Namun ternyata berbeda dari perkiraan. Saya kira akan lebih banyak mengerjakan hal berorientasi performa, menganalisis angka, dan memeras performa terakhir dari cluster. Jujur saja, awalnya bahkan tidak ada monitoring. Saya membangunnya sendiri, tetapi hampir tidak dipakai. Sesekali manajemen bertanya “seberapa sibuk cluster” untuk alasan seperti justifikasi anggaran
Sebagian besar ‘optimasi’ berupa memastikan orang tidak meminta 384 CPU padahal skripnya hanya memakai 16 CPU, atau menguji sampai berapa CPU suatu software bisa berjalan tanpa penurunan performa. Saya hanya pernah membuka profiler Intel dua kali
Sebagian besar pekerjaan lebih dekat ke membantu pekerjaan para peneliti. Biasanya menjalankan program komersial atau open source dan memecahkan masalahnya, atau mengambil kode yang ditulis tim lain di cluster lain lalu membuatnya bisa dibangun dan dijalankan di cluster kami. Mengutak-atik kode Python yang buruk, dan berusaha membangun proyek C++ dari cluster yang lebih modern ke lingkungan CentOS 7
Ada kesenangannya sendiri. Karena saya pernah menangani banyak bahasa, saya menikmati membuat sesuatu berjalan, serta menggali crash dan stack trace. Saat bekerja dengan mesin besar, standar normal jadi bergeser ketika melihat server yang RAM-nya ‘hanya’ 128GB atau disknya 20TB
Yang menakutkan adalah hasil-hasil ini dipakai di dunia nyata, tetapi orang-orang yang menjalankan simulasi kadang tidak melakukannya dengan benar. Saya pernah menemukan kode yang salah, source code yang bercampur, penggunaan data yang berbeda dari data yang mereka kira sedang dipakai, bahkan bug besar yang sudah ada selama 3 tahun. Saat itu rasanya semua pekerjaan yang sudah dilakukan pada topik ini bisa jadi batal seluruhnya
Kekurangannya adalah banyak pekerjaan HPC menuntut gelar master meskipun tugasnya hanya mengoperasikan cluster. Saya tidak begitu mengerti. Saya tidak menulis software yang saya jalankan, dan tidak mengoperasikan cluster TOP500 terbaru. Ini hanya pekerjaan menghubungkan beberapa mesin lewat jaringan dan menjalankan kode
Dari pengalaman bekerja dengan developer CUDA, banyak knob yang diutak-atik untuk memeras performa. Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, di sebagian industri juga disebut ‘wedge’) adalah salah satu alat utama dalam optimasi sehari-hari
Namun saya tidak tahu apakah ini layak disebut black box. Pada akhirnya mungkin mirip. Meski tahu apa yang dilakukan knob dan bagaimana cara kerjanya, serta membuat tebakan yang berdasar, saat diukur sering muncul kejutan besar. Aturan pertama optimasi adalah mengukur
Saya selalu teringat bab pertama “The Best Optimizer is Between Your Ears” dari “Black Book” karya Michael Abrash http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf. Memang berpusat pada game PC, bukan HPC modern, tetapi merupakan tulisan bagus yang menunjukkan filosofi performa tinggi
Terkait abstraksi, tuning knob yang paling berat sebaiknya dilakukan di akhir proses optimasi. Sebab jika melakukan refactoring atau mengubah sesuatu, tuning knob harus diulang. Perubahan kecil pada register spill atau pola akses cache saja bisa sepenuhnya mengatur ulang tuning detail seperti konfigurasi thread, cache, dan ukuran shared memory
Meski begitu, tuning knob dalam jumlah yang wajar tetap perlu dilakukan di tengah proses. Tujuannya untuk melakukan pengecekan dan penyeimbangan, serta membangun intuisi tentang ruang performa di sekitar kode
Pada perangkat keras x86_64 saat ini, tidak ada yang namanya subsistem memori superkomputer. Itu hanya sistem NUMA yang mewah, dan masalah terbesarnya adalah menempatkan memori dekat dengan core, yakni menjaga data tetap lokal di dalam node NUMA tersebut untuk mengurangi latensi
Pemetaan resource ditangani oleh scheduler. Scheduler mengetahui perangkat keras, sehingga ia membuat cgroup yang memenuhi kebutuhan dan seoptimal mungkin, lalu memasukkan aplikasi ke cgroup itu untuk dijalankan
Saat ini raja interkoneksi berkinerja tinggi adalah InfiniBand, yang mempercepat MPI di tingkat fabric. Pengiriman pesan, broadcast, dan reduksi hasil bisa dilakukan sangat cepat. Saat pesan tiba, hasilnya sudah direduksi, dan saat melakukan broadcast, cukup mengirim satu pesan; broadcast dilakukan di lapisan fabric. Kartu IB multi-konteks memiliki banyak queue, sehingga beberapa pekerjaan MPI dapat dijalankan dari satu node/kartu dengan isolasi queue/konteks
Jika memakai framework untuk pekerjaan GPU, struktur dan optimasi biasanya ditangani otomatis di tingkat tersebut. Pekerjaan berat umumnya dilakukan oleh para pengembang framework. Driver NVIDIA juga murni ilmu hitam, dan menangani sebagian optimasi. Koneksi antar-GPU ditangani oleh fabric fisik serta dikelola oleh driver dan daemon miliknya sendiri
Jika bottleneck ada di CPU, library biasanya sudah di-tuning manual oleh vendor. Contohnya Intel MKL, BLAS, dan Eigen; Eigen yang pernah saya pakai secara pribadi menyertakan hint dan optimasi khusus prosesor
Yang perlu diperhatikan adalah mengompilasi kode untuk arsitektur yang tepat, serta memastikan hardware tempat menjalankannya dapat memenuhi kebutuhan. Misalnya, jangan terlalu banyak melakukan akses memori acak; jika ingin berjalan “secepat mungkin” di sebuah node, sesuaikan dengan prefetcher dan branch predictor, serta jangan menyalahgunakan akses disk
Di sisi komputasi numerik, kuncinya adalah menjaga pekerjaan tetap independen agar paralelisme tingkat instruksi/vektorisasi dimungkinkan, tidak melakukan komputasi yang tidak perlu, dan tidak menyalahgunakan MPI—dengan kata lain, mengurangi komunikasi antarnode sampai tingkat yang benar-benar diperlukan
Memang lebih mudah diucapkan daripada dilakukan, tetapi setelah terbiasa, memikirkan hal-hal seperti ini menjadi seperti naluri kedua. Maksudnya, jika jenis pekerjaan seperti ini memang cocok dengan selera Anda
Bisa benar, bisa juga tidak
MPI dan OpenMP adalah sarana utama untuk mengabstraksikan hardware di HPC. MPI adalah abstraksi untuk komputasi paralel memori terdistribusi, sedangkan OpenMP adalah abstraksi untuk komputasi paralel memori bersama. Banyak peneliti menulis kode hanya dengan keduanya, dan sering juga memakai keduanya dalam kode yang sama. Saat menggunakannya, sebagian besar detail arsitektur tidak perlu dipikirkan
Meski begitu, peneliti yang gemar mengoptimalkan lebih jauh sering mengutak-atik banyak detail struktural kecil untuk memeras performa lebih tinggi. Misalnya loop unrolling cukup umum, dan menurut saya pribadi bisa cukup membingungkan. Saya samar-samar ingat pernah mendengar bahwa karena arsitektur CPU tertentu, orang lebih memilih penjumlahan daripada perkalian untuk mencoba memvektorisasi operasi, tetapi saya belum pernah melihatnya langsung
Mencegah cache miss juga merupakan topik besar. Ada kode yang ditulis agar informasi yang paling dibutuhkan berada di cache CPU, bukan di memori. Sebagian besar kode hanya menangani ini sebatas menjamin traversal column-major untuk operasi array di Fortran dan traversal row-major di C, tetapi konsepnya bisa diperluas lebih jauh. Jika mengetahui ukuran cache prosesor, operasi tertentu juga dapat dioptimalkan agar semua informasi yang diperlukan tetap berada di dalam cache sehingga cache miss diminimalkan. Saya belum pernah melihatnya secara nyata, tetapi hal ini dibahas aktif dalam kelas komputasi ilmiah yang saya ikuti pada 2013
Apakah menggunakan GPU tertentu sangat bergantung pada masalah yang ingin diselesaikan. Sebagian masalah sangat cocok untuk GPU, sementara sebagian lainnya terlalu sulit. Sayangnya saya tidak terlalu tahu bagian itu
Kagum bahwa Victor telah mengumpulkan materi yang luar biasa seperti ini
Saya tidak mengenalnya secara pribadi, tetapi saat menempuh program doktor di UT Austin pada 1990-an, saya menyelesaikan riset dengan menggunakan sumber daya yang dikelola TACC (Cray Y-MP, IBM SP/2 Winterhawk, dan hostname Lonestar yang saat itu merujuk ke Cray T3E). Salah satu anggota komite disertasi saya masih berada di sana. Kalau ingatan saya benar, saat itu TACC disebut HPCC atau CHPC
Pada masa itu programmer harus memparalelkan kode sendiri, dan dalam kasus saya, saya memakai MPI di Cray T3E dalam lingkungan UNICOS. Karena bidangnya masih tahap awal, pemahaman tentang hardware juga diperlukan sampai batas tertentu. Saya menyelesaikan masalah dengan membaca binder cincin Cray berwarna abu-abu dan buku Gropp dkk. yang saya pegang, dan tentu saja kontak berpengetahuan yang disebutkan sebelumnya juga sangat membantu
Zaman memang tidak pernah berhenti
Sedikit di luar bidang saya, tetapi sangat menarik. Saya berencana melihat sisanya juga, dan menyarankan siapa pun yang tertarik untuk memeriksanya
Tertarik pada sisi manajemen hardware dalam HPC
Saya penasaran bagaimana masalah dideteksi dan didiagnosis, bagaimana dipetakan ke tindakan seperti reboot/instal ulang/perbaikan, serta bagaimana pekerjaan semacam ini dijadwalkan dan dioptimalkan untuk memberikan tingkat layanan terbaik
Saya juga tertarik bagaimana caranya ketika ada beberapa target yang harus dioptimalkan sekaligus, seperti ketersediaan node dan throughput keseluruhan; bagaimana berbagai topologi memengaruhi hal-hal di atas; bagaimana batasan lain berpengaruh; dan secara umum bagaimana masalah seperti ini ditangani dari sudut pandang dinamika sistem
Saya belum banyak menemukan materi yang membahas informasi seperti ini dengan baik. Kalau ada yang tahu referensi, saya senang diberi tahu
Teori antrean saat pertama dipelajari terlihat sepele dan mudah, tetapi ada banyak masalah terbuka
Misalnya, metrik kinerja untuk sistem dengan waktu kedatangan acak, waktu layanan independen, dan k server (M/G/k) pun masih merupakan masalah terbuka
https://www.sciencedirect.com/science/article/pii/S0895717704905341
Berlawanan dengan dugaan, dalam teori antrean benar-benar ada banyak masalah terbuka
Meta punya beberapa video YouTube yang cukup bagus yang menjelaskan masalah menangani GPU pada skala sebesar ini
Meta juga menerbitkan banyak paper, blog, dan proyek open source di situs engineering mereka [2]
James Hamilton dari AWS juga hampir setiap tahun memberikan presentasi tentang infrastruktur. Presentasi dari beberapa tahun layak ditonton [3]
[1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
[2] https://engineering.fb.com/category/data-center-engineering/
[3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
Pada dasarnya, optimasinya dilakukan pada tingkat workload, di sini pekerjaan deep learning, sehingga memungkinkan penyesuaian ukuran pekerjaan dan preemption
[1] https://arxiv.org/pdf/2202.07848.pdf
Pada 2013 saya mengambil kelas komputasi ilmiah
Mata kuliah itu ditawarkan lintas jurusan, baik di ilmu komputer maupun matematika terapan. Masalahnya, bidang ini secara keseluruhan terlalu luas, sehingga banyak topik termasuk HPC dan pemrograman paralel dibahas sangat dangkal. Saya tidak menyesal mengambilnya, tetapi cakupannya terlalu luas untuk aplikasi yang saya kejar
Saya sudah beberapa tahun tidak melihat mata kuliah apa saja yang ditawarkan, tetapi saat masih mahasiswa pascasarjana, mata kuliah khusus yang membahas komputasi paralel selama satu semester penuh pasti sangat membantu. Terutama, saya membutuhkan kelas yang mendalami algoritma dan struktur data tertentu untuk komputasi paralel dan terdistribusi
Di kelas komputasi ilmiah yang saya ambil, topik-topik ini dibahas terlalu sepintas, seolah-olah pada percobaan pertama pun kita bisa tahu persis cara memparalelkannya dengan benar. Setelah itu, seperti banyak orang HPC lainnya, saya belajar banyak sendiri dan dari rekan kerja selama bertahun-tahun, tetapi buku-buku seperti ini akan sangat berharga jika menjadi bagian dari kelas khusus satu semester
Mengejutkan bahwa penulis membuat buku-buku selengkap ini, bahkan mencakup pelatihan C++ dan alat Unix, lalu membagikannya secara gratis
Bahkan jika tidak khusus HPC, ada hal yang bisa dipelajari oleh semua programmer
Sebagai materi terkait, ada juga buku “Matters Computational” karya Jorg Arndt dan pustaka FXT: https://www.jjj.de/fxt/
Saya penasaran bagaimana orang memandang metode pengajaran C++ yang dipakai di sini. Apakah ada kekurangan khusus?
Saya sudah sangat lama memakai Python, juga sedikit menangani C, C++, dan CUDA, serta melakukan riset tingkat aplikasi (ML/DL) di lingkungan HPC. Saya ingin meningkatkan kemampuan C++, dan setelah menelusuri ketiga jilidnya, tampaknya pas sekali dengan level saya. Alurnya tidak terlalu lambat, dan alih-alih bertujuan mencakup semuanya, pendekatannya mengajarkan praktik terbaik menurut penulis
Saya mencari range-based for loop, std::array, dan std::span, dan senang semuanya ada
Karena buku ini terkait HPC, ada beberapa hal yang ingin saya tambahkan. Akan bagus jika ada penjelasan tentang optimasi nilai balik, move semantics, dan pada bagian fungsi rekursif, optimasi tail call
Sebagai materi pemula, saya sangat bisa merekomendasikannya
Sebagai catatan, MPI hanyalah salah satu cara melakukan HPC dengan Python
Jika ingatan saya benar, ipyparallel bisa menjalankan job MPI di atas tunnel yang dibuat sendiri
Akan lebih mutakhir jika ada bab tentang dask-scheduler, CuDF, CuGraph(NetworkX), DaskML, CuPy, dan dask-labextension
Dask tidak menangani penyimpanan data untuk Anda, jadi menjadi tanggung jawab pengguna untuk memastikan penyimpanan data sebelum setiap barrier tidak menjadi bottleneck performa
High Performance Computers di dokumentasi Dask: https://docs.dask.org/en/stable/deploying-hpc.html
Sumber bilangan acak juga bisa menjadi bottleneck. Anda tidak akan tahu sebelum memprofilkan pekerjaan di seluruh klaster
Terkait alat tracing berbasis eBPF: https://news.ycombinator.com/item?id=31688180
Setelah itu, akan bagus juga jika ada materi seperti GitOps dan ChatOps, code review dan revisi, serta kuota sumber daya proyek
Sepuluh tahun lalu saya ditawari untuk berbagi peran sebagai asisten pengajar mata kuliah pascasarjana HPC, tetapi saya menolaknya
Dari penelusuran sekilas, saya bisa jujur mengatakan bahwa jika buku ini sudah ada saat itu, saya akan mengambil kesempatan tersebut
Perpaduan antara framing sebagai seni yang terasa ala Knuth, sudut pandang yang menganalogikannya dengan pertukangan kayu, dan kebutuhan untuk menjadi orang DevOps yang lebih baik daripada orang DevOps Anda sendiri, terasa meyakinkan
Saya memberi apresiasi atas pencapaian penulisnya. UT Austin tampaknya telah melakukan bagi ilmu komputer sesuatu yang mirip dengan apa yang dilakukan North Texas State bagi musik
UT Austin benar-benar institusi yang luar biasa dalam HPC dan metodologi komputasi
Ketika saya bergabung dengan sebuah perusahaan kecil yang mendukung para engineer HPC di produsen mobil besar, saya terkejut melihat begitu banyak skrip pengembangan internal di sekitar scheduler LSF
Jauh setelah itu, saat mengutak-atik SLURM di mini-klaster pribadi, saya mengetahui bahwa versi perangkat lunak scheduler umumnya tidak kompatibel satu sama lain. Artinya, tidak bisa memakai satu versi di dalam klaster dan versi lain di mesin klien eksternal
Karena itu diperlukan perangkat lunak perekat untuk mengirim job ke scheduler dari luar dan mengambil hasilnya nanti. Secara pribadi, saya menganggap ini menurunkan nilai scheduler
Saya mengira setelah sekitar 30 tahun komputasi terdistribusi berperforma tinggi, kebutuhannya sudah dikenal baik dan setidaknya protokol pertukaran perintah dan data sudah baku. Rupanya tidak demikian
Di masa lalu juga ada upaya untuk menstandarkan API manajemen job dasar, dan DRMAA adalah contoh yang patut dicatat. Namun DRMAA v2 hanya diimplementasikan oleh Grid Engine, dan pada dasarnya merupakan versi yang sedikit mengabstraksikan API internalnya, sehingga tidak mendapat dukungan kelas satu di Slurm/PBS/LSF
Di Slurm, REST API dipandang sebagai arah ke depan. Masalah autentikasi diserahkan melalui proxy Apache/NGINX ke cara apa pun yang ingin dihubungkan oleh admin. API pengiriman job dasar dan statusnya kini sudah cukup stabil sehingga dapat dikonsumsi oleh hampir versi aplikasi klien apa pun ke depannya