Semua orang dapat berkontribusi pada OpenXLA, dan kami menghargai kontribusi semua orang. Ada beberapa cara untuk berkontribusi, termasuk:
Menjawab pertanyaan di forum diskusi OpenXLA (openxla-discuss)
Meningkatkan atau memperluas dokumentasi OpenXLA
Berkontribusi pada codebase OpenXLA
Berkontribusi dengan cara apa pun di atas ke ekosistem library yang lebih luas yang dibangun di OpenXLA
Project OpenXLA mengikuti Pedoman Komunitas Open Source Google.
Sebelum memulai
Menandatangani Perjanjian Lisensi Kontributor
Kontribusi untuk project ini harus disertai dengan Perjanjian Lisensi Kontributor (CLA). Anda (atau perusahaan Anda) tetap memiliki hak cipta atas kontribusi Anda; hal ini hanya memberi kami izin untuk menggunakan dan mendistribusikan ulang kontribusi Anda sebagai bagian dari project.
Jika Anda atau perusahaan tempat Anda bekerja saat ini telah menandatangani CLA Google (meskipun untuk project lain), Anda mungkin tidak perlu melakukannya lagi.
Buka <https://cla.developers.google.com/> untuk melihat perjanjian Anda saat ini atau menandatangani perjanjian baru.
Meninjau Kode Etik
Project ini mengikuti Kode Etik Tensorflow.
Proses kontribusi
Panduan Developer
Untuk panduan tentang cara menyiapkan lingkungan pengembangan untuk OpenXLA, termasuk cara mendapatkan kode, membangunnya, menjalankan pengujian, dan mengirimkan perubahan, lihat Panduan developer.
Panduan kontribusi
Arsitektur compiler terdiri dari komponen berikut.
Penerusan pengoptimalan
Pengoptimalan meneruskan eksekusi transformasi pada HLO untuk meningkatkan efisiensi komputasi. Transformasi ini mencakup peningkatan tingkat tinggi yang tidak bergantung pada arsitektur hingga penyesuaian khusus hardware (misalnya, untuk GPU NVIDIA).
Yang biasanya kami terima:
- Penerusan yang digeneralisasi di beberapa beban kerja dan menunjukkan dampak positif yang jelas dan signifikan pada tolok ukur performa.
Yang umumnya kami tolak:
- Penerusan yang melakukan pengoptimalan unik yang menargetkan model tertentu.
Kartu gabungan
Penggabungan adalah pengoptimalan penting yang menggabungkan beberapa operasi HLO menjadi satu kernel untuk mengurangi I/O memori dan overhead peluncuran kernel.
Semua kartu gabungan harus ditambahkan ke pipeline gabungan saja, bukan sebelum atau sesudahnya. Artinya juga bahwa modul HLO yang telah dioptimalkan sebelumnya tidak boleh berisi petunjuk penggabungan. Jika penggabungan dilakukan di awal pipeline, penggabungan tersebut akan menjadi hambatan untuk proses pengoptimalan. Jika fusi terbentuk terlambat, kita akan kehilangan kemampuan untuk memilih dan menyesuaikan backend untuk fusi yang dihasilkan.
Penggabungan ke panggilan kustom, yaitu panggilan kustom pencocokan pola dengan produsen/konsumen dan penulisan ulang ke panggilan kustom baru tidak diizinkan. Dalam hal ini, harus diganti dengan kartu fusi yang tepat.
Penskalaan horizontal
Kontribusi pada penskalaan horizontal mencakup pengoptimalan HLO, peningkatan model biaya, pembaruan pustaka, dan berbagai modifikasi infrastruktur. Karena sulitnya mereproduksi peningkatan performa dan terbatasnya kebutuhan akan konfigurasi multi-host secara internal, kami mematuhi kriteria penerimaan yang ketat:
Kami memprioritaskan perubahan yang tidak terlalu invasif dan memiliki risiko rendah.
Yang biasanya kami terima:
Update pada library yang menangani komunikasi antar-GPU atau antar-host.
Pembaruan tabel performa untuk platform baru.
Yang umumnya kami tolak:
Penulisan ulang HLO atau perubahan runtime yang disesuaikan dengan model tertentu.
Perubahan infrastruktur yang memperkenalkan flag baru, utang teknis, atau regresi.
Backend & Penyetelan Otomatis
Backend untuk operasi yang tidak bertingkat, misalnya panggilan dan penggabungan kustom, harus menerapkan antarmuka CodegenBackend.
Antarmuka ini diperlukan untuk mengaktifkan pemilihan backend yang optimal, karena menyediakan metode untuk menyertakan parameter untuk petunjuk HLO tertentu ke dalam ruang penelusuran autotuner.
// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
GetSupportedConfigs(const HloInstruction& instr);
// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
const HloInstruction& instr);
Runtime
Hasil akhir pipeline kompilasi XLA adalah urutan thunk yang dapat diserialisasi.
Semua jenis thunk baru harus dapat diserialisasi, yaitu GpuCompiler atau
CpuCompiler harus dapat mengompilasi program, menyerialisasinya, sehingga nantinya
peluncur XLA dapat memuat dan menjalankan program. Artinya, tidak boleh ada pointer ke HloInstruction atau ke bagian lain dari compiler atau StreamExecutor.
Standar kode
Gaya coding: Kami mengikuti panduan gaya kode Google. Lihat secara khusus panduan C/C++ dan Python. Semua kode yang dikirimkan harus benar-benar sesuai dengan panduan gaya ini.
Perubahan ringkas: Kami mengikuti praktik engineering Google. Secara khusus, harap perhatikan panduan tentang cara menulis perubahan ringkas. Dengan melakukannya, kecepatan penggabungan kode Anda akan meningkat secara signifikan karena peningkatan kemudahan peninjauan, dan mengurangi kemungkinan efek samping perubahan yang tidak disengaja. Meskipun Anda memiliki perubahan besar, ada banyak strategi untuk memecahnya menjadi perubahan yang lebih inkremental.
Cakupan Pengujian: Semua perubahan harus menyertakan pengujian unit yang sesuai. Pengujian unit tidak boleh bergantung pada pengaturan waktu hardware tertentu (CPU, GPU, dll.), dan harus menggunakan tiruan dan palsu secara bebas untuk membuat pengujian yang deterministik dan terfokus. Perubahan yang berupaya memperluas kode yang ada yang saat ini sulit diuji harus melakukan peningkatan yang sesuai pada kemampuan pengujian.
Semua perubahan harus menyertakan hasil tolok ukur yang sesuai serta judul perubahan untuk memastikan manfaatnya dipahami dengan jelas.
Jika Anda ragu mengenai konvensi dalam kode, sebaiknya periksa kode yang sudah ada dan coba ikuti pola yang sudah ada di OpenXLA.
Proses Peninjauan
Semua kiriman, termasuk kiriman oleh anggota project, memerlukan peninjauan. Kami menggunakan permintaan pull GitHub untuk tujuan ini. Lihat Bantuan GitHub untuk mengetahui informasi selengkapnya tentang cara menggunakan permintaan pull.
Kode harus mengikuti semua standar yang tercantum di atas sebelum ditinjau. Hal ini tidak bersifat opsional dan pengirim harus memastikan bahwa kode mereka sesuai sebelum meminta peninjauan untuk memastikan perubahan diterima tepat waktu.
Semua pengujian harus lulus. Jika Anda menemukan bahwa pengujian rusak dan masalahnya tidak terkait dengan lingkungan build atau perubahan Anda, hubungi pengelola.
Coba hindari perubahan cakupan selama proses peninjauan. Hal ini menjadi tanggung jawab pengirim dan peninjau. Jika perubahan mulai terlalu besar, pertimbangkan untuk membaginya menjadi beberapa perubahan.
Sebelum perubahan digabungkan, perubahan tersebut akan menjalani pengujian internal yang menggunakan kode internal Google dan vendor hardware lainnya. Hal ini berpotensi menambah langkah-langkah tambahan dalam proses peninjauan jika ada kegagalan pada pengujian internal yang tidak terdeteksi oleh CI publik kami. Karyawan Google yang meninjau perubahan Anda akan mengomunikasikan kegagalan pengujian internal dan menjelaskan hal yang perlu diperbaiki.
Pertanyaan umum (FAQ)
"Perubahan infrastruktur ini tidak terkait dengan PR saya. Mengapa saya harus melakukannya?"
Tim XLA tidak memiliki tim infrastruktur khusus, jadi kami semua harus membangun library pembantu dan menghindari utang teknis. Kami menganggapnya sebagai bagian rutin dalam melakukan perubahan pada XLA, dan semua orang diharapkan berpartisipasi. Kita biasanya membangun infrastruktur sesuai kebutuhan saat menulis kode.
Peninjau XLA dapat meminta Anda untuk membangun beberapa infrastruktur (atau membuat perubahan besar pada PR) bersama dengan PR yang telah Anda tulis. Permintaan ini mungkin tampak tidak perlu atau tidak terkait dengan perubahan yang ingin Anda lakukan. Hal ini kemungkinan disebabkan oleh ketidakcocokan antara ekspektasi Anda tentang jumlah infrastruktur yang Anda butuhkan untuk membangun dan ekspektasi peninjau Anda untuk hal yang sama.
Perbedaan ekspektasi tidak masalah. Hal ini wajar terjadi saat Anda baru menggunakan project (dan terkadang bahkan terjadi pada kami yang sudah lama). Kemungkinan besar proyek yang pernah Anda kerjakan di masa lalu memiliki ekspektasi yang berbeda. Itu juga tidak masalah dan diharapkan. Hal ini tidak berarti salah satu dari project ini memiliki pendekatan yang salah, tetapi hanya berbeda. Kami mengundang Anda untuk menganggap permintaan infrastruktur bersama semua komentar ulasan lainnya sebagai kesempatan untuk mempelajari apa yang kami harapkan dalam proyek ini.
"Dapatkah saya membahas komentar Anda dalam PR mendatang?"
Pertanyaan yang sering diajukan terkait permintaan infrastruktur (atau permintaan besar lainnya) dalam PR adalah apakah perubahan harus dilakukan dalam PR asli, atau apakah dapat dilakukan sebagai tindak lanjut dalam PR mendatang.
Secara umum, XLA tidak mengizinkan penulis PR menanggapi komentar peninjauan dengan PR lanjutan. Jika peninjau memutuskan bahwa ada sesuatu yang perlu ditangani dalam PR tertentu, kami biasanya mengharapkan penulis untuk menanganinya dalam PR tersebut, meskipun perubahan yang diminta adalah perubahan besar. Standar ini berlaku secara eksternal dan juga secara internal dalam Google.
Ada beberapa alasan mengapa XLA mengambil pendekatan ini.
Kepercayaan: Mendapatkan kepercayaan pengulas adalah komponen utama. Dalam project open source, kontributor dapat muncul atau menghilang sesuka hati. Setelah kami menyetujui PR, peninjau tidak dapat memastikan bahwa tindak lanjut yang dijanjikan benar-benar dilakukan.
Dampak pada developer lain: Jika Anda telah mengirimkan PR yang menyentuh bagian tertentu dari XLA, ada kemungkinan orang lain sedang melihat bagian yang sama. Jika kami menerima utang teknis dalam PR Anda, semua orang yang melihat file ini akan terpengaruh oleh utang ini hingga tindak lanjutnya dikirimkan.
Kapasitas peninjau: Menunda perubahan ke tindak lanjut akan menimbulkan beberapa biaya bagi peninjau kami yang sudah kelebihan beban. Peninjau mungkin akan lupa apa yang dibahas di PR pertama saat menunggu tindak lanjutnya, sehingga membuat peninjauan berikutnya menjadi lebih sulit. Selain itu, peninjau harus melacak tindak lanjut yang diharapkan, memastikan bahwa tindak lanjut tersebut benar-benar dilakukan. Jika perubahan dapat dilakukan sehingga benar-benar ortogonal dengan PR asli agar peninjau lain dapat meninjaunya, bandwidth tidak akan menjadi masalah. Berdasarkan pengalaman kami, hal ini jarang terjadi.