تقنية

أحداث توقيت CUDA: أي فترة تقيسها على المسار؟

نافذة طلب طولها اثنتا عشرة وحدة ونافذة جزء طولها خمس، لكل منهما حدان معلنان.
رسم تحريري لمثال معلن، دون تشغيل نموذج أو جهاز.

فترة توقيت أحداث CUDA تتعلق بحدين سجلتهما في العمل، لا بكل مدة طلب المستخدم. توثق PyTorch أحداثا للتزامن والتوقيت، ويكون enable_timing معطلا افتراضيا. [1] نرسم نافذتين معلنتين لفهم الرقم دون تشغيل جهاز.

الخلاصة السريعة

اقرأ الحدين والمسار ونوع التوقيت؛ لا تنقل مدة بين حدثين إلى زمن الطلب كله، ولا تسميها مجموع وقت الحساب الصافي دون تحديد ما وقع بينهما.

  • توثق Event قياس الزمن مع enable_timing، المعطل افتراضيا، وrecord يسجل في المسار المحدد أو الحالي عند إغفاله. [1] سم الإعداد والمسار.
  • في ورقتنا نافذة الطلب من صفر إلى 12، ونافذة الحدثين من 3 إلى 8 على خط معلن؛ مدتهما 12 و 5 وحدات، ولا نخلط حدود إحدى النافذتين بالأخرى.
  • العمل في مسار ثان لا يصبح كله داخل نافذة الحدثين لمجرد أنه على الجهاز نفسه؛ ولا نحول طول النافذة إلى مجموع أزمنة نوى دون معرفة محتواها.
  • توثق synchronize انتظار اكتمال العمل الذي يحمله الحدث. [1] تحقق من اكتماله ثم اقرأ حدود القياس؛ مثالنا ليس قياس CUDA أو مقارنة سرعة نموذج.

اسم الحدث لا يعلن إعداد التوقيت

تصف PyTorch الحدث كعلامة للتزامن والتوقيت؛ خيار enable_timing افتراضه False، ويسجل record في مسار معين أو المسار الحالي عند عدم تحديده. [1]

لذلك تحتاج بطاقة القياس إلى أكثر من سطر يقول «أنشأنا حدثين». اسأل هل فعّل التوقيت، وأي مسار يحمل التسجيل، وما العملية التي وضعت بين الحدين. لا ننسب إلى ملف زمن نتيجة لمجرد أنه يحتوي اسم واجهة.

نختار في الورقة مسارا اسمه س، وحدا قبله وآخر بعد جزء معلن. هذه تسمية تعليمية وليست معرف مسار حصلنا عليه من جهاز. ولا نستنتج من الاسم أن العمل الآخر على الجهاز توقف أو دخل النافذة نفسها.

نافذتان بطولين مختلفين

نؤلف خطا زمنيا واحدا بوحدات حسابية لتوضيح الحدود. يبدأ طلب كامل عند صفر وينتهي عند 12. داخل خطنا، يقع حد جزء العمل عند 3، وحده الآخر عند 8. لا نقدم هذه الأرقام كساعات CPU وGPU قرأناها فعليا.

مدة الطلب المعلنة 12 ناقص صفر، أي 12 وحدة. مدة الجزء بين الحدين 8 ناقص 3، أي 5 وحدات. يوجد زمن خارج الجزء داخل نافذة الطلب: ثلاث وحدات قبله وأربع بعده، مجموعهما سبع.

لو أراد التقرير زمن الطلب ثم نقل العدد خمسة، فقد نقل جواب سؤال آخر. ولم نسم الأجزاء الخارجية نقل بيانات أو انتظار شبكة؛ لم نحدد أسبابها في العقد. حدود صحيحة لا تبرر تشخيص سبب زمن لم نصفه.

هل الرقم يجمع كل ما على الجهاز؟

تصف elapsed_time مدة بالميليثانية بين تسجيل الحدث وتسجيل حدث النهاية. [1] هذا تعريف لحقل الواجهة؛ وحدات ورقتنا المفترضة لا تتحول بذلك إلى قياس ميليثانية حقيقي.

نضيف في الرسم الذهني مسارا ثانيا ص له عمل من 2 إلى 10. لا نضم مدته كلها إلى نافذة س من 3 إلى 8 بمجرد اشتراكهما في اسم الجهاز. وإذا كانت هناك علاقة انتظار بينهما، نحتاج وصفها قبل تفسير أثرها.

كذلك لا نجزئ الخمس إلى خمس وحدات حساب نواة صافي. قد يضم العقد بين الحدين أحداثا أخرى أو انتظارا؛ لم نزود القارئ بسجل تفصيلي. نتعامل مع مدة الفترة كما عرفناها، لا مع سبب أو مجموع أزمنة اخترعناه.

أي اكتمال تنتظره قبل التقرير؟

توضح synchronize انتظار انتهاء العمل الملتقط في الحدث، وتمنع تقدم خيط CPU حتى اكتماله. [1]

نقترح حفظ إعداد الحدث والمسار والحدين ودليل الاكتمال ووحدة التقرير، ثم بيان ما استبعد من النافذة. الانتظار على حدث لا نعرف علاقته بقياسنا ليس بديلا عن تعريف هذه العناصر.

الرسم يقارن نافذة طلب ونافذة جزء، ولم ننشئ حدثا أو نستدع elapsed_time. لا يثبت العدد خمسة تسريعا أو صحة نموذج. هو جواب مشروط لمدتين مؤلفتين؛ يبدأ تقييم التنفيذ الفعلي من حدوده الموثقة، لا من تسمية أصغر رقم بأنه الزمن الكامل.

المصادر ومتابعة القراءة

  1. PyTorch2.14: CUDA Event (يفتح في نافذة جديدة)docs.pytorch.org

أُعدّ هذا المقال بصياغة عربية أصلية بالاستناد إلى المصادر أعلاه، وهو مدخل تمهيدي إلى الموضوع. اقرأ منهجية المحتوى وحدوده.