Herkes OpenXLA'ya katkıda bulunabilir ve herkesin katkılarını değerli buluruz. Katkıda bulunmanın çeşitli yolları vardır. Örneğin:
OpenXLA'nın tartışma forumlarındaki (openxla-discuss) soruları yanıtlama
OpenXLA'nın dokümanlarını iyileştirme veya genişletme
OpenXLA'nın kod tabanına katkıda bulunma
OpenXLA üzerinde oluşturulan daha geniş kitaplık ekosistemine yukarıdaki yöntemlerden herhangi biriyle katkıda bulunmak
OpenXLA projesi, Google'ın Açık Kaynak Topluluğu Kuralları'na uyar.
Başlamadan önce
Katkıda Bulunan Lisans Sözleşmesi'ni imzalayın
Bu projeye yapılan katkılarla birlikte Katkıda Bulunan Lisans Sözleşmesi (CLA) gönderilmelidir. Katkınızın telif hakkı sizde (veya işvereninizde) kalır. Bu lisans yalnızca katkılarınızı proje kapsamında kullanmamıza ve yeniden dağıtmamıza izin verir.
Siz veya mevcut işvereniniz Google CLA'yı daha önce imzaladıysanız (farklı bir proje için olsa bile) muhtemelen tekrar imzalamanız gerekmez.
Mevcut sözleşmelerinizi görmek veya yeni bir sözleşme imzalamak için <https://cla.developers.google.com/> adresini ziyaret edin.
Davranış Kuralları'nı inceleyin.
Bu proje, Tensorflow'un Davranış Kuralları'na uygundur.
Katkı süreci
Geliştirici Kılavuzu
OpenXLA için geliştirme ortamının nasıl kurulacağıyla ilgili kılavuz (kod alma, derleme, test çalıştırma ve değişiklik gönderme dahil) için lütfen Geliştirici kılavuzu'na bakın.
Katkı kılavuzu
Derleyicinin mimarisi aşağıdaki bileşenlerden oluşur.
Optimizasyon geçişleri
Optimizasyon geçişleri, hesaplama verimliliğini artırmak için HLO'da dönüşümler gerçekleştirir. Bu dönüşümler, mimariden bağımsız, üst düzey iyileştirmelerden donanıma özel ayarlamalara (ör. NVIDIA GPU'lar için) kadar uzanır.
Genellikle kabul ettiğimiz içerikler:
- Birden fazla iş yükünde genelleştirilen ve performans karşılaştırmaları üzerinde net ve önemli bir olumlu etki gösteren geçişler.
Genellikle reddettiklerimiz:
- Belirli modelleri hedefleyen benzersiz optimizasyonlar gerçekleştiren geçişler.
Karma kartlar
Birleştirme, bellek G/Ç'sini ve çekirdek başlatma ek yükünü azaltmak için birden fazla HLO işlemini tek bir çekirdekte birleştiren kritik bir optimizasyondur.
Tüm birleştirme geçişleri, birleştirme işlem hattına yalnızca işlem sırasında eklenmelidir. Bu, önceden optimize edilmiş HLO modülünün birleştirme talimatları içermemesi gerektiği anlamına da gelir. Birleştirme, işlem hattının başlarında oluşturulursa optimizasyon geçişleri için engel teşkil eder. Birleştirme geç oluşturulursa oluşturulan birleştirme için arka ucu seçme ve ayarlama olanağını kaybederiz.
Özel çağrılarla birleştirme (ör. üreticiler/tüketicilerle özel çağrıları kalıpla eşleştirme ve bunları yeni özel çağrılar olarak yeniden yazma) işlemine izin verilmez. Bu durumda, uygun bir birleştirme geçişiyle değiştirilmesi gerekir.
Yatay ölçeklendirme
Yatay ölçeklendirmeye katkılar arasında HLO optimizasyonları, maliyet modeli iyileştirmeleri, kitaplık güncellemeleri ve çeşitli altyapı değişiklikleri yer alır. Performans artışlarını yeniden üretmenin zorluğu ve şirket içinde çoklu ana makine yapılandırmalarına duyulan sınırlı ihtiyaç nedeniyle katı kabul ölçütlerine uyuyoruz:
Önceliğimiz, düşük risk taşıyan ve mümkün olduğunca az müdahale gerektiren değişikliklerdir.
Genellikle kabul ettiğimiz içerikler:
GPU'lar arası veya ana bilgisayarlar arası iletişimi işleyen kitaplıklarda güncellemeler.
Yeni platformlar için performans tablosu güncellemeleri.
Genellikle reddettiklerimiz:
Belirli bir modele göre uyarlanmış HLO yeniden yazma işlemleri veya çalışma zamanı değişiklikleri.
Yeni işaretler, teknik borç veya gerilemeler getiren altyapı değişiklikleri.
Arka uçlar ve otomatik ayarlama
İç içe yerleştirilmemiş işlemlerin (ör. özel çağrılar ve birleştirmeler) arka uçları, CodegenBackend arayüzünü uygulamalıdır.
Bu arayüz, verilen HLO talimatlarının parametrelerini otomatik ayarlayıcının arama alanına dahil etme yöntemlerini sağladığı için optimum arka uç seçimini etkinleştirmek için gereklidir.
// 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);
Çalışma zamanı
XLA derleme işlem hattının nihai sonucu, serileştirilebilen bir thunk dizisidir.
Yeni thunk türlerinin tümü serileştirilebilir olmalıdır.Yani GpuCompiler veya CpuCompiler, programı derleyip serileştirebilmelidir. Böylece XLA çalıştırıcısı daha sonra programı yükleyip çalıştırabilir. Bu nedenle, HloInstruction veya derleyicinin ya da StreamExecutor'nin diğer bölümlerine yönelik işaretçiler olmamalıdır.
Kod standartları
Kodlama stili: Google'ın kod stili kılavuzuna uyarız. Özellikle C/C++ ve Python kılavuzlarına bakın. Gönderilen tüm kodlar bu stil kılavuzlarına kesinlikle uygun olmalıdır.
Küçük değişiklikler: Google'ın mühendislik uygulamalarına uyarız. Özellikle kısa değişiklikler yazma kılavuzuna uymanızı rica ederiz. Bu sayede, incelenebilirlik iyileştirileceğinden kodunuzun birleştirilme hızı büyük ölçüde artar ve değişikliklerin istenmeyen yan etkilerinin olasılığı azalır. Büyük bir değişiklik yapmanız gerekse bile bunu daha küçük değişikliklere bölmek için birçok strateji vardır.
Test Kapsamı: Tüm değişiklikler uygun birim testlerini içermelidir. Birim testleri, belirli donanım (CPU, GPU vb.) zamanlamalarına bağlı olmamalı ve deterministik ve odaklanmış testler yapmak için sahte verilerden ve taklitlerden bolca yararlanmalıdır. Mevcut ve şu anda test edilmesi zor olan kodu genişletmeyi amaçlayan değişiklikler, test edilebilirlik konusunda uygun iyileştirmeler yapmalıdır.
Faydaların net bir şekilde anlaşılması için tüm değişiklikler, değişiklik başlığında uygun karşılaştırma sonuçlarını da içermelidir.
Kod içindeki kurallar konusunda şüphe duyduğunuzda, her zaman önceden var olan kodu incelemek ve OpenXLA'da zaten mevcut olan kalıpları takip etmeye çalışmak iyi bir fikirdir.
İnceleme süreci
Proje üyelerinin gönderimleri de dahil olmak üzere tüm gönderimlerin incelenmesi gerekir. Bu amaçla GitHub pull isteklerini kullanırız. Çekme isteklerini kullanma hakkında daha fazla bilgi için GitHub Yardım'a bakın.
Kod, incelemeden önce yukarıda listelenen tüm standartlara uymalıdır. Bu bilgiler isteğe bağlı değildir ve değişikliklerin zamanında kabul edilmesi için gönderen kişinin, inceleme isteğinde bulunmadan önce kodunun uygun olduğundan emin olması çok önemlidir.
Tüm testler başarılı olmalıdır. Bir testin bozulduğunu ve sorunun derleme ortamınızla veya değişikliklerinizle ilgili olmadığını fark ederseniz lütfen bakımcılarla iletişime geçin.
İnceleme sürecinde kapsam kaymasından kaçınmaya çalışın. Bu, hem gönderenin hem de incelemeyi yapan kişinin sorumluluğundadır. Bir değişiklik çok büyük olmaya başlarsa bunu birden fazla değişikliğe bölmeyi düşünebilirsiniz.
Bir değişiklik birleştirilmeden önce, Google'a ve diğer donanım tedarikçilerine ait kodun kullanıldığı dahili testlerden geçirilir. Bu durum, herkese açık sürekli entegrasyon sistemimizin yakalamadığı dahili testlerde hatalar olması halinde inceleme sürecine ek adımlar ekleyebilir. Değişikliğinizi inceleyen Google çalışanı, dahili test hatalarını bildirir ve düzeltilmesi gereken noktaları açıklar.
Sık sorulan sorular (SSS)
"Bu altyapı değişikliği PR'm ile ilgili değil. Neden yapmalıyım?"
XLA ekibinin özel bir altyapı ekibi yok. Bu nedenle, yardımcı kitaplıklar oluşturmak ve teknik borçtan kaçınmak hepimizin sorumluluğunda. Bu toplantıların, XLA'da değişiklik yapmanın normal bir parçası olduğunu düşünüyoruz ve herkesin katılması bekleniyor. Genellikle kod yazarken gerektiği şekilde altyapı oluştururuz.
XLA incelemecileri, yazdığınız bir PR ile birlikte bazı altyapılar oluşturmanızı (veya PR'de büyük bir değişiklik yapmanızı) isteyebilir. Bu istek, gereksiz veya yapmaya çalıştığınız değişiklikle alakasız görünebilir. Bunun nedeni, ne kadar altyapı oluşturmanız gerektiğiyle ilgili beklentileriniz ile incelemecinizin aynı konudaki beklentileri arasındaki uyuşmazlık olabilir.
Beklentilerde uyuşmazlık olması normaldir. Bir projeye yeni başladığınızda bu durumun yaşanması beklenir (hatta bazen biz eski kurtların başına bile gelir). Geçmişte üzerinde çalıştığınız projelerde farklı beklentiler olabilir. Bu da normal ve beklenen bir durumdur. Bu, projelerden birinin yanlış yaklaşıma sahip olduğu anlamına gelmez. Sadece farklıdırlar. Altyapı isteklerini, bu projede beklentilerimizi öğrenmek için diğer tüm inceleme yorumlarıyla birlikte değerlendirmenizi öneririz.
"Yorumunuzu gelecekteki bir halkla ilişkiler çalışmasında ele alabilir miyim?"
Çekme isteklerindeki altyapı istekleriyle (veya diğer büyük isteklerle) ilgili sık sorulan bir soru, değişikliğin orijinal çekme isteğinde yapılıp yapılmaması gerektiği veya gelecekteki bir çekme isteğinde takip olarak yapılıp yapılamayacağıdır.
Genel olarak XLA, PR yazarlarının inceleme yorumlarını takip eden bir PR ile ele almasına izin vermez. Bir incelemeci, belirli bir PR'de ele alınması gereken bir konu olduğuna karar verdiğinde, istenen değişiklik büyük olsa bile genellikle yazarların bu konuyu ilgili PR'de ele almasını bekleriz. Bu standart, Google'ın hem dışında hem de içinde geçerlidir.
XLA'nın bu yaklaşımı benimsemesinin birkaç nedeni vardır.
Güven: İncelemeyi yapan kullanıcının güvenini kazanmak önemli bir bileşendir. Açık kaynaklı projelerde katkıda bulunanlar istedikleri zaman görünebilir veya kaybolabilir. Bir çekme isteğini onayladıktan sonra inceleme yapanlar, söz verilen takip işlemlerinin gerçekten yapıldığından emin olamaz.
Diğer geliştiriciler üzerindeki etkisi: XLA'nın belirli bir bölümüne dokunan bir PR gönderdiyseniz diğer kullanıcıların da aynı bölüme baktığına dair büyük bir olasılık vardır. PR'nizdeki teknik borcu kabul edersek bu dosyaya bakan herkes, takip gönderilene kadar bu borçtan etkilenir.
İnceleme ekibinin kapasitesi: Bir değişikliğin takip incelemesine ertelenmesi, zaten aşırı yüklenmiş olan inceleme ekibimize birden fazla maliyet getirir. İnceleme yapanlar, takip eden PR'ı beklerken ilk PR'ın ne hakkında olduğunu unutabilir. Bu da sonraki incelemeyi zorlaştırır. Ayrıca inceleme uzmanları, beklenen takip işlemlerini de takip ederek bunların gerçekten gerçekleştiğinden emin olmalıdır. Değişiklik, orijinal çekme isteğine gerçekten dik olacak şekilde yapılabilirse (böylece başka bir incelemeci inceleyebilir) bant genişliği daha az sorun yaratır. Deneyimlerimize göre bu durum nadiren görülür.