X10 hızlandırıcı arka ucu, grafik tabanlı paralel hesaplama için önemli ölçüde daha yüksek verim sağlayabilir, ancak ertelenmiş izleme ve tam zamanında derleme, bazen açık olmayan davranışlara yol açabilir. Bu, grafik veya tensör şekli değişiklikleri nedeniyle izlerin sık sık yeniden derlenmesini veya derleme sırasında bellek sorunlarına yol açan büyük grafikleri içerebilir.
Sorunları teşhis etmenin bir yolu, X10 tarafından sağlanan yürütme ölçümlerini ve sayaçlarını kullanmaktır. Bir model yavaş olduğunda kontrol edilecek ilk şey bir ölçüm raporu oluşturmaktır.
Metrikler
Bir ölçüm raporu yazdırmak için programınıza bir PrintX10Metrics()
çağrısı ekleyin:
import TensorFlow
...
PrintX10Metrics()
...
Bu, INFO
düzeyinde çeşitli ölçümleri ve sayaçları günlüğe kaydedecektir.
Metrik raporunu anlama
Raporda aşağıdakiler yer alıyor:
- XLA derlemelerini kaç kez tetiklediğimiz ve derleme için harcanan toplam süre.
- Bir XLA hesaplamasını kaç kez başlattığımız ve yürütme için harcanan toplam süre.
- Kaç tane cihaz veri tanıtıcısı oluşturduğumuz/yok ettiğimiz vb.
Bu bilgi numunelerin yüzdelik dilimleri cinsinden rapor edilir. Bir örnek:
Metric: CompileTime
TotalSamples: 202
Counter: 06m09s401ms746.001us
ValueRate: 778ms572.062us / second
Rate: 0.425201 / second
Percentiles: 1%=001ms32.778us; 5%=001ms61.283us; 10%=001ms79.236us; 20%=001ms110.973us; 50%=001ms228.773us; 80%=001ms339.183us; 90%=001ms434.305us; 95%=002ms921.063us; 99%=21s102ms853.173us
Ayrıca dahili yazılım durumunu izleyen tam sayı değişkenleri olarak adlandırılan sayaçlar da sağlıyoruz. Örneğin:
Counter: CachedSyncTensors
Value: 395
Bilinen uyarılar
X10 tarafından desteklenen Tensor
anlamsal olarak varsayılan istekli mod Tensor
gibi davranır. Ancak performans ve bütünlük konusunda bazı uyarılar vardır:
Çok fazla yeniden derleme nedeniyle performansın düşmesi.
XLA derlemesi pahalıdır. X10, yeni şekillerle her karşılaşıldığında, kullanıcı müdahalesi olmadan grafiği otomatik olarak yeniden derler. Modellerin birkaç eğitim adımı içinde sabitlenmiş şekilleri görmesi gerekir ve bu noktadan sonra yeniden derlemeye gerek yoktur. Ek olarak, yürütme yollarının da aynı nedenden ötürü hızlı bir şekilde dengelenmesi gerekir: X10, yeni bir yürütme yolu ile karşılaşıldığında yeniden derlenir. Özetlemek gerekirse, yeniden derlemelerden kaçınmak için:
- Oldukça değişken dinamik şekillerden kaçının. Ancak az sayıda farklı şekil iyi olabilir. Mümkün olduğunda tensörleri sabit boyutlara tamponlayın.
- Eğitim adımları arasında farklı sayıda yineleme içeren döngülerden kaçının. X10 şu anda döngüleri açmaktadır, bu nedenle farklı sayıdaki döngü yinelemeleri farklı (açılmamış) yürütme yollarına dönüşür.
Az sayıda işlem henüz X10 tarafından desteklenmemektedir.
Şu anda, bunları XLA ve statik şekiller (şu anda sadece
nonZeroIndices
olmayan) yoluyla ifade etmenin iyi bir yolu olmadığından veya bilinen kullanım durumlarının eksikliğinden (birkaç doğrusal cebir işlemi ve çok terimli başlatma) dolayı desteklenmeyen bir avuç işlemimiz var. . İkinci kategorinin gerektiği şekilde ele alınması kolay olsa da, ilk kategori yalnızca CPU ile birlikte çalışabilirlik, XLA olmayan uygulama aracılığıyla ele alınabilir. Birlikte çalışabilirliğin çok sık kullanılması, ana bilgisayar gidiş-dönüşleri ve tamamen birleştirilmiş bir modelin birden çok iz halinde parçalanması nedeniyle önemli performans etkilerine sahiptir. Bu nedenle kullanıcıların modellerinde bu tür işlemleri kullanmaktan kaçınmaları tavsiye edilir.Linux'ta, desteklenmeyen işlemi çağıran Swift yığın izlemesini almak için
XLA_SAVE_TENSORS_FILE
(sonraki bölümde belgelenmiştir) kullanın. İşlev adlarının karışıklığı,swift-demangle
kullanılarak manuel olarak çözülebilir.
İzlerin elde edilmesi ve grafiğinin çıkarılması
Grafiklerin izlenme şekliyle ilgili sorunlar olduğundan şüpheleniyorsanız veya izleme sürecini anlamak istiyorsanız, oturumu kapatmak ve izleri görselleştirmek için araçlar sağlanır. XLA_SAVE_TENSORS_FILE
ortam değişkenini ayarlayarak X10'un bulduğu izlerden çıkış yapmasını sağlayabilirsiniz:
export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt
Bu izleme günlükleri üç formatta gelir: text
, hlo
ve dot
ve format XLA_SAVE_TENSORS_FMT ortam değişkeni aracılığıyla ayarlanabilir:
export XLA_SAVE_TENSORS_FMT=text
Uygulamanızı çalıştırdığınızda, oturum kapatılan text
gösterimi, her bir izi X10 tarafından kullanılan yüksek düzeyli bir metin gösteriminde gösterecektir. hlo
gösterimi, XLA derleyicisine iletilen ara gösterimi gösterir. Bu günlüklerin çok büyük olmasını önlemek için eğitim veya hesaplama döngülerinizdeki yineleme sayısını kısıtlamak isteyebilirsiniz. Ayrıca, uygulamanızın her çalıştırılması bu dosyaya eklenecektir, dolayısıyla onu çalıştırmalar arasında silmek isteyebilirsiniz.
XLA_LOG_GRAPH_CHANGES
değişkeninin 1'e ayarlanması, izleme günlüğünde grafikte değişikliklerin nerede meydana geldiğini de gösterecektir. Bu, yeniden derlemenin sonuçlanacağı yerleri bulmada son derece faydalıdır.
Bir izin görsel temsili için dot
seçeneği Graphviz uyumlu grafiklerin oturumunu kapatacaktır. Bir izin şuna benzeyen kısmını çıkarırsanız
digraph G {
...
}
Graphviz (kurulu olduğunu varsayarak) kendi dosyasına görsel bir diyagram oluşturabilir.
dot -Tpng trace.dot -o trace.png
XLA_SAVE_TENSORS_FILE
ortam değişkenini ayarlamanın, özellikle XLA_LOG_GRAPH_CHANGES
ile birlikte kullanıldığında performans üzerinde önemli bir olumsuz etkiye sahip olacağını unutmayın. Bunları yalnızca hata ayıklama sırasında kullanın, normal çalışma için kullanmayın.
Ek ortam değişkenleri
Hata ayıklamaya yönelik ek ortam değişkenleri şunları içerir:
XLA_USE_BF16
: 1'e ayarlanırsa tümFloat
değerlerini BF16'ya dönüştürür. Otomatik karışık hassasiyet sunduğumuzdan yalnızca hata ayıklama için kullanılmalıdır.XLA_USE_32BIT_LONG
: 1 olarak ayarlanırsa S4TFLong
türünü XLA 32 bit tamsayı türüyle eşler. TPU'da 64 bit tamsayı hesaplamaları pahalı olduğundan bu bayrağın ayarlanması yardımcı olabilir. Elbette kullanıcının, değerlerin hala 32 bitlik bir tam sayıya sığdığından emin olması gerekir.