اشکال زدایی مشکلات X10

باطن شتاب دهنده X10 می تواند توان عملیاتی بسیار بالاتری را برای محاسبات موازی مبتنی بر نمودار ارائه دهد، اما ردیابی به تعویق افتاده و کامپایل به موقع آن می تواند منجر به رفتار غیر واضح شود. این ممکن است شامل کامپایل مجدد مکرر ردیابی‌ها به دلیل تغییر شکل نمودار یا تانسور یا نمودارهای بزرگی باشد که منجر به مشکلات حافظه در طول کامپایل می‌شود.

یکی از راه های تشخیص مشکلات استفاده از معیارهای اجرا و شمارنده های ارائه شده توسط X10 است. اولین چیزی که باید بررسی کرد که یک مدل کند است، ایجاد یک گزارش معیار است.

معیارهای

برای چاپ یک گزارش متریک، یک فراخوان PrintX10Metrics() به برنامه خود اضافه کنید:

import TensorFlow

...
PrintX10Metrics()
...

با این کار معیارها و شمارنده های مختلف در سطح INFO ثبت می شود.

درک گزارش متریک

این گزارش شامل موارد زیر است:

• چند بار کامپایل های XLA را فعال می کنیم و کل زمان صرف شده برای کامپایل کردن.
• چند بار یک محاسبات XLA را راه اندازی می کنیم و کل زمان صرف شده برای اجرا.
• چه تعداد دسته داده دستگاه را ایجاد / نابود می کنیم و غیره.

این اطلاعات بر حسب صدک نمونه ها گزارش شده است. یک مثال این است:

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

ما همچنین شمارنده‌هایی را ارائه می‌کنیم که متغیرهای عدد صحیح نامیده می‌شوند که وضعیت نرم‌افزار داخلی را دنبال می‌کنند. مثلا:

Counter: CachedSyncTensors
  Value: 395

هشدارهای شناخته شده

Tensor که توسط X10 پشتیبانی می‌شوند، از نظر معنایی مانند حالت پیش‌فرض مشتاق Tensor رفتار می‌کنند. با این حال، برخی اخطارهای عملکرد و کامل بودن وجود دارد:

1. عملکرد ضعیف به دلیل کامپایل‌های زیاد.

   کامپایل XLA گران است. X10 هر بار که با اشکال جدید مواجه می شود، به طور خودکار نمودار را دوباره جمع آوری می کند، بدون دخالت کاربر. مدل‌ها باید اشکال تثبیت شده را در چند مرحله آموزشی ببینند و از آن نقطه به کامپایل مجدد نیازی نیست. علاوه بر این، مسیرهای اجرا باید به همین دلیل به سرعت تثبیت شوند: X10 هنگامی که با یک مسیر اجرای جدید مواجه می‌شوید دوباره کامپایل می‌شود. به طور خلاصه، برای جلوگیری از کامپایل مجدد:

   • از اشکال پویا بسیار متغیر اجتناب کنید. با این حال، تعداد کم اشکال مختلف می تواند خوب باشد. در صورت امکان، تانسورها را به اندازه های ثابت قرار دهید.
   • از حلقه‌هایی با تعداد تکرارهای مختلف بین مراحل آموزشی اجتناب کنید. X10 در حال حاضر حلقه‌ها را باز می‌کند، بنابراین تعداد تکرار حلقه‌های متفاوت به مسیرهای اجرایی متفاوت (نورل نشده) تبدیل می‌شوند.

2. تعداد کمی از عملیات هنوز توسط X10 پشتیبانی نمی شود.

   ما در حال حاضر تعدادی عملیات داریم که پشتیبانی نمی‌شوند، یا به این دلیل که راه خوبی برای بیان آنها از طریق XLA و اشکال استاتیک (در حال حاضر فقط nonZeroIndices ) یا عدم استفاده از موارد شناخته شده (چند عملیات جبر خطی و مقداردهی اولیه چندجمله‌ای) وجود ندارد. . در حالی که رسیدگی به دسته دوم در صورت نیاز آسان است، دسته اول فقط از طریق قابلیت همکاری با CPU، پیاده سازی غیر XLA قابل رسیدگی است. استفاده از قابلیت همکاری اغلب پیامدهای عملکردی قابل توجهی به دلیل رفت و برگشت میزبان و تکه تکه شدن یک مدل کاملاً ذوب شده در چندین ردیابی دارد. بنابراین به کاربران توصیه می شود از استفاده از چنین عملیاتی در مدل های خود اجتناب کنند.

   در لینوکس، از XLA_SAVE_TENSORS_FILE (مستند شده در بخش بعدی) استفاده کنید تا ردیابی پشته Swift را دریافت کنید که عملیات پشتیبانی نشده را نامیده است. نام توابع را می توان به صورت دستی با استفاده از swift-demangle جدا کرد.

به دست آوردن و ترسیم ردیابی ها

اگر مشکوک هستید که در نحوه ردیابی نمودارها مشکلاتی وجود دارد، یا می خواهید روند ردیابی را درک کنید، ابزارهایی برای خروج از سیستم و تجسم ردیابی ها ارائه می شود. با تنظیم متغیر محیطی XLA_SAVE_TENSORS_FILE می توانید از X10 بخواهید از ردیابی هایی که پیدا می کند خارج شود:

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

این گزارش‌های ردیابی در سه قالب می‌آیند: text ، hlo ، و dot ، با فرمت قابل تنظیم از طریق متغیر محیطی XLA_SAVE_TENSORS_FMT:

export XLA_SAVE_TENSORS_FMT=text

هنگامی که برنامه خود را اجرا می کنید، نمایش text که از سیستم خارج شده است، هر ردیابی را در یک نماد متنی سطح بالا که توسط X10 استفاده می شود نشان می دهد. نمایش hlo نمایش میانی را نشان می دهد که به کامپایلر XLA ارسال می شود. ممکن است بخواهید تعداد تکرارها را در حلقه های آموزشی یا محاسباتی خود محدود کنید تا از بزرگ شدن این گزارش ها جلوگیری کنید. همچنین، هر اجرا از برنامه شما به این فایل اضافه می شود، بنابراین ممکن است بخواهید آن را بین اجراها حذف کنید.

تنظیم متغیر XLA_LOG_GRAPH_CHANGES روی 1 همچنین در داخل گزارش ردیابی نشان می دهد که در آن تغییرات در نمودار رخ داده است. این برای یافتن مکان هایی که در آن کامپایل مجدد نتیجه می شود بسیار مفید است.

برای نمایش بصری یک ردیابی، گزینه dot نمودارهای سازگار با Graphviz را از سیستم خارج می کند. اگر بخشی از یک ردیابی را استخراج کنید که به نظر می رسد

digraph G {
    ...
}

در فایل خودش، Graphviz (با فرض اینکه نصب شده باشد) می تواند یک نمودار بصری از طریق آن ایجاد کند

dot -Tpng trace.dot -o trace.png

توجه داشته باشید که تنظیم متغیر محیطی XLA_SAVE_TENSORS_FILE ، به خصوص زمانی که در ترکیب با XLA_LOG_GRAPH_CHANGES استفاده شود، تأثیر منفی قابل توجهی بر عملکرد خواهد داشت. فقط در هنگام اشکال زدایی از آنها استفاده کنید و نه برای عملکرد معمولی.

متغیرهای محیطی اضافی

متغیرهای محیطی اضافی برای اشکال زدایی عبارتند از:

• XLA_USE_BF16 : اگر روی 1 تنظیم شود، تمام مقادیر Float را به BF16 تبدیل می کند. فقط باید برای اشکال زدایی استفاده شود زیرا ما دقت ترکیبی خودکار را ارائه می دهیم.

• XLA_USE_32BIT_LONG : اگر روی 1 تنظیم شود، نوع S4TF Long را به نوع عدد صحیح XLA 32 بیتی نگاشت می کند. در TPU، محاسبات اعداد صحیح 64 بیتی گران هستند، بنابراین تنظیم این پرچم ممکن است کمک کند. البته، کاربر باید مطمئن باشد که مقادیر همچنان در یک عدد صحیح 32 بیتی قرار می گیرند.