Wawancara: Janji Intel oneAPI dan Direct Parallel C++

Intel bukanlah nama pertama yang muncul di benak Anda saat memikirkan pengembangan perangkat lunak, meskipun itu adalah salah satu perusahaan teknologi paling berpengaruh dan inovatif di planet ini. Empat dekade lalu, prosesor Intel 8088 membantu meluncurkan revolusi PC, dan jika Anda membaca ini di desktop atau laptop, kemungkinan Anda memiliki Intel Inside. Hal yang sama berlaku untuk server dan berbagai perangkat keras lain yang kami andalkan setiap hari. Bukan berarti AMD dan vendor lain tidak memiliki produk kompetitif karena mereka memilikinya, tetapi Intel masih mendominasi pasar CPU x86.

Insinyur perangkat lunak telah menggunakan platform perangkat keras Intel selama beberapa dekade, biasanya tanpa mempertimbangkan perangkat lunak dan firmware di belakangnya. Jika mereka membutuhkan lebih banyak kinerja virtualisasi, mereka memilih produk multicore, Core i7 hyperthreaded, atau Xeon. Untuk mengutak-atik database lokal, mereka bisa mendapatkan Intel SSD. Tapi sekarang, Intel ingin pengembang mulai menggunakan lebih banyak perangkat lunaknya juga.

Apa itu Intel oneAPI?

Masukkan oneAPI, yang disebut-sebut oleh Intel sebagai model pemrograman terpadu tunggal yang bertujuan untuk menyederhanakan pengembangan di berbagai arsitektur perangkat keras: CPU, GPU, FPGA, akselerator AI, dan banyak lagi. Semuanya memiliki sifat yang sangat berbeda dan unggul dalam berbagai jenis operasi.

Intel sekarang berkomitmen pada strategi "pertama-perangkat lunak" dan mengharapkan pengembang untuk memperhatikannya. Ide besar di balik oneAPI adalah untuk memungkinkan penggunaan satu platform untuk berbagai perangkat keras yang berbeda, sehingga pengembang tidak perlu menggunakan bahasa, alat, dan pustaka yang berbeda ketika mereka membuat kode untuk CPU dan GPU, misalnya. Dengan oneAPI, kotak alat dan basis kode akan sama untuk keduanya.

Untuk memungkinkan hal ini, Intel mengembangkan Data Parallel C++ (DPC++) sebagai alternatif sumber terbuka untuk bahasa berpemilik yang biasanya digunakan untuk memprogram perangkat keras tertentu (misalnya, GPU atau FFPGA). Bahasa pemrograman baru ini seharusnya memberikan produktivitas dan keakraban C++ sambil menyertakan kompiler untuk digunakan di berbagai target perangkat keras.

Data Parallel C++ juga menggabungkan SYCL Khronos Group untuk mendukung paralelisme data dan pemrograman heterogen. Intel saat ini menawarkan akses gratis ke DevCloud-nya, memungkinkan para insinyur perangkat lunak untuk mencoba alat mereka dan mengotak-atik oneAPI dan DPC++ di cloud tanpa banyak kesulitan.

Tapi tunggu dulu, apakah itu akan bekerja pada perangkat keras yang dibuat oleh vendor lain? Bagaimana dengan perizinan, apakah gratis? Ya dan ya: oneAPI dirancang untuk menjadi agnostik perangkat keras dan sumber terbuka, dan itu tidak akan berubah.

Untuk mempelajari lebih lanjut tentang oneAPI, kami membahas asal-usul dan masa depannya dengan Sanjiv M. Shah, Wakil Presiden Grup Arsitektur, Grafik dan Perangkat Lunak Intel dan manajer umum Teknis, Perusahaan, dan Komputasi Awan di Intel.

Sanjiv: Dalam hal apa yang ada di oneAPI, saya menganggapnya sebagai empat bagian. Salah satunya adalah bahasa dan perpustakaan standar, yang kedua adalah seperangkat alat pembelajaran mendalam, yang ketiga benar-benar lapisan abstraksi perangkat keras dan lapisan driver perangkat lunak yang dapat mengabstraksi akselerator yang berbeda, dan bagian keempat adalah seperangkat perpustakaan yang berfokus pada domain. , seperti Matlab dan sebagainya. Itu adalah empat kategori hal dalam oneAPI, tetapi kita bisa masuk lebih dalam dan berbicara tentang sembilan elemen oneAPI. Sembilan elemen tersebut pada dasarnya adalah bahasa baru yang kami perkenalkan yang disebut Data Parallel C++ dan pustaka standarnya.

Ada dua perpustakaan pembelajaran, satu untuk jaringan saraf dan satu untuk komunikasi. Ada perpustakaan yang kami sebut level nol untuk abstraksi perangkat keras, dan ada empat perpustakaan yang berfokus pada domain. Kami melakukan ini dengan cara yang sangat, sangat terbuka. Spesifikasi untuk semua ini sudah terbuka dan tersedia. Kami menyebutnya versi 0.5. Kami bermaksud untuk mendorong ke 1.0 pada akhir tahun 2020, dan kami juga memiliki implementasi open-source dari semua ini. Sekali lagi, tujuan kami adalah memungkinkan orang untuk memanfaatkan apa yang sudah ada di luar sana. Jika vendor perangkat keras ingin mengimplementasikan bahasa ini, mereka dapat mengambil apa yang bersumber terbuka dan menjalankannya.

T: Mengenai algoritme dan implementasinya, bagaimana cara kerjanya?

Apa yang kami sediakan adalah primitif yang akan digunakan oleh algoritme: primitif matematika dan komunikasi primitif yang mendasarinya. Biasanya, inovasi algoritme terjadi pada tingkat yang lebih tinggi dari itu, di mana mereka tidak benar-benar mengulang matematika dasar, matematika matriks, matematika konvolusi, dan sebagainya. Ini tentang mencari cara baru untuk menggunakan matematika itu dan cara baru untuk menggunakan pola komunikasi. Tujuan kami sebenarnya adalah agar kami memberikan yang primitif, level nol, sehingga orang lain dapat berinovasi di atasnya.

T: Bagaimana cara kerjanya pada tingkat perangkat keras?

Jika Anda adalah penyedia perangkat keras, mari kita ambil matriks AI, seseorang yang membangun ASIC AI, misalnya—ada dua cara bagi vendor perangkat keras itu untuk "memasang" dan memanfaatkan ekosistem AI. Salah satunya adalah menyediakan antarmuka perangkat keras tingkat rendah yang kami sebut level nol, dan jika mereka menyediakan versi level nol mereka menggunakan API standar, mereka dapat memanfaatkan sumber terbuka jika mereka mau, dan kemudian semua lapisan perangkat lunak di atas dapat secara otomatis memanfaatkan itu.

Itu mungkin sulit bagi ASIC yang berfokus pada segmen, untuk memberikan generalitas penuh level nol. Jadi, sebagai alternatif untuk itu, mereka juga dapat menyediakan kernel matematika dan kernel komunikasi yang ada di domain dan perpustakaan pembelajaran mendalam kami, dan kemudian kami akan melakukan pekerjaan "memasang" perpustakaan tersebut ke kerangka kerja tingkat yang lebih tinggi, jadi mereka akan mendapatkannya secara otomatis.

T: Anda menyebutkan bahwa versi yang Anda miliki saat ini adalah 0,5, dan spesifikasi lengkapnya akan siap pada akhir tahun 2020.

Jadi, ada dua bagian dari inisiatif oneAPI kami. Salah satunya adalah bagian industri, dan satu lagi adalah produk Intel. Spesifikasi industri adalah 0,5, dan sekitar pertengahan tahun, kami ingin membuatnya menjadi 1,0. Sejalan dengan itu, Intel sedang membangun serangkaian produk, dan produk yang sedang dibuat Intel saat ini dalam versi beta dan mereka menerapkan spesifikasi 0,5. Pada akhir tahun, kami ingin mendapatkan produk 1.0.

Produk Intel melampaui sembilan elemen oneAPI karena, selain elemen pemrograman dasar yang kami sediakan, kami juga ingin menyediakan hal-hal yang benar-benar dibutuhkan programmer, seperti debugger, penganalisis, dan alat kompatibilitas sehingga mereka bermigrasi dari bahasa yang ada ke dalam Data Bahasa C++ paralel.

T: Seberapa sulit bagi pengembang untuk melakukan transisi? Apakah lingkungan yang lebih luas mirip dengan apa yang telah mereka gunakan selama bertahun-tahun?

Ya, sangat mirip. Mari saya jelaskan Data Parallel C++ sedikit karena itu adalah bagian besar dari apa yang kita lakukan. DPC++ adalah tiga hal. Itu dibangun di atas bahasa C++ standar internasional ISO. Ada grup bernama Khronos yang mendefinisikan standar yang disebut SYCL, dan SYCL berlapis di atas C++. Kami mengambil SYCL, dan kemudian kami menambahkan ekstensi di atas SYCL. Cara kami membangun Data Paralel C++, sebenarnya hanya C++ dengan ekstensi di atasnya, yang merupakan SYCL.

Kompiler C++ mana pun dapat mengompilasinya. Keindahan DPC++ adalah bahwa kompiler mana pun dapat mengompilasinya, hanya kompiler yang berpengetahuan luas yang dapat memanfaatkan apa yang ada dalam bahasa itu dan menghasilkan kode akselerator. Cara kami melakukan bahasa ini, kami melakukannya dengan sangat, sangat terbuka, jadi semua diskusi kami tentang Data Paralel C++ dilakukan dengan komite SYCL. Implementasinya adalah open-source, semua ekstensi sudah diterbitkan, dan kami bekerja dengan sangat, sangat hati-hati untuk memastikan bahwa kami memiliki jalur luncur yang bagus ke dalam standar SYCL di masa mendatang. Melihat ke bawah pada 5-10 tahun dari sekarang, sebuah glidepath ke ISO C++ juga.

T: Mengenai compiler dan migrasi ke DPC++, kurva pembelajaran seharusnya tidak menjadi masalah?

Ya, itu tergantung dari mana Anda memulai, tentu saja. Untuk programmer C++, kurva belajar akan sangat kecil. Untuk programmer C, Anda harus mengatasi rintangan belajar C++, tapi itu saja. Ini sangat akrab dengan C++. Untuk programmer yang terbiasa dengan bahasa seperti OpenCL, seharusnya sangat mirip.

Bagian lain yang harus saya tekankan adalah bahwa kami melakukan pekerjaan di sumber terbuka menggunakan infrastruktur LLVM. Semua sumber kami sudah terbuka, ada repositori Intel GitHub di mana Anda dapat pergi dan melihat implementasi bahasa, bahkan mengunduh kompiler open-source. Semua alat Intel, penawaran produk kami yang beta juga tersedia gratis untuk dimainkan dan diunduh oleh siapa saja. Kami juga memiliki cloud pengembang yang tersedia, di mana orang tidak perlu mengunduh atau menginstal apa pun, mereka cukup menulis kode dan mulai menggunakan semua alat yang kita bicarakan.

T: C++ berkinerja baik dan relatif sederhana, tetapi kita semua tahu bahwa C++ semakin tua, pengembangannya lambat, terlalu banyak pemangku kepentingan, sehingga memperlambat segalanya. Ini jelas tidak akan terjadi dengan DPC++. Anda akan memiliki iterasi dan pembaruan yang jauh lebih cepat?

Saya pikir Anda telah mencapai titik yang sangat, sangat penting bagi kami, yaitu evolusi cepat yang tidak diperlambat oleh standar. Jadi, kami ingin melakukan diskusi kami secara terbuka dengan standar, jadi ada cara untuk masuk ke standar, tetapi kami juga ingin melakukannya dengan cepat.

Bahasa berfungsi paling baik saat dirancang bersama oleh pengguna dan pelaksananya, seiring dengan perkembangan arsitektur. Tujuan kami adalah desain kode iteratif yang sangat cepat di mana kami mempraktikkan berbagai hal, menemukan cara terbaik untuk melakukan sesuatu, dan menjadikannya standar. Jadi, tentu saja, iterasi cepat adalah tujuan besar.

T: Satu pertanyaan yang diajukan oleh beberapa rekan saya (Anda mungkin dapat memahami bahwa mereka agak khawatir tentang keterbukaan dengan apa pun yang datang dari perusahaan besar): Apakah DPC++ akan selalu terbuka untuk semua pengguna dan vendor?

Sangat! Spesifikasi dilakukan dengan lisensi creative commons. Siapa saja dapat menggunakan spesifikasi, mengambilnya dan memotongnya jika mereka mau, dan mengembangkannya. Saya ingin menekankan bahwa tidak semua elemen oneAPI adalah open-source, tetapi kami berada di jalur untuk membuat hampir semua elemen open-source. Semua itu, siapa pun dapat mengambil dan memanfaatkan - ini tersedia untuk implementasi.

Codeplay, yang merupakan perusahaan di luar Inggris, mengumumkan implementasi Nvidia dari DPC++, dan kami sangat mendorong semua vendor perangkat keras dan vendor perangkat lunak untuk melakukan port mereka. Kami berada pada titik unik dalam industri di mana akselerator menjadi umum bagi banyak vendor. Ketika itu terjadi dalam sejarah, ketika hanya ada satu penyedia, bahasa mereka mendominasi. Industri perangkat lunak menuntut solusi standar dan banyak penyedia.

Apa yang kami coba lakukan di sini adalah apa yang kami lakukan sekitar dua setengah dekade yang lalu dengan OpenMP, di mana ada beberapa bahasa paralel tetapi tidak ada satu pun yang benar-benar dominan. Kami mengambil semua itu dan menyatukannya menjadi standar yang sekarang, 25 tahun kemudian, adalah cara untuk memprogram HPC.

T: Apakah benar untuk mengatakan bahwa DPC++ akan melihat banyak evolusi selama beberapa tahun ke depan? Bagaimana dengan tensor, bagaimana dengan perangkat keras baru yang keluar?

Ya, tentu saja, Anda benar. Kami harus mengembangkan bahasa untuk mendukung perangkat keras baru yang akan keluar. Itu adalah tujuan dari iterasi yang lebih cepat. Hal lain yang ingin saya tekankan adalah bahwa kami sedang merancang Data Paralel C++ sehingga Anda juga dapat memasang ekstensi khusus arsitektur jika Anda mau.

Jadi, meskipun ini adalah bahasa standar yang ingin kami jalankan di berbagai arsitektur, kami juga menyadari bahwa terkadang, audiens, audiens yang sangat penting membutuhkan kinerja maksimal. Mereka mungkin ingin terjun ke pemrograman tingkat sangat rendah yang belum tentu arsitektur-portabel. Kami sedang membangun ekstensi dan mekanisme sehingga Anda dapat memiliki ekstensi untuk tensor dan sebagainya yang spesifik untuk arsitektur.

T: Seberapa besar kendali atas kode yang dihasilkan untuk perangkat keras yang dapat dimiliki pengembang? Seberapa besar kendali yang mereka miliki atas manajemen memori antara sistem dan berbagai akselerator?

Kami meminjam konsep buffer dari SYCL, yang memberikan kontrol memori yang sangat eksplisit kepada pengguna, tetapi selain itu, kami juga menambahkan gagasan memori terpadu . Tujuan kami adalah untuk memungkinkan programmer tingkat kontrol yang mereka butuhkan, tidak hanya untuk mengelola memori tetapi untuk menghasilkan kode cepat. Beberapa ekstensi yang kami tambahkan melalui SYCL adalah hal-hal seperti subgrup, reduksi, pipa, dan sebagainya. Itu akan memungkinkan Anda menghasilkan kode yang jauh lebih baik untuk arsitektur yang berbeda.

T: Poin yang menarik adalah distribusi oneAPI untuk Python—Intel secara khusus mencantumkan NumPy, SciPy, SciKit Learn. Saya ingin tahu tentang peningkatan kinerja dan manfaat produktivitas yang dapat dibuka melalui oneAPI. Apakah Anda memiliki metrik tentang itu?

Itu pertanyaan yang bagus. Kami mendukung ekosistem itu. Mengapa Python ingin menggunakan akselerator? Ini untuk mendapatkan kinerja dari perpustakaan matematikanya, perpustakaan analitiknya. Apa yang kami lakukan adalah "memasang pipa" NumPy, SciPy, SciKit Learn, dll., sehingga kami bisa mendapatkan kinerja yang baik dengan memanfaatkan perpustakaan yang kami miliki di atasnya. Implementasi default dari NumPy, SciPy, SciKit Learn, dan seterusnya, dibandingkan dengan implementasi yang disematkan dengan benar dengan paket asli yang dioptimalkan, dapat melihat keuntungan yang sangat, sangat besar. Kami telah melihat keuntungan pada urutan 200x, 300x, dll.

Tujuan kami dengan Python adalah kami ingin mendapatkan bagian yang masuk akal, dalam 2x, mungkin dalam 80 persen dari kinerja kode asli. Keadaan seni saat ini adalah bahwa Anda sering berada di 10x atau lebih. Kami ingin benar-benar menjembatani kesenjangan itu dengan menyalurkan semua tugas berkinerja tinggi sehingga Anda berada dalam faktor 2, dan sebenarnya jauh lebih tinggi dari itu.

T: Jenis perangkat keras apa yang sedang kita bicarakan? Bisakah pengembang membuka potensi ini pada workstation biasa, atau apakah itu memerlukan sesuatu yang sedikit lebih kuat?

Tidak, itu akan ada di mana-mana. Jika Anda memikirkan dari mana keuntungan itu berasal, maka Anda akan mengerti. Pustaka Python normal tidak menggunakan kemampuan virtualisasi apa pun pada CPU. Mereka tidak menggunakan kemampuan multi-core pada CPU. Mereka tidak dioptimalkan, sistem memori dan semua yang tidak dioptimalkan. Jadi, ini bermuara pada perkalian matriks yang ditulis oleh programmer yang naif dan dikompilasi oleh kompiler tanpa optimasi apa pun, dan kemudian membandingkannya dengan apa yang ditulis oleh seorang ahli dalam kode assembly. Anda dapat melihat keuntungan multi-100x saat Anda membandingkan keduanya, dan di dunia Python, pada dasarnya, itulah yang terjadi.

Penerjemah Python dan pustaka standar sangat tinggi sehingga kode yang Anda dapatkan menjadi kode yang sangat, sangat naif. Saat Anda menyelaminya dengan benar dengan perpustakaan yang dioptimalkan, Anda mendapatkan keuntungan besar itu. Sebuah laptop sudah memiliki dua sampai enam atau delapan inti CPU, mereka multithreaded dan memiliki kemampuan vektorisasi yang cukup baik di dalamnya, mungkin 256, mungkin 512. Jadi, ada banyak kinerja duduk di laptop dan workstation. Saat Anda meningkatkannya ke GPU, setelah Anda memiliki grafik yang tersedia, Anda dapat membayangkan dari mana keuntungannya berasal.

Jika Anda melihat grafik terintegrasi kami, mereka juga menjadi sangat kuat. Saya yakin Anda telah melihat Ice Lake Gen 11, di mana grafis terintegrasi secara signifikan lebih baik daripada generasi sebelumnya. Anda dapat melihat dari mana manfaatnya, bahkan di laptop.

T: Bagaimana dengan ketersediaan DevCloud? Jika saya mengingatnya dengan benar, ini gratis untuk digunakan semua orang saat ini, tetapi apakah akan tetap seperti itu setelah Anda meraih emas tahun depan?

Itu pertanyaan yang bagus. Pada titik ini, saya akan jujur, saya tidak tahu jawabannya. Niat kami pada saat ini adalah untuk bebas selamanya. Ini untuk pengembangan, untuk bermain-main, dan ada banyak tenaga kuda di sana, sehingga orang benar-benar dapat berlari.

T: Jadi, Anda tidak keberatan jika kami meminta beberapa ribu pengembang untuk mencobanya?

Oh, sama sekali tidak. Kami akan senang jika itu terjadi!

Saya dapat meringkas apa yang kami coba lakukan. Pertama, kami sangat, sangat senang dengan oneAPI. Saatnya solusi multi-vendor lepas landas, karena ada banyak vendor yang tersedia di pasar sekarang. Jika Anda melihat lini prosesor kami, bukan hanya GPU yang akan datang, GPU terintegrasi yang semakin kuat, dan peta jalan FPGA kami, ini adalah waktu yang menyenangkan untuk membangun standar untuk semua itu. Sasaran kami adalah produktivitas, kinerja, dan infrastruktur industri sehingga Anda dapat membangunnya.

Adapun tiga audiens yang saya bicarakan, pengembang aplikasi dapat memanfaatkan berbagai hal dengan mudah, karena sudah tersedia. Vendor perangkat keras dapat memanfaatkan tumpukan perangkat lunak dan memasang perangkat keras baru, sementara vendor alat dan bahasa dapat dengan mudah menggunakannya. Intel tidak dapat membangun semua bahasa dan semua alat di dunia, jadi ini adalah infrastruktur sumber terbuka yang dapat dimanfaatkan dan dibangun oleh orang lain dengan sangat mudah.