Sebagai bagian dari kolom "Ajukan pertanyaan ke pakar Intel", kami meminta spesialis Intel terkemuka Konstantin Vladimirov untuk menjawab pertanyaan terkait pemrograman heterogen,
toolkit oneAPI, dan hal-hal menarik terkait. Hasilnya melebihi semua harapan kami. Konstantin tidak menyisihkan waktu dan memberikan jawaban yang terperinci dan kuat, tanpa takut menjadi polemik. Bahkan, kami mendapat kuliah kecil tentang pemrograman lintas-arsitektur dalam segala bentuknya: nuansa muatan, optimisasi, standar, dan sebagainya.
Kami mentransfer mikrofon ke ahli. Nah, komentar diberikan kepada audiens.
Pertanyaan
Soarex16Seberapa melelahkan transisi dari OpenCL ke oneAPI dan manfaat apa yang bisa didapat dari ini?
Jawabannya Beralih ke DPC ++ bisa rumit, tapi menurut saya, itu sepadan. Ada dua tahap utama.
Pertama, ini adalah transisi dari bahasa pemrograman heterogen Anda (komputasi OpenCL, Vulkan), yang, kemungkinan besar, didasarkan pada API. Di sini Anda memiliki permulaan dalam kenyataan bahwa Anda sudah mengetahui bidang subjek, dan kesulitannya adalah dalam mengalihkan pemikiran dari kontrol langsung melalui API ke konstruksi bahasa yang sedikit lebih implisit.
Kedua, ini adalah transisi dari bahasa host Anda. Jika Anda telah melepas seluruh hidup Anda dari C murni, maka ambang input sama dengan ambang untuk beralih dari C ke C ++, yang cukup tinggi.
Mengapa mencoba
Pertama, DPC ++ melakukan pekerjaan yang bagus untuk seorang programmer. Anda akan dengan cepat lupa, seperti mimpi buruk, semua panggilan eksplisit ini ke clXXXYYY, dan apa arti argumen keenam, dan apakah Anda lupa kode pengembalian. Banyak pembungkus berorientasi objek menyembunyikan rutinitas tidak lebih buruk, tetapi biasanya dengan biaya beralih dari API OpenCL standar ke API pembungkus yang tidak terlalu standar (saya juga melihat sepeda itu). Dalam kasus DPC ++, Anda cukup menulis SYCL standar dengan ekstensi Intel (yang mungkin juga akan menjadi SYCL standar).
Kedua, DPC ++ menyediakan untuk kompilasi bersama, yaitu, Anda dapat memastikan jenisnya dan Anda tidak akan memiliki masalah di perbatasan API dengan dimensi, pengisi, pelurusan. Anda menulis kode kernel dan host dalam satu file, dan ini adalah kode yang sama. Menggunakan USM, Anda juga dapat bekerja dengan struktur data yang kompleks jauh lebih mudah.
Ketiga, DPC ++ adalah C ++ asli, yaitu memungkinkan pemrograman umum. Misalnya, kernel paling sederhana untuk menambahkan dua vektor:
auto kern = [A, B, C](cl::sycl::id<1> wiID) { C[wiID] = A[wiID] + B[wiID];
Hal yang sama di OpenCL:
_kernel void vector_add(__global int *A, __global int *B, __global int *C) { int i = get_global_id(0); C[i] = A[i] + B[i]; }
Soalnya, saya terpaksa menunjuk ke int tipe OpenCL. Jika saya membutuhkan float, saya harus menulis kernel lain, atau menggunakan preprocessor, atau pembuatan kode eksternal. Mendapatkan hampir semua fitur C ++ yang Anda inginkan bisa sedikit menakutkan jika Anda belum memiliki pengalaman dengan C ++. Tapi ini adalah hal yang umum ketika terjadi perubahan teknologi besar.
Dan semua manfaatnya tidak terbatas pada ini saja. Saya akan menyebutkan hal lain dalam jawaban berikut.
Jadi saya akan mengunduh kompiler di tempat Anda dan mencobanya, karena tidak sulit melakukan ini dengan paket
OneAPI .
Juster Pertanyaan
Apakah OpenVINO dan oneAPI terkait entah bagaimana?
Jawabannya Distribusi OpenVINO sekarang menjadi bagian dari distribusi OneAPI. Belajar dan menggunakan jaringan saraf adalah tugas yang sulit secara komputasi yang sangat diuntungkan dari pemrograman heterogen. Saya percaya bahwa cepat atau lambat, semua komponen OneAPI akan memungkinkan untuk menggunakan semua sumber daya komputasi yang tersedia untuk Anda: akselerator grafis dan akselerator khusus seperti Nervana dan FPGA. Dan semua ini tanpa meninggalkan paradigma bahasa dan sistem tipe program C ++ Anda.
Pertanyaan dari surat
Saya mencoba memahami bagaimana akselerator perangkat keras AI dalam 3 tahun, tolong bantu dengan ini. Ada perusahaan Graphcore yang menarik dan IPU-nya - perangkat ini tidak kalah efisien dari FPGA, tetapi jauh lebih mudah untuk diprogram - Python dengan dukungan untuk TensorFlow dan kerangka kerja lainnya. Ternyata jika janji-janji Graphcore dipenuhi, tidak akan ada kebutuhan untuk FPGA di pasar pembelajaran mesin. Python jauh lebih nyaman untuk ilmuwan data daripada C ++.
Apakah Anda setuju bahwa FPGA tidak cocok untuk pasar pembelajaran mesin dibandingkan dengan solusi yang dapat diprogram Python? Jika pasar ML hilang, aplikasi FPGA luas apa lagi yang Anda lihat?
Dalam aplikasi apa Anda melihat kebutuhan yang tak terhindarkan untuk pemrograman heterogen, di mana Anda tidak bisa bertahan dengan alat yang lebih nyaman seperti Python?
Jawabannya Saya melihat sekilas IPU seperti apa. Satu potong besi lagi yang akan dilepas semua orang. Orang-orang ini bersaing dengan GPU dan dengan akselerator khusus, dan bukan dengan FPGA.
Dalam tugas-tugas yang mana perangkat keras khusus dipertajam, itu akan selalu mengalahkan FPGA, misalnya, membuat video lebih baik pada kartu video, dll. Tetapi di dunia (termasuk di dunia ML) ada banyak tugas yang tidak ada yang khusus diciptakan atau dirilis, dan di sini FPGA akan selalu diperlukan. Misalnya, karena ada masalah harga dan, agar murah, perangkat keras khusus harus besar.
Asumsikan sekarang bahwa IPU yang ditentukan benar-benar keren. Ini tidak akan membatalkan pemrograman heterogen, sebaliknya, kehadiran akselerator yang sangat baik akan memacu itu. Dan itu juga akan memberikan kepala raksasa memulai OneAPI dan DPC ++, karena cepat atau lambat seseorang akan berkata "Saya ingin menggunakan IPU dan GPU saya dari satu program." Agak awal karena pemrograman heterogen adalah tentang itu. Artinya adalah pembongkaran tugas yang cocok ke perangkat yang sesuai. Sebuah tugas bisa datang dari mana saja. Dan perangkat ini bisa berupa apa saja, bahkan bisa menjadi perangkat yang sama tempat program dijalankan. Sebagai contoh, jika Anda melepas kernel yang ditulis dalam ISPC dan memanfaatkan fitur vektor Xeon secara maksimal, Anda dapat melepasnya sendiri dan masih menjadi keuntungan yang signifikan. Kriteria utama di sini adalah kinerja. Ya, tidak akan pernah ada terlalu banyak produktivitas di dunia ini. Bahkan dengan akselerator terbaik di dunia.
Adapun Python dan kenyamanannya ... Saya harus segera mengakui bahwa saya tidak suka bahasa yang diketik secara dinamis: mereka lambat dan bukannya kesalahan kompilasi normal, Anda harus menunggu dua jam sebelum jatuh ke runtime karena jenis yang salah. Tapi saya tidak melihat betapa buruknya melakukan offload yang sama dari bawah Python. Omong-omong, OneAPI sudah menyertakan Intel Distribution for Python, yang sangat nyaman untuk berbagai tinjauan.
Yaitu, di dunia impian para pecinta Python, Anda menulis sebuah program di atasnya dan menurunkannya ke semua akselerator yang dapat Anda temukan menggunakan OneAPI, dan bukan sekelompok perpustakaan khusus vendor. Hal lain adalah bahwa dengan pendekatan ini Anda kehilangan pengetikan ujung ke ujung dan kembali ke dunia pemrograman berbasis API yang sangat berbahaya. Mungkin pengembangan DPC ++ akan mendorong masyarakat untuk lebih aktif menggunakan alat yang lebih tepat, seperti C ++.
Pertanyaan dari surat
Kinerja versus OpenCL. Harus ada pajak untuk barang mewah - mis. biaya overhead. Apakah ada pengukuran?
Jawabannya Di Internet Anda dapat menemukan banyak pengukuran dengan berbagai hasil, tergantung pada kompiler, tugas dan kualitas implementasi. Sebagai penelitian pribadi, saya mengukur pada tugas-tugas sederhana (SGEMM, DGEMM) pada laptop saya (grafik Skylake terintegrasi), dan saya melihat bahwa sejauh ini ada beberapa drawdown (dalam persen). Tapi menurut saya ini adalah konsekuensi dari kenyataan bahwa semua ini adalah beta sejauh ini.
Secara teori, hasilnya harus akselerasi, bukan perlambatan, yaitu, pada prinsipnya, semua kemewahan ini harus memiliki nilai negatif. Ini semua tentang kompiler. Ketika program Anda terdiri dari satu sumber dan diproses sebagai satu program, kompiler mendapat peluang fantastis, luar biasa untuk optimasi: meletakkan kode umum, membalikkan loop, menyusun ulang bagian kode, dan segala sesuatu yang tidak dapat dilakukan oleh kompiler dalam pendekatan berbasis API, tetapi cepat atau lambat, dia pasti akan belajar dengan model sumber tunggal.
Selain itu, DPC ++ akan memiliki biaya negatif dalam hal waktu pengembangan. Contoh sederhana adalah pengakses SYCL, yang sudah digunakan oleh kompiler untuk mengatur acara dan mengelola antrian asinkron.
deviceQueue.submit([&](cl::sycl::handler &cgh) { auto A = bufferA.template get_access<sycl_read>(cgh); auto B = bufferB.template get_access<sycl_read>(cgh); auto C = bufferC.template get_access<sycl_write>(cgh); .... deviceQueue.submit([&](cl::sycl::handler &cgh) { auto A = bufferA.template get_access<sycl_read>(cgh); auto B = bufferB.template get_access<sycl_read>(cgh); auto D = bufferD.template get_access<sycl_write>(cgh);
Di sini, kompilator melihat bahwa kedua paket hanya membaca A dan B dan menulis buffer independen C dan D, sebagai hasilnya, ia melihat kemampuan untuk mengirimnya secara paralel jika ada ukuran global yang cukup.
Tentu saja, program OpenCL yang ditulis dengan pedantik dapat melakukannya juga, tetapi waktu pengembangan yang dihabiskan dengan kernel non-sepele tidak akan sebanding.
Pertanyaan dari surat
Apakah semua cara untuk mengoptimalkan aplikasi OpenCL untuk DPC ++ relevan? Apa yang baru ditambahkan ke mereka?
Jawabannya Saya akan mengatakan bahwa sebagian besar optimasi manual yang dilakukan oleh penulis kernel dapat dan harus dilakukan oleh kompiler. Dengan cara yang sama, misalnya, saya menganggap itu praktik berbahaya untuk menginstal inline assembler secara manual dalam program C ++, karena meskipun memberikan manfaat taktis, itu mengganggu optimasi dan bertindak sebagai faktor negatif dalam pengembangan dan transfer produk. Nah, OpenCL sekarang juga assembler.
Adapun jawaban yang lebih rinci, saya takut jurang maut di sini. Misalnya, ada dokumen Intel yang terkenal "Panduan Pengembang OpenCL untuk Intel Processor Graphics". Dan ada
bagian tentang cara mencoba, agar tidak meletakkan tempat sinkronisasi berlebih.
Jadi, dari sudut pandang saya, pada prinsipnya ini bukan tugas manusia. Orang-orang sangat miskin dalam alasan tentang sinkronisasi multi-utas dan cenderung memahat sinkronisasi baik secara konservatif atau tidak benar, atau keduanya sekaligus - saya menempatkan koma seperti ini (
tetapi kami memperbaikinya - catatan editorial ).
Di sisi lain, di DPC ++, alih-alih menulis kode dengan penghalang eksplisit, seperti ini:
for (t = 0; t < numTiles; t++) { const int tiledRow = TS * t + row; const int tiledCol = TS * t + col; Asub[col][row] = A[globalRow * AY + tiledCol]; Bsub[col][row] = B[tiledRow * BY + globalCol];
Anda kemungkinan besar akan menulis iterasi eksplisit
parallel_for_work_group , di dalamnya
group.parallel_for_work_item cgh.parallel_for_work_group<class mxm_kernel>( cl::sycl::range<2>{BIG_AX / TS, BIG_BY / TS}, cl::sycl::range<2>{TS, TS}, [=](cl::sycl::group<2> group) {
Akibatnya, Anda tidak perlu mengatur sinkronisasi dengan tangan sama sekali, dan seluruh bagian dapat dibuang.
Sehingga Anda bisa berjalan di semua bagian. Sesuatu akan bertahan, sesuatu akan pergi. Saya meramalkan munculnya dokumen baru "Optimasi untuk DPC ++", tetapi waktu harus berlalu, karena semua teknik yang benar-benar bekerja dikembangkan kemudian dan dengan darah
Pertanyaan dari surat
Ada batasan dalam OpenCL - Anda tidak dapat menggunakan "data jauh" di kernel, yaitu, misalnya, menerapkan "filter lebar" yang menggunakan input data dari kelompok besar piksel lebih besar dari kelompok kerja OpenCL dalam satu perhitungan. Apa yang DPC ++ tawarkan dalam hal ini?
Jawabannya Yah, itu tidak mungkin. Tentu saja, saya tidak terlalu menulis kernel ... Tetapi sangat yakin bahwa Anda dapat menggunakan semua memori global seperti itu, Anda hanya perlu memastikan bahwa Anda bekerja dengan operasi atom (atau menyinkronkan kernel hirarkis secara eksternal). Dan Anda juga dapat menghubungkan Sistem SVM (baik, atau ada USM di DPC ++).
Sayangnya, semua ini sangat tidak efisien, dan saya tidak suka semua trik ini. Selain itu, mereka sulit dioptimalkan oleh kompiler.
Jadi, jika kita berbicara tentang solusi langsung dan efektif, maka, tentu saja, tidak ada keajaiban di DPC ++. Program Anda pada akhirnya masih dibagi menjadi beberapa bagian: kode host dan kode perangkat, dan semua pembatasan perangkat memengaruhi kode perangkat. Ukuran maksimum kelompok kerja adalah paralelisme nyata yang dapat dilakukan perangkat keras Anda. Semua yang ada di atasnya hanyalah cara untuk keluar, secara dramatis memengaruhi kinerja. Itulah sebabnya DPC ++ memberikan kesempatan untuk melakukan ini:
device.get_info <sycl :: info :: device :: max_work_group_size> () dan kemudian memutuskan bagaimana hidup dengan nomor yang dihasilkan.
Tentu saja akan tergoda untuk membuat model di DPC ++, ketika programmer bekerja sesuka Anda dengan loop berapa pun, dan kompiler melihat apa yang harus dilakukan selanjutnya, tetapi itu akan sangat salah, karena akan menyembunyikan konstanta, dan bahkan asimtotik dari kompleksitas tambahan. komputasi muncul entah dari mana. Untuk alasan lain, Alexandrescu menulis bahwa "kerumitan yang merangkum harus dianggap sebagai kejahatan," dan ini juga berlaku.
Terkadang merevisi algoritma itu sendiri membantu. Di sini DPC ++ membuat segalanya lebih mudah karena kode yang lebih terstruktur lebih mudah untuk di-refactor. Tapi ini penghiburan yang begitu-begitu saja.
Pertanyaan dari surat
DPC ++ didasarkan pada SYCL. Tetapi bagaimana jika Anda masuk lebih dalam di balik tudung, apa perbedaan dari OpenCL dalam implementasi back end, jika ada. Misalnya, apakah mekanisme distribusi antara perangkat heterogen sama dengan OpenCL?
Jawabannya Jika Anda berada di bawah tenda, maka ini adalah OpenCL. Semua kelebihan dan kelebihan SYCL adalah kelebihan dan kelebihan dari bahasa tersebut, yaitu frontend. Dari ujung depan muncul SPIRV tua yang bagus yang pergi ke backend dan di sana dioptimalkan (sering sudah saat runtime, yaitu, JIT) sudah untuk kartu video tertentu dengan cara yang sama seperti OpenCL akan dioptimalkan untuk itu.
Hal lain adalah bahwa mekanisme untuk mendistribusikan pekerjaan antara perangkat heterogen hanya lebih front-end daripada back-end, karena itu adalah kode host yang memutuskan apa yang harus dikirim dan ke mana. Dan kode host diperoleh dari DPC ++. Saya telah menunjukkan contoh sedikit lebih tinggi bagaimana kompiler dapat, atas dasar accessors, membuat keputusan tentang paket paralel. Dan ini hanyalah puncak gunung es.
Pertanyaan dari surat
Perpustakaan Ya, kita tidak berbicara tentang CUDA. Tetapi kita tahu bahwa untuk pengembang CUDA ada perpustakaan yang sangat berguna yang bekerja dengan kinerja tinggi pada GPU. OneAPI juga berisi beberapa perpustakaan, tetapi, misalnya, IPP - tidak ada arsip yang berguna untuk bekerja dengan gambar di oneAPI / OpenCL. Akankah ada sesuatu, dan bagaimana dalam kasus ini untuk beralih dari CUDA ke oneAPI?
Jawabannya Transisi dari CUDA ke standar terbuka tunggal akan sulit, tetapi tidak terhindarkan. Tentu saja, CUDA sekarang memiliki infrastruktur yang lebih matang. Tetapi fitur-fitur dari perizinannya adalah hambatan pemblokiran, karena semakin banyak pemain muncul di pasar sistem heterogen, semakin banyak kartu dan akselerator yang menarik dari berbagai produsen.
Keragaman API yang ada membuat penggunaan dunia kemungkinan ini sulit bagi programmer dengan pengalaman CPU klasik. Yang mengarah ke OneAPI atau semacamnya. Di sini keajaiban tidak ada pada terobosan Intel dalam hal grafis, tetapi pada kenyataan bahwa Intel membuka pintu ke DPC ++ untuk semua orang. Kami bahkan tidak memiliki standar SYCL, itu milik grup Khronos dan semua ekstensi Intel adalah ekstensi di Khronos tempat siapa pun dapat melakukan (dan ada perwakilan dari semua pemain besar di sana). Dan itu berarti (perpustakaan) dan komunitas akan muncul (sudah muncul), dan banyak lowongan di arah ini.
Dan tentu saja, IPP akan ditulis ulang untuk realitas baru. Saya tidak ada hubungannya dengan IPP, tetapi menggunakan DPC ++ adalah akal sehat, dan orang waras duduk di sana.
Tetapi yang lebih penting, sekarang adalah saat dalam sejarah ketika Anda dapat menulis perpustakaan Anda sendiri, yang akan melampaui IPP dan yang kemudian akan digunakan oleh seluruh dunia. Karena standar terbuka selalu menang.
Pertanyaan dari surat
Jika kita membandingkan peluncuran pelatihan dan algoritma jaringan saraf inferensi pada Nervana dan FPGA - apa perbedaan dalam pemrograman dan efisiensi yang dihasilkan?
Jawabannya Saya tidak tahu apa-apa tentang detail pemrograman FPGA, saya menulis kompiler. Tapi saya punya pertanyaan balasan. Dan bagaimana kita akan membandingkan? Pada tolok ukur standar itu tidak sportif, Nervana menjilat di bawah mereka. Tetapi jika Anda memiliki sesuatu yang menarik, maka FPGA akan melepaskan tangan Anda, dan meletakkan sesuatu ini pada Nervana bisa lama, mahal, itu saja.
Ternyata pertanyaan itu sendiri, seolah-olah, dari seri “siapa yang lebih kuat dari gajah atau paus”. Tapi ini bukan pertanyaan nyata. Pertanyaan sebenarnya adalah: bagaimana cara memanfaatkan gajah dan paus dalam satu gerobak? Nah, atau setidaknya mendistribusikan, katakanlah, untuk seekor gajah menariknya melalui darat, dan seekor paus di laut.
Dalam kasus OneAPI, Anda akan memiliki program yang sama di, secara umum, standar C ++. Dan Anda dapat menulisnya sendiri dan menjalankannya dengan offload bolak-balik. Ini akan menjadi tugas yang sangat menarik bagi Anda, di mana Anda sendiri dapat mengukur dan mengoptimalkan kinerja. Standar tunggal dan antarmuka tunggal ke perangkat heterogen akan menjadi langkah menuju membandingkan apel dengan apel dalam hal-hal tersebut.
Misalnya: "apa yang lebih baik untuk% dari tugas saya% dari sudut pandang kemudahan pemrograman dan efisiensi - letakkan bagian ini di FPGA, tinggalkan bagian ini di Nervana atau pisahkan bagian ini menjadi dua, dan tulis ulang bagian ini untuk GPU?"
Dan keseluruhan cerita dengan OneAPI - hanya untuk Anda mengatakan, "mengapa memikirkannya untuk waktu yang lama, saya akan mencobanya sekarang dengan cepat, IT'S SIMPLE".
Belum, tidak mudah. Tetapi akan ada.
Kata penutup dari ahlinyaTerima kasih atas pertanyaan Anda. Mungkin dan bahkan mungkin saya salah, tidak akurat, dan membuat kesalahan. Itu terjadi, di internet terus-menerus seseorang salah.
Saya harap saya dapat menarik minat seseorang dalam pemrograman heterogen dan DPC ++. Saya ingin merekomendasikan semua orang situs
sycl.tech , tempat berton-
tonnya laporan, termasuk dari para pakar terkenal dunia (bahasa Inggris diperlukan)
Baik untuk semua!
PS dari penerbit. Kali ini, dengan keputusan bulat dari dewan editorial, diputuskan untuk memberikan hadiah untuk pertanyaan terbaik ... kepada penulis jawaban. Saya pikir Anda akan setuju bahwa ini adil.