Design: الاقتراح: أعلام مستوى الامتثال Fp IEEE لـ Wasm (FP-Fast-Math for Wasm Scalar & SIMD)
تسمح برامج التحويل البرمجي الأصلية مثل gcc و clang و msvc للمطورين بتعيين مستويات امتثال fp IEEE من خلال البراغماس أو علامات وقت التجميع مثل / fp (صارم سريع) و ffast-math و -ffp-contract وما إلى ذلك. هذه العلامات مفيدة لمجموعة واسعة مجموعة من التطبيقات (مثل ML-convolutions و DSP ومحركات رسومات / فيزيائية منخفضة الدقة ..) حيث يفضل المطورون مقايضة الدقة المحمولة لصالح الأداء.
يمكن أن تكون مكاسب الأداء كبيرة اعتمادًا على الإعدادات المحددة والمجمعات المستخدمة. تسمح تلميحات / تفضيلات المطور هذه للمترجمين بإجراء المزيد من تحسينات Fp الرياضية بأمان واختيار تعليمات أفضل (دمج / fma) وقيود نطاق القيمة وعمليات تحقق مريحة.
في الوقت الحالي ، يتم استهلاك هذه العلامات عند تحديد مطوري Wasm بواسطة سلسلة أدوات المطور وقد يكرمون القليل منها اعتمادًا على الأداة المحددة المستخدمة (مثل https://github.com/WebAssembly/binaryen/pull/3155). سيتم تجاهل معلومات التفضيلات هذه غير متوفرة / مرئية لأوقات التشغيل إذا كانوا يرغبون في استخدامها.
يمكن أن تستفيد أوقات تشغيل Wasm من امتلاك الوسائل للوصول إلى إشارات / تلميحات المطورين هذه لاتخاذ قراراتهم الخاصة بشأن اختيار التحسين والتعليمات عندما يكون ذلك آمنًا. سيكون هذا مفيدًا بشكل خاص لإجراء تحسينات إضافية لوقت التشغيل ، خاصة في برامج التحويل البرمجي لـ AOT. يساعد هذا أيضًا في معالجة عدد قليل من مشكلات الأداء المعروفة في ترميز FP Wasm SIMD مثل التقريب ، والحد الأدنى / الحد الأقصى وما إلى ذلك. واحد على مستوى عالٍ ، سيسمح ذلك لأوقات التشغيل بأن لا تعتمد على أدوات المطور لبعض تحسينات FP ويزيل مانع لـ Wasm لتتبع الأداء الأصلي عن كثب.
هناك سابقة JVM 1.2 التي تساعد على التخفيف من امتثال IEEE كوضع افتراضي وإدخال معدل "صارم" لضمان قابلية النقل في فئة / واجهة / دقة تفصيلية. هناك فرصة لاستكشاف نهج أكثر توافقًا مع الإصدارات السابقة لـ Wasm.
أود أن أقترح آلية لتشفير إشارات امتثال fp IEEE في ملف Wasm الثنائي ليتم استهلاكها بواسطة محركات وقت التشغيل. كما هو الحال في اللغات الأصلية ، يمكن التعامل مع العلامات نفسها على أنها اختيارية ويمكن أن يكون استخدامها اختيارًا لأوقات التشغيل. سيظهر التأثير على أنه أداء محسّن ، ودلالات متسقة على نظام أساسي معين ، وإمكانية نقل أقل للنظام الأساسي. ستمكّن الآلية المقترحة من وضع علامات لا لبس فيها على أقسام الكود داخل ثنائي Wasm باستخدام هذه التفضيلات / التلميحات على مستوى تفاصيل كتلة التعليمات.
يمكن تسوية التصميم بالتفصيل أثناء المضي قدمًا ، يتمثل أحد الخيارات في تقديم قسم مخصص جديد بإدخالات تحدد التفضيلات وتعويضات مقطع الكود وخيار آخر هو تقديم تعليمات جديدة لتمييز أجزاء الكود بتفضيلات المطور هذه كما في JVM. يمكن مناقشة العلامات المحددة التي يجب دعمها وإدراجها أثناء تقدمنا (على سبيل المثال -fp-finate-math-only، -fp-no-signed-zeros ..)
ستكمل هذه الآلية المناقشات لإضافة إرشادات تقريبية Scalar / Vector FMA و FP لمواصفات Wasm و / أو SIMD.
تهدف هذه المشكلة إلى تتبع الاهتمام بهذا الموضوع ومناقشة ذلك في مزامنة CG.
arunetm
ال 7 كومينتر
نظرًا لأن صرامة عمليات fp تؤثر على دلالات البرنامج ، أتوقع أن أفضل طريقة لجعل دلالات أكثر تساهلاً ممكنة هي تقديم تعليمات جديدة بدلاً من قسم مخصص أو بناء كتلة. لدينا بالفعل آليات المواصفات اللازمة للتعامل مع عدم التحديد العائم بسبب قواعد انتشار NaN الخاصة بنا ، لذلك أتوقع أنه سيكون من السهل تقديم تعليمات جديدة للفاصلة العائمة تسمح بمزيد من النتائج المحتملة.
tlively
في ١٢ يناير ٢٠٢١
كسياق إضافي ، فإن JVM ، من جانبها ، تفكر في إزالة strictfp ودعم الدلالات الصارمة فقط.
sunfishcode
في ١٢ يناير ٢٠٢١
أفضل طريقة لجعل دلالات أكثر تساهلاً ممكنة هي تقديم تعليمات جديدة بدلاً من قسم مخصص أو بناء كتلة.
يُعد تقديم إرشادات جديدة مفيدًا ، لكنه لن يتوسع جيدًا أو يزيل تبعية سلسلة الأدوات تمامًا. تعتبر التعليمات التي تدعم النظام الأساسي الجيد مثل fma والمعاملة بالمثل وما إلى ذلك مرشحين جيدين لإضافة تعليمات جديدة. هناك تنوع كبير
-fassociative-math
-ffast-math
-fno-honor-nans
-ffinate-math-only
-fdenormal-fp-math
-fno-strict-float-cast-overflow
-fno-math-errno
-fno-trapping-math
...
معظم هذه تلميحات للسماح بتحسينات fp الأكثر عدوانية لرفع القيود المفروضة على التحويلات الجبرية ، nan ، الأصفار الموقعة ، الفخاخ ، التقريب ، إلخ. التعبير عن جميع العلامات المفيدة كتعليمات جديدة ليس مثاليًا imo.
كسياق إضافي ، فإن JVM ، من جانبها ، تفكر في إزالة صارم fp ودعم الدلالات الصارمة فقط.
شكرا sunfishcode لهذا السياق المضافة! لم أكن أعرف عن هذا التحديث الجديد ويبدو أن الدافع هو دمج متغيرات مكتبة الرياضيات. عند إلقاء نظرة فاحصة ، يبدو أن Javarict-fp أكثر تخصصًا وليست تمثيلًا جيدًا لنطاق نقاط التحكم التي تقدمها gcc / clang. يبدو أن أعلام -ffast-math والأعلام المرتبطة بها تحظى بشعبية كبيرة في المستودعات الأصلية من بحث github السريع. أخطط للنظر في استخدامات الأعلام المذكورة أعلاه والبراغمات المرتبطة بها
arunetm
في ١٢ يناير ٢٠٢١
المشاريع النموذجية التي تستخدم gcc / clang's -ffast-math يتم تجميعها إلى كود أصلي. عادةً ما يختبر مطورو التطبيقات الذين يستخدمونها جميع متغيرات التعليمات البرمجية الأصلية التي يقومون ببنائها بأنفسهم. ونظرًا لأن جميع ISAs الشائعة للأجهزة لها سلوك حتمي بالكامل في النقطة العائمة ، فبمجرد أن يختبر المطورون هذه المتغيرات ، يمكنهم التأكد تمامًا من أن السلوك لن يتغير لمستخدميهم. حاليًا ، تعمل النقطة العائمة لـ WebAssembly بهذه الطريقة أيضًا ؛ إنها حتمية تمامًا ، تمامًا مثل ISA للأجهزة ، لذلك يتم دعم افتراضات المطورين القائمة منذ فترة طويلة حول القدرة على إضافة الرياضيات السريعة واختبار أنها "مناسبة لهم".
تعني علامة WebAssembly-level -ffast-math أن WebAssembly لم يعد يشبه ISA الأجهزة في هذا الصدد ، ولم يعد يدعم هذه الافتراضات. سيختبر المطورون الثنائية التي ينتجونها ، ولكن عند الشحن لمستخدميهم ، يجب أن يتوقع مستخدموهم أن يكونوا قادرين على تشغيله على أجهزة مختلفة أو محركات مختلفة. باستخدام علامات تشبه الرياضيات السريعة على مستوى WebAssembly ، لن يتصرف WebAssembly مثل ISA ، ويمكن للمستخدمين رؤية نتائج نقطة عائمة مختلفة عن تلك التي تم اختبارها بواسطة المطور.
تجدر الإشارة أيضًا إلى أن المشروعات التي تستخدم هذه العلامات لا تُفقد عند التحويل إلى WebAssembly اليوم. على سبيل المثال ، العديد من التحسينات التي تم تمكينها بواسطة -fassociative-math هي تحسينات موجهة للحلقة يستطيع LLVM القيام بها قبل إنتاج WebAssembly.
sunfishcode
في ٢١ يناير ٢٠٢١
نعم ، أي قرارات تؤثر على دقة / سلوك الطفو يجب أن يتم دمجها في وحدة Wasm بواسطة الأدوات. يمكن إضافة تعليمات جديدة للسلوك الذي لا يمكن التعبير عنه بالتعليمات الحالية.
aardappel
في ٢١ يناير ٢٠٢١
لقد أجرينا مناقشة حول هذا الموضوع في اجتماع المجموعة الأخير مع إضافة التعليمات الجديدة كوسيلة بديلة للهدف. يبدو أن هناك مصلحة عامة في حل هذا من خلال الاتجاه الأخير. ليس لدي اعتراضات إذا كان من الممكن دعم توقعات المطور بشأن مكاسب الأداء من خلال تحسينات toolchain وتقديم متغيرات التعليمات المفقودة. في هذه الحالة ، ليست هناك حاجة جيدة لتبرير نشر هذه الأعلام في وقت التشغيل مما يضر بمستوى تجريد واسم. سيكون من الجيد فهم تعليمات المتغيرات الدلالية الضرورية للوصول إلى هذا الهدف. لدينا بعض الإرشادات الجديدة التي تم تحديدها في سياق SIMD والتي قد تحتاج إلى تمديدها لتتوافق مع الإرشادات التي تحتاجها أدوات التعبير عن علامات الرياضيات السريعة بشكل كامل. سوف نستمر في النظر في هذا الاتجاه.
شكرا على ملاحظاتك.
arunetm
في ٢٢ يناير ٢٠٢١
المحتوى المستخدم في مناقشة CG. واسم ffast-math.pptx
arunetm
في ١ مارس ٢٠٢١
القضايا ذات الصلة
jfbastien
·
6تعليقات
cretz
·
5تعليقات
mfateev
·
5تعليقات
dpw
·
3تعليقات
frehberg
·
6تعليقات
التعليق الأكثر فائدة
المشاريع النموذجية التي تستخدم gcc / clang's -ffast-math يتم تجميعها إلى كود أصلي. عادةً ما يختبر مطورو التطبيقات الذين يستخدمونها جميع متغيرات التعليمات البرمجية الأصلية التي يقومون ببنائها بأنفسهم. ونظرًا لأن جميع ISAs الشائعة للأجهزة لها سلوك حتمي بالكامل في النقطة العائمة ، فبمجرد أن يختبر المطورون هذه المتغيرات ، يمكنهم التأكد تمامًا من أن السلوك لن يتغير لمستخدميهم. حاليًا ، تعمل النقطة العائمة لـ WebAssembly بهذه الطريقة أيضًا ؛ إنها حتمية تمامًا ، تمامًا مثل ISA للأجهزة ، لذلك يتم دعم افتراضات المطورين القائمة منذ فترة طويلة حول القدرة على إضافة الرياضيات السريعة واختبار أنها "مناسبة لهم".
تعني علامة WebAssembly-level -ffast-math أن WebAssembly لم يعد يشبه ISA الأجهزة في هذا الصدد ، ولم يعد يدعم هذه الافتراضات. سيختبر المطورون الثنائية التي ينتجونها ، ولكن عند الشحن لمستخدميهم ، يجب أن يتوقع مستخدموهم أن يكونوا قادرين على تشغيله على أجهزة مختلفة أو محركات مختلفة. باستخدام علامات تشبه الرياضيات السريعة على مستوى WebAssembly ، لن يتصرف WebAssembly مثل ISA ، ويمكن للمستخدمين رؤية نتائج نقطة عائمة مختلفة عن تلك التي تم اختبارها بواسطة المطور.
تجدر الإشارة أيضًا إلى أن المشروعات التي تستخدم هذه العلامات لا تُفقد عند التحويل إلى WebAssembly اليوم. على سبيل المثال ، العديد من التحسينات التي تم تمكينها بواسطة -fassociative-math هي تحسينات موجهة للحلقة يستطيع LLVM القيام بها قبل إنتاج WebAssembly.