Peringatan: Proyek ini sudah tidak digunakan lagi. Swift untuk TensorFlow adalah eksperimen dalam platform generasi berikutnya untuk pembelajaran mesin, menggabungkan penelitian terbaru di seluruh pembelajaran mesin, kompiler, pemrograman yang dapat dibedakan, desain sistem, dan seterusnya. Itu diarsipkan pada Februari 2021.

Halaman ini diterjemahkan oleh Cloud Translation API.

Men-debug masalah X10

Backend akselerator X10 dapat memberikan throughput yang jauh lebih tinggi untuk komputasi paralel berbasis grafik, namun penelusuran yang tertunda dan kompilasi tepat waktu terkadang dapat menyebabkan perilaku yang tidak jelas. Hal ini mungkin mencakup kompilasi ulang jejak yang sering terjadi karena perubahan bentuk grafik atau tensor, atau grafik berukuran besar yang menyebabkan masalah memori selama kompilasi.

Salah satu cara untuk mendiagnosis masalah adalah dengan menggunakan metrik dan penghitung eksekusi yang disediakan oleh X10. Hal pertama yang harus diperiksa ketika model lambat adalah membuat laporan metrik.

Metrik

Untuk mencetak laporan metrik, tambahkan panggilan PrintX10Metrics() ke program Anda:

import TensorFlow

...
PrintX10Metrics()
...

Ini akan mencatat berbagai metrik dan penghitung di tingkat INFO .

Memahami laporan metrik

Laporan tersebut mencakup hal-hal seperti:

Berapa kali kami memicu kompilasi XLA dan total waktu yang dihabiskan untuk kompilasi.
Berapa kali kami meluncurkan komputasi XLA dan total waktu yang dihabiskan untuk eksekusi.
Berapa banyak penanganan data perangkat yang kami buat/hancurkan, dll.

Informasi ini dilaporkan dalam persentil sampel. Contohnya adalah:

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

Kami juga menyediakan penghitung, yang diberi nama variabel integer yang melacak status perangkat lunak internal. Misalnya:

Counter: CachedSyncTensors
  Value: 395

Peringatan yang diketahui

Tensor yang didukung oleh X10 berperilaku semantik seperti Tensor mode bersemangat default. Namun, ada beberapa kendala kinerja dan kelengkapan:

Performa menurun karena terlalu banyak kompilasi ulang.
Kompilasi XLA mahal. X10 secara otomatis mengkompilasi ulang grafik setiap kali bentuk baru ditemukan, tanpa campur tangan pengguna. Model perlu melihat bentuk yang stabil dalam beberapa langkah pelatihan dan sejak saat itu tidak diperlukan kompilasi ulang. Selain itu, jalur eksekusi harus stabil dengan cepat karena alasan yang sama: X10 melakukan kompilasi ulang ketika jalur eksekusi baru ditemukan. Singkatnya, untuk menghindari kompilasi ulang:
- Hindari bentuk dinamis yang sangat bervariasi. Namun, sejumlah kecil bentuk yang berbeda mungkin tidak masalah. Padukan tensor ke ukuran tetap jika memungkinkan.
- Hindari perulangan dengan jumlah iterasi berbeda antar langkah pelatihan. X10 saat ini membuka gulungan loop, oleh karena itu jumlah iterasi loop yang berbeda diterjemahkan ke dalam jalur eksekusi yang berbeda (tidak digulung).
Sejumlah kecil operasi belum didukung oleh X10.
Saat ini kami memiliki beberapa operasi yang tidak didukung, baik karena tidak ada cara yang baik untuk mengekspresikannya melalui XLA dan bentuk statis (saat ini hanya nonZeroIndices ) atau kurangnya kasus penggunaan yang diketahui (beberapa operasi aljabar linier dan inisialisasi multinomial) . Meskipun kategori kedua mudah ditangani sesuai kebutuhan, kategori pertama hanya dapat diatasi melalui interoperabilitas dengan CPU, implementasi non-XLA. Penggunaan interoperabilitas yang terlalu sering menimbulkan implikasi performa yang signifikan karena adanya perjalanan bolak-balik host dan fragmentasi model yang sepenuhnya menyatu dalam beberapa trace. Oleh karena itu pengguna disarankan untuk menghindari penggunaan operasi seperti itu dalam model mereka.
Di Linux, gunakan XLA_SAVE_TENSORS_FILE (didokumentasikan di bagian selanjutnya) untuk mendapatkan jejak tumpukan Swift yang disebut operasi yang tidak didukung. Nama fungsi dapat diubah secara manual menggunakan swift-demangle .

Memperoleh dan membuat grafik jejak

Jika Anda menduga ada masalah dengan cara penelusuran grafik, atau ingin memahami proses penelusuran, alat disediakan untuk keluar dan memvisualisasikan penelusuran. Anda dapat meminta X10 mengeluarkan jejak yang ditemukannya dengan mengatur variabel lingkungan XLA_SAVE_TENSORS_FILE :

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

Log jejak ini hadir dalam tiga format: text , hlo , dan dot , dengan format yang dapat diatur melalui variabel lingkungan XLA_SAVE_TENSORS_FMT:

export XLA_SAVE_TENSORS_FMT=text

Saat Anda menjalankan aplikasi, representasi text yang keluar akan menampilkan setiap jejak individual dalam notasi teks tingkat tinggi yang digunakan oleh X10. Representasi hlo menunjukkan representasi perantara yang diteruskan ke kompiler XLA. Anda mungkin ingin membatasi jumlah iterasi dalam loop pelatihan atau penghitungan untuk mencegah log ini menjadi terlalu besar. Selain itu, setiap proses aplikasi Anda akan ditambahkan ke file ini, jadi Anda mungkin ingin menghapusnya di antara proses yang berjalan.

Menyetel variabel XLA_LOG_GRAPH_CHANGES ke 1 juga akan menunjukkan dalam log jejak di mana perubahan pada grafik telah terjadi. Ini sangat membantu dalam menemukan tempat di mana kompilasi ulang akan dihasilkan.

Untuk representasi visual dari jejak, opsi dot akan mengeluarkan grafik yang kompatibel dengan Graphviz. Jika Anda mengekstrak bagian jejak yang terlihat seperti itu

digraph G {
    ...
}

ke dalam filenya sendiri, Graphviz (dengan asumsi sudah diinstal) dapat menghasilkan diagram visual melalui

dot -Tpng trace.dot -o trace.png

Perhatikan bahwa menyetel variabel lingkungan XLA_SAVE_TENSORS_FILE , terutama bila digunakan bersama dengan XLA_LOG_GRAPH_CHANGES akan berdampak negatif besar pada kinerja. Hanya gunakan ini saat melakukan debug, dan bukan untuk pengoperasian reguler.

Variabel lingkungan tambahan

Variabel lingkungan tambahan untuk proses debug meliputi:

XLA_USE_BF16 : Jika disetel ke 1, ubah semua nilai Float menjadi BF16. Sebaiknya hanya digunakan untuk debugging karena kami menawarkan presisi campuran otomatis.
XLA_USE_32BIT_LONG : Jika diatur ke 1, memetakan tipe S4TF Long ke tipe integer XLA 32 bit. Di TPU, komputasi bilangan bulat 64 bit mahal, jadi menyetel tanda ini mungkin bisa membantu. Tentu saja, pengguna perlu memastikan bahwa nilainya masih sesuai dengan bilangan bulat 32 bit.