Design: وثق لماذا لا تكون بتات NaN حتمية بالكامل

هناك شيء آخر يجب ملاحظته وهو أنه من الصعب ملاحظة بتات NaN عن طريق الخطأ

هل هناك أي طريقة تجعل من المستحيل ملاحظتها أو على الأقل علامة بت؟

IMO nondeterminisms NaN يجب تركها بمفردها ، نظرا لندرة البرامج التي تهتم بها. ما هو الحال في التضحية بالأداء لجعلها حتمية؟

فيما يلي قائمة بالطرق التي يمكن للمرء أن يلاحظ بها بتات NaN:

• reinterpret
• store للذاكرة الخطية وتحميل البتات بتفسير مختلف (أو دع البتات تتم ملاحظتها خارجيًا)
• قم بتمرير وسيطة إلى call لدالة مستوردة ، أو قم بإرجاع قيمة من دالة مُصدرة
• copysign بت الإشارة على غير NaN

يمكن أن تُدخل الأجهزة الافتراضية رمزًا متعارفًا قبل كل من هذه ؛ هذه هي فكرة "وضع عنوان قانوني في نقاط الهروب" التي تمت مناقشتها أعلاه. store شائعًا جدًا في المسارات الساخنة ، لذلك من المحتمل أن يظل هذا مكلفًا إلى حد ما.

qwertie أنا أهتم بهم كثيرًا ولدي حالة استخدام تعتمد على كونها حتمية. ولكن كما نوقش هنا ، هناك طرق لجعلها حتمية بالكامل حتى لو لم تكن ضمن المواصفات.

قد تتضمن مزايا qwertie قابلية نقل أكبر قليلاً (يوجد رمز في العالم يستخدم بشكل غير حكيم وظيفة IEEE 754 totalOrder ، على سبيل المثال) ، وقابلية استنساخ أكبر قليلاً ، وثوابت أقوى عند إجراء عمليات حسابية متماثلة عبر عقد متعددة.

store شائع جدًا في المسارات الساخنة ، لذلك من المحتمل أن يظل هذا مكلفًا إلى حد ما.

في هذه الحالة ، هل يمكننا دائمًا تحديد قيمة الإشارة؟ لذا مثل جعله 1 إذا تم وضعه في mem؟

wanderer هذا هو ما فقم بتطبيق بعض التصحيح. عادة ما تكون مقارنة إضافية وتتفرع على المسار الساخن.

يجب أن أضيف أيضًا ، لم أقم بقياس أي من الخيارات المذكورة في هذه المشكلة ؛ أي معيار يمكن لأي شخص أن يضيفه هنا سيكون موضع ترحيب.

أود أن أميل بشدة نحو المستوى الحالي من اللا حتمية ، الذي يفضل الأداء.
لقد فوجئت إلى حد ما في الواقع بأن wasm يحدد بدقة أجزاء الجزء العشري لـ NaN.
في حين أن هذا قد يكون كافيا لمعالجات اليوم ، فمن يدري ما قد يأتي في المستقبل معالجات.

إذا تم إنشاء الوسم من لغة عالية المستوى ، يمكن لهذا المترجم أن يوفر خيارًا للتحكم في مستوى دلالات FP ، على غرار -ffast-math على سبيل المثال. يمكن للمترجم بعد ذلك إدخال أي إصلاحات إضافية مطلوبة لإجبار النان على التنسيق المطلوب. لتحقيق هذه الغاية ، يمكننا توفير مشغلي نان أو تطبيع نان ، على الرغم من أنني لا أدافع عن ذلك الآن.

باختصار ، من الأفضل ترك "إصلاح" هذا لأداة ذات مستوى أعلى ، وهي IMO.

+1mbodart. تحرير : انظر ، هناك بالفعل +1 شيء الآن :). راجع للشغل ، أنا شخصياً أعتقد أن Wasm = الهيمنة على العالم وبالتالي فإن المعالجات المستقبلية لن تستعد لذلك.

أود تحديد تأثيرات الأداء لهذا قبل اتخاذ قرار. أعتقد أن سلاسل أدواتنا لا تزال غير ناضجة جدًا لإجراء قياسات أداء جيدة في الوقت الحالي (هناك أعمدة أطول في طريق هذا). بعبارة أخرى: أريد أن أتجنب "الموت بألف جرح".

أتفق معjfbastien. يجب قياس تأثيرات الأداء أولاً قبل تعديل الدلالات.

لكي أكون واضحًا ، أنا لا أدافع حاليًا عن التغيير هنا ؛ أنا أجمع مادة الأساس المنطقي. إن اللاحتمية غير الحتمية (NaN bit) تخرج وتريد تفسيرًا. وبقدر ما أعلم ، لم يقم أحد بتحديد تأثيرات الأداء لجعل هذه البتات غير محددة أيضًا.

لا تنشر ARMv8 دائمًا المعامل الأول عندما يكون كلا المعاملين NaN. القاعدة هي:

• إذا كان أحد المعاملين عبارة عن NaN هادئ والآخر عبارة عن NaN للإشارة ، فقم بنشر NaN للإشارة.
• وإلا ، فانتشر المعامل الأول.

أثناء قراءتي للمواصفات ، ينطبق هذا على وضعي Aarch32 و Aarch64 من ARMv8.

يختلف هذا السلوك عن SSE الذي ينشر المعامل الأول في كلتا الحالتين.

كلتا البنيتين ستحولان sNaN إلى qNaN عن طريق ضبط البت الهادئ قبل نشره.

stoklund بقعة جيدة! لقد فاتني أن اختيار ARM لأول NaN لا يحدث في الحالة التي يشير فيها NaN الثاني. هذا من شأنه أن يعقد الإستراتيجية التي وضعتها لحالة NaN المتعددة أعلاه ، لذلك يمكننا أن نذكر ذلك في الأساس المنطقي.

لقد أنشأت الآن # 973 لاقتراح نص محدد يلخص ما ورد أعلاه.