Design: استرخاء SIMD

تضمين التغريدة هذا مفيد للغاية.

سيكون من المفيد ألا تقتصر التعليمات كجزء من هذا الامتداد على أعلى 5. لقد قمنا بتقييم Float min / max ، وتحويلات float-int ، وما إلى ذلك حتى نتمكن من تقديم مكاسب كبيرة في الأداء اعتمادًا على الأنظمة الأساسية. سيساعد وجود هذه المتغيرات كمتغيرات تعليمات جديدة بدلاً من امتداد الوضع البسيط (المذكور أعلاه) في تقليل عدم الحتمية المحتملة التي تقدمها المحركات.
إلى جانب التكاثر النانوي ، هناك عدد قليل من السيناريوهات الأخرى التي قد تستفيد من استرخاء الدلالات ، خاصةً عندما يتم استخدام أوضاع الامتثال FP IEEE من قبل المطورين (على سبيل المثال ، no-honor-inf ، no-sign-zeros ، no-trapping-Math .. ) سيكون مفيدًا إذا استطعنا النظر في من هم تحت هذه المظلة أيضًا.

سيكون من المفيد إذا كانت التعليمات كجزء من هذا الامتداد لا تقتصر على الخمسة الأوائل.

نعم ، هذه القائمة ليست شاملة ، وآمل أن نتمكن من التوصل إلى المزيد عندما يكون لدينا في النهاية الريبو (على غرار الطريقة التي اقترحناها ودمجناها مع تعليمات SIMD).

إلى جانب التكاثر النانوي ، هناك عدد قليل من السيناريوهات الأخرى التي قد تستفيد من استرخاء الدلالات ، خاصةً عندما يتم استخدام أوضاع الامتثال FP IEEE من قبل المطورين (على سبيل المثال ، no-honor-inf ، no-sign-zeros ، no-trapping-Math .. ) سيكون مفيدًا إذا استطعنا النظر في من هم تحت هذه المظلة أيضًا.

فكرة جيدة ، سأضيف هذا المقتطف إلى الوصف ، شكرًا.

شكرا. ذات صلة: https://github.com/WebAssembly/design/issues/1393#issuecomment -788196826

آمل أن نتمكن من التوصل إلى المزيد عندما يكون لدينا في النهاية إعادة شراء

هل هناك خطة قريبة المدى لإجراء استطلاع رأي في المرحلة 0/1؟

هل هناك خطة قريبة المدى لإجراء استطلاع رأي في المرحلة 0/1؟
نعم ، بمجرد حصولنا على مزيد من التعليقات ، ربما يمكننا إجراء التصويت في اجتماع مجموعة التنسيق في 16 مارس.

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

قدم نوعًا جديدًا معتمًا ، fpenv ، يمثل معلومات حول بيئة النقطة العائمة للمضيف ، والتي سيتم تمريرها إلى عوامل مثل qfma كمعامل. يمكن أن يتطور هذا بطرق مختلفة في المستقبل ، ولكن في الوقت الحالي ، سيشمل فقط أعلام مثل "هل fma سريع؟".

في البداية ، الطريقة الوحيدة للحصول على قيمة fpenv ستكون باستيراد متغير عام من النوع fpenv :

   (global $fp (import "host.fp" "default") fpenv)

   (func $foo (param f32) (param f32) (param f32) (result f32)
     local.get 0
     local.get 1
     local.get 2
     global.get $fp
     f32.qfma
   )

(الأسماء "host.fp" و "default" هنا للتوضيح فقط ؛ وهذا شيء نحتاج إلى اكتشافه.)

بدلاً من القول إن qfma بحد ذاته غير محدد ، نقول أن قيمة fpenv التي تستوردها غير حتمية. سيؤدي ذلك إلى جعل الخاصية "نفسها عبر تشغيل" صريحة في التعليمات البرمجية. إذا أراد أحدهم ضمان أن يكون لمثيلين نفس القيمة (على سبيل المثال ، مثيل برنامج رئيسي ومثال مكتبة) ، فيمكن لوحدة واحدة استيرادها ثم إعادة تصديرها ، ويمكن للأخرى استيرادها من الأولى (يمكن أن تقوم سلاسل الأدوات بترتيبها) هذا تلقائيًا).

في عمليات التنفيذ النموذجية ، لن يكون fpenv قيمة ديناميكية. سيكون لدى العديد من المضيفين fpenv واحدة ممكنة ، لذا فإن جميع الإرشادات التي تتفاعل مع قيم fpenv يمكن أن تكون no-ops.

الجانب السلبي هو حجم كود wasm ؛ تأخذ إرشادات الاستيراد و global.get بعض المساحة. ومع ذلك ، يجب أن يكون التأثير صغيرًا نسبيًا ، نظرًا لأن التعليمات التي تحتاج إلى قيمة fpenv من المحتمل أن تكون غير متكررة نسبيًا في الوحدات الكاملة.

من الواضح أنه من المهم أن يكون "البرنامج" قادرًا على افتراض أن التقريب متسق عبر "تشغيل" لتجنب الانقطاعات وما إلى ذلك.

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

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

يبدو أن FMA هو مثال مضاد لهذا ؛ إنه متاح في الكثير من وحدات المعالجة المركزية هذه الأيام (وهذا الرابط قديم ، وهناك الكثير الآن) ، لذلك على سبيل المثال ، يمكن أن تعتمد العديد من بيئات الخوادم اليوم بشكل مريح على وجود FMA. لها قابلية تطبيق واسعة ، بما في ذلك المجالات التي يكون فيها كل من الحتمية والحساب الموزع مهمين (الجبر الخطي على مجموعات البيانات المكسوة بالبلاط). وهو يوفر تسريعًا كبيرًا (~ 30٪ الرقم المذكور أعلاه).

من الواضح أنه من المهم أن يكون "البرنامج" قادرًا على افتراض أن التقريب متسق عبر ...

تقتصر اللا حتمية في هذا الاقتراح على نتيجة التعليمات الفردية وهي متسقة عبر المسارات ...

هل هناك حالات حيث ، إذا لم تكن التعليمات "متسقة عبر المسارات" (لبعض التعريفات) ، فستظل مفيدة وليست مربكة؟

أفكر في تعريفه مثل:

fma(x, y, z) = oneof { round(x + y * z), round(round(x+y) * z) }

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

إذا كان التطبيق قويًا لمثل هذه الاختلافات ، فسيحصلون على أقصى أداء من هذا.

هل هناك حالات حيث ، إذا لم تكن التعليمات "متسقة عبر المسارات" (لبعض التعريفات) ، فستظل مفيدة وليست مربكة؟

من المؤكد أن هناك تطبيقات قوية لتقريب FMA بشكل مختلف في كل مرة يتم استدعاؤها. ولكن هناك أيضًا تطبيقات لا تكون فيها الدقة المطلقة مهمة ، ولكن تجنب الانقطاعات أمر مهم. على سبيل المثال ، في العديد من برامج الرسومات ، قد لا يكون ملحوظًا إذا كان موضع أو لون كائن معين مختلفًا قليلاً عما قد تظهره عملية حسابية دقيقة تمامًا ، ولكن قد يكون ملحوظًا إذا كان هناك نتوء في خط أو حد في التدرج.

لقد رأيت برامج تشغيل GPU تقوم بتقسيم FMAs إلى عمليات مضاعفة منفصلة وتضيف في الأماكن التي يمكن أن تناسب فقط الضرب أو الإضافة إلى خط أنابيب الأجهزة في مكان معين في الكود ، وقد رأيت التطبيقات الفعلية معطلة نتيجة لذلك. إذا أردنا الاتساق ، يجب أن نقول ذلك في المواصفات.

ماذا لو حللنا المشكلة في اتجاه مختلف عن طريق توضيح ما نعنيه بكلمة "تشغيل" في المواصفات؟ يمكننا إضافة لغة إلى تأثير "قد يكون لدى FMA هذا السلوك أو ذاك ، ولكن قد لا يلاحظ مثيل كلاً من السلوكين ويجب أن تلاحظ جميع الحالات في المتجر نفس السلوك." مرة أخرى ، بالنسبة للمحركات غير الموزعة وغير المهاجرة ، فإن هذا لا يفرض أي عبء إضافي. لا يزال يتعين على المحركات الموزعة / المهاجرة القيام بكل ما ستفعله باستخدام fpenv الصريح ، ولكن من منظور المنتج والمواصفات ، سيكون هذا أبسط.

ماذا لو حللنا المشكلة في اتجاه مختلف عن طريق توضيح ما نعنيه بكلمة "تشغيل" في المواصفات؟ يمكننا إضافة لغة إلى تأثير "قد يكون لدى FMA هذا السلوك أو ذاك ، ولكن قد لا يلاحظ مثيل كلاً من السلوكين ويجب أن تلاحظ جميع الحالات في المتجر نفس السلوك." مرة أخرى ، بالنسبة للمحركات غير الموزعة وغير المهاجرة ، فإن هذا لا يفرض أي عبء إضافي. لا يزال يتعين على المحركات الموزعة / المهاجرة القيام بكل ما ستفعله باستخدام fpenv الصريح ، ولكن من منظور المنتج والمواصفات ، سيكون هذا أبسط.

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

الهدف من fpenv هو أن المحركات لا يمكنها الاستدلال عليها بمفردها. يعرف المنتجون مقاصدهم ، مثل "تحتاج هذه المكتبة إلى نفس تكوين النقطة العائمة مثل البرنامج المرتبط به" ، و fpenv تتيح الحالة الغرض منها.

أرى وجهة نظرك حول كون المتجر تجريدًا غير كامل لحالة الاستخدام هذه. إذا قام أحد المحركات بالتقاط صور لذاكرة المثيل وأعاد تثبيت الوحدة بالذاكرة التي تم التقاطها على جهاز مختلف ، فيبدو أنه يمكنك استدعاء هذا المتجر المختلف ولكن لا يزال بإمكانك تعطيل البرنامج إذا تغيرت دلالات FMA.

أعتقد أنني لست مقتنعًا بأن السماح للمنتجين بالتعبير عن نواياهم الدقيقة هنا مفيد بما يكفي ليكون يستحق هذا التعقيد الإضافي ، رغم ذلك. أستطيع أن أرى أنه يمكن إنشاء حالة استخدام ، لكنني أعلم أيضًا أن المستخدمين الذين أعمل معهم والذين يرغبون حقًا في استخدام FMA لن يحتاجوا إلى ذلك. أنا بالطبع متحيز ، لأنني أعمل فقط عن كثب مع مستخدمي الويب ، الذين لن يحدث هذا فرقًا بالنسبة لهم. هل تعرف المستخدمين الذين يتوقون إلى هذا التحكم الدقيق؟ إذا لم يكن هناك أي ضمانات الآن ، فربما يمكننا إما تقديم أي ضمانات أو إيجاد طريقة لتحديد ضمانات رديئة حول الاتساق الدلالي في هذا الاقتراح. بافتراض عدم وجود مستخدمين الآن ، سأكون سعيدًا لإعادة النظر في هذا والقيام بإصدار آخر مع تحكم أكثر دقة في المستقبل عندما يكون هناك مستخدمون مستعدون للاستفادة من ذلك.

واحدة من خصائص الوسم المثيرة للاهتمام هي قابليتها للافتراضية. تمر جميع التفاعلات مع العالم الخارجي من خلال عمليات الاستيراد والتصدير ، لذلك من السهل الحصول على مثيلات WebAssembly بدون مفهوم "الجهاز الذي أستخدمه" كهوية مميزة يمكنهم التفاعل معها. مع WASI ، نحن نعمل على نظام بيئي لا تعرف فيه البرامج "مساحة اسم نظام الملفات للجهاز الذي أستخدمه" أو "تكوين الشبكة المحلية للجهاز الذي أستخدمه" (استبدل "الحاوية I" 'm in "أو" VM الذي أنا فيه "حسب الحاجة ؛-)).

هذا يعني أن "الجهاز الذي أستخدمه" يمكن أن يتغير بمرور الوقت ، ويمكن أن يكون "الجهاز الذي أستخدمه" مختلفًا عن "الأجهزة الأخرى التي ارتبطت بها قيد التشغيل". يمكننا القيام بذلك ، بدون تكوين مُرتَّب مسبقًا ، لأن العلاقات بين المثيلات موصوفة بالكامل في عمليات الاستيراد والتصدير الخاصة بها. أنا نفسي وآخرون نبني على أنظمة ستستفيد من هذه الخاصية بشكل عام.

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

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

كيف يتم معالجة ذلك لـ NaNs في عمليات f32 / f64 ؟

إن وحدات البت الخاصة بـ NaN التي تم إنتاجها بواسطة عملية f32 / f64 هي ببساطة غير محددة ، ضمن قيود قليلة ، لذا فهي لا تتضمن أي حالة. ومن الناحية العملية ، من النادر أن تهتم البرامج بأجزاء NaNs بطرق لا تغطيها القيود.

sunfishcode ، إذا أضفنا آلية fpenv لضمان الحتمية ، لا أعتقد أنها ستجعل مجموعة التعليمات المقترحة هذه أكثر جاذبية للمنتجين الذين يستهدفون أوقات التشغيل غير المتجانسة. بالنسبة للكود الذي يعمل في وجود FMA غير متسق ، لا يهم ما إذا كان لدينا آلية fpenv. من ناحية أخرى ، لن ترغب الكود الذي يتطلب ~ الحتمية ~ الاتساق خلال التشغيل في استخدام FMA في بيئة قد لا تدعمها باستمرار بسبب تكلفة محاكاتها. سيكون لمثل هذا الرمز أداء أكثر قابلية للتنبؤ باستخدام الضرب والإضافات غير المستخدمة ، والتي يمكن التعبير عنها بالفعل بدون هذا الاقتراح.

أنت محق في أن Wasm يُقصد به عمومًا أن يكون حتميًا بكل الطرق المهمة ويجب أن يكون افتراضيًا بسهولة. ولكن من المفترض أن يكون هذا الاقتراح استثناءً لهذه القاعدة ، ولهذا السبب تم فصله عن اقتراح SIMD. لا أتوقع أوقات تشغيل غير متجانسة تريد توفير الحتمية لتنفيذ هذا الاقتراح على الإطلاق. يجب أن تستخدم التعليمات البرمجية التي تريد تشغيلها في أوقات التشغيل التي توفر هذا الاقتراح بالإضافة إلى أوقات التشغيل التي لا توفر هذا الاقتراح اقتراح اكتشاف الميزة لتحقيق ذلك.

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

هذا لا يعني استبعاد القلق الذي يثيرهsunfishcode . أنا فقط أتساءل عما إذا كان نطاق الاهتمام أوسع من هذا الاقتراح. إذا كان الأمر كذلك ، فبالنسبة للمحركات الافتراضية ، أتساءل عما إذا كان من المنطقي ، عند تجميع وحدة ، تتبع أي سلوكيات خاصة بالمنصة لديها ، وبعد ذلك ، عند إنشاء وحدة نمطية ، قم بتسجيل تلك التفاصيل الخاصة بالمنصة الحالية وتأكد لنقل المثيلات إلى الأنظمة الأساسية التي لها نفس التفاصيل فقط. (أو لتقييد الكود بمجموعة فرعية من النظام الأساسي المستقل عن النظام الأساسي). أفكار؟

tlively لقد أوجزت حالة استخدام أعلاه والتي لا بأس بها مع FMA كونها غير حتمية ، ولكنها تحتاج إلى أن يكون FMA متسقًا خلال التشغيل. تؤدي الانقطاعات إلى كسر التطبيقات الحقيقية ، حتى عندما لا تكون هناك حاجة إلى الدقة الكاملة والحتمية الكاملة.

هل fpenv مرهق جدًا حقًا؟ يجب أن يكون ميكانيكيًا للعديد من سيناريوهات المنتجين ، ويجب أن يكون جاهلاً في كثير من المستهلكين.

RossTate Re: NaNs: مع NaNs يمكننا على الأقل إخبار المطورين "لا تفعل ذلك" ، في حين أن مواقف FMA التي تمت مناقشتها هنا تحدث في الاستخدام الشائع. وفي بعض حالات الاستخدام ، يمكننا تجاوز مشكلة NaN باستخدام أعلام محرك wasm لتعديل NaNs. إجمالاً ، القصة في الواقع ليست محكمة تمامًا ، لكنها مشكلة صغيرة إلى حد ما في الممارسة.

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

sunfishcode ، آسف ، في التعليق السابق ، استخدمت "غير حتمي" و "حتمية" حيث كنت أعني حقًا "غير متناسق خلال تشغيل" و "ثابت ضمن تشغيل". لقد قمت بتحديثه ، لذا نأمل الآن أن يكون أكثر منطقية. ليس الأمر أن fpenv مرهق بشكل خاص ، ولكن من وجهة نظري فإن حل المشكلة التي يحلها ليس هدفًا لهذا الاقتراح ولا أرى كيف سيضيف قيمة إلى عدد المستخدمين / البرامج الذين أستخدمهم نتوقع استخدام هذا الاقتراح. نظرًا لأن جذور الخلاف بيننا تبدو وكأنها توقعات مختلفة لأهداف الاقتراح ، فما رأيك في مواصلة هذا الخط من المناقشة في اجتماع CG التالي حيث يمكننا إجراء محادثة أكثر تفصيلاً حول الأهداف وغير الأهداف. أريد أن أترك مجالًا بشأن هذه المسألة للناس لإثارة مواضيع أخرى أيضًا :)

كتمرين فكري ، إذا كان لنا أن نسير في طريق تضمين آلية fpenv ، فأنا أحاول معرفة الطرق الأخرى التي ستكون مفيدة. أنا مهتم بفكرة تجريد متغيرات البيئة المضيفة في صورة عالمية - بصرف النظر عن is fma fast flag ، ما هي المعلومات المفيدة الأخرى التي يمكننا ترميزها؟ عندما تحدثنا لأول مرة عن ميزات ما بعد MVP Simd ، كانت الفكرة التي كانت جذابة بالنسبة لي بمثابة علامة متوافقة مع الإصدارات السابقة لتخفيف بعض دلالات عمليات MVP الحالية للأداء ، ويمكنني أن أرى fpenv مفيدًا لذلك غرض.

ومع ذلك ، ماذا يعني ذلك بالنسبة للتعليمات التقريبية المتبادلة / المتبادلة sqrt؟ ما لم أفقد شيئًا ما ، ستعطي هذه النتائج نتائج مختلفة قليلاً عن البنى المختلفة ولا يبدو أنه يمكن منعها باستخدام fpenv ؟

dtig قد نفكر في fpenv كنوع من الإشارة إلى معالج مشترك النقطة العائمة. سيكون المعامل fpenv في تعليمات الفاصلة العائمة هو المعالج المشترك لحساب النتيجة معه. سيكون من غير المحدد الخوارزميات التي يستخدمها المعالج المشترك ، ضمن بعض القيود التي نصممها ، لكن المعالج المشترك سيكون دائمًا متسقًا مع نفسه.

أود أن أشير إلى أنه لا يمكننا تغليف اللا حتمية بالكامل داخل متغير fpenv : بعض الإرشادات التي يتم وضعها في الاعتبار لـ SIMD المريح (على سبيل المثال ، خريطة تقريبية متبادلة / مربعة الشكل) للتعليمات غير المحددة معماريًا (على سبيل المثال RSQRTPS / RCPPS على x86 SSE). ومع ذلك ، يمكننا تحديد احتياطي حتمي لكل تعليمات SIMD مريحة ، يتم التعبير عنها من خلال تعليمات SIMD MVP. ثم يمكن للتطبيقات التي يكون فيها عدم الحتمية مصدر قلق كبير أن تستخدم التخفيض الحتمي ، على حساب بعض الأداء.

fpenv فقط بإعطاء نتائج التطبيقات المتسقة خلال التشغيل ، لذلك لا بأس من عدم تحديد RCPPS ، RSQRTPS ، إلخ.

إذا تضمن التشغيل نقل التنفيذ إلى جهاز مختلف ، فإن التعليمات التقريبية المتبادلة ستؤدي إلى نتائج مختلفة إذا كانت أقل إلى RCPPS / RSQRTPS

ما زلت غير متأكد من أن fpenv يجب أن يكون استيرادًا صريحًا لتلبية احتياجات @ sunfishcode ، ولكن إذا حدث ذلك ، فأنا أقترح عدم تمثيله كقيمة من الدرجة الأولى.

Maratyszcza لا يتعلق الأمر بضمان أنه يمكننا دائمًا الترحيل ، ولكن يتعلق بجعل متطلبات التطبيق صريحة.

RossTate نرحب بأي أفكار لديك لطرق أخرى لحل المشكلة.

sunfishcode في أقصى الحدود ، يمكننا توثيق ما يعادل fpenv في التعريفات الدلالية لكل من عمليات SIMD المريحة ، دون الحاجة إلى تمثيلها في كود البرنامج. باختصار ، قد يجلس في المثال ، لكنني متأكد من أنه يمكننا ركوب الدراجة. سيكون من مسؤولية المضيف تحديد كيفية تكوين fpenv (والذي يمكن أن يظل بطريقة برمجية في وقت إنشاء مثيل ، إذا لزم الأمر).

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

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

إذا أردنا أن تكون البرامج قادرة على الاشتراك أو إلغاء الاتساق الداخلي ، فسيكون من الأسهل توفير نسختين من كل تعليمات (أو فورية تمييزية) للسماح للمنتجين بالتعبير عن ذلك بشكل مباشر. لا حاجة للاستيراد أو أي شيء آخر. (لا يزال يتعين علينا أن نناقش لاحقًا ما إذا كان ينبغي أن يكون هذا هدفًا لهذا الاقتراح ، على الرغم من ذلك).

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

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

RossTate فيما يلي ملخص: بعض التطبيقات لا بأس بها إذا كانت بعض عوامل تشغيل fpenv من البيئة ويعيد تصديره ، ويمكن للمثيلات الأخرى بعد ذلك استيراده من المثيل الأول ، بحيث يحصلون جميعًا على نفس السلوك (دون التأثير على أي حالات أخرى غير مرتبطة بها).

بالتفكير في هذا أكثر ، لقد فكرت الآن أيضًا في طريقة للقيام بذلك بدون قيم من الدرجة الأولى. ظهرت فكرة "الدوال الجوهرية" للوضع عدة مرات ، ولكن لم يكن من الواضح أبدًا الفرق بين "التعليمات" و "الوظيفة الجوهرية". ربما أصبحت اللاحتمية الآن مثل هذا الاختلاف. إذا قمنا باستيراد الدالات الجوهرية qfma ، qrcp ، qrsqrt مع أسماء محجوزة حتى تتمكن المحركات من التعرف عليها ودمجها ، وطلبنا منها أن يكون لها سلوك حتمي في وقت التشغيل ، يمكن أيضًا إعادة تصديرها واستيرادها في حالات أخرى للتأكد من أن المثيلات الأخرى ترى نفس الوظائف.

شكرا للمعلومات ، sunfishcode!

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

بالنسبة لما تصفه ، أعتقد أنك بحاجة إلى امتداد مثل نظام التأثير. قد يشير تأثير التعليمات الخاصة بالمنصة إلى fpenv المحدد الذي استخدمته التعليمات. للحفاظ على هذا التتبع ، يجب أن يكون fpenv s من الدرجة الثانية (وإلا فإنك تدخل في أنظمة تأثير مكتوبة بشكل مستقل). وبالمثل ، سيتم تمديد أنواع توقيعات الوظائف لتقول أي fpenv يستخدمونه (ولجعل الأشياء قابلة للتتبع للمحركات ، يمكنك وضع قيود على أن يكون fpenv واحدًا على الأكثر موجودًا في كل مرة). بعد ذلك ، سيضمن فحص النوع أن الوظائف الحساسة fpenv تستدعي فقط وظائف حساسة أخرى fpenv تستخدم نفس fpenv ، وبالمثل تستورد / تصدر fpenv الوظائف الحساسة لـ fpenv .

هل هذا منطقي؟

RossTate تركت القليل من التفاصيل في الملخص: -}. لا نحتاج إلى آليات تفشل في التحقق مما إذا كان البرنامج يستخدم قيم fpenv ، داخل وحدة نمطية أو حتى داخل وظيفة واحدة. تعني الوظيفة التي تستخدم قيمتين fpenv الناحية المفاهيمية أنها قد تؤدي هيئتين مستقلتين من عمل الفاصلة العائمة التي لا تحتاج إلى أن تكون متسقة مع بعضها البعض. من الناحية العملية ، قد يكون هذا نادرًا جدًا ، لكننا لسنا بحاجة إلى حظره.

ما نحتاجه هو مجرد طريقة لطلب جزء من التعليمات البرمجية لتكون متسقة مع جزء آخر من التعليمات البرمجية. سواء كنا نستورد الكرات الأرضية أو الوظائف ، فإن الواردات تعطينا ما يلي: الطريقة التي يطلب بها جزء من التعليمات البرمجية أن تكون متسقة مع جزء آخر من التعليمات البرمجية هي استخدام نفس القيمة المستوردة. يمكن أيضًا إعادة تصدير الواردات إلى وحدات نمطية أخرى لتوفير نفس القيمة عبر حدود الوحدة النمطية.

sunfishcode ، كيف تتعامل مع هذه النقطة التي أثارها Maratyszcza ؟

أود أن أشير إلى أنه لا يمكننا تغليف اللا حتمية بالكامل داخل متغير fpenv: بعض الإرشادات التي يتم وضعها في الاعتبار لـ SIMD المريح (على سبيل المثال ، خريطة تقريبية متبادلة / مربعة الشكل) لتعليمات غير محددة معماريًا (مثل RSQRTPS / RCPPS على x86 SSE).

tlively لا يتعلق الأمر بضمان أنه يمكننا دائمًا الترحيل ، ولكن يتعلق بإعطاء التعليمات البرمجية طريقة

إذا قامت الوحدة A باستيراد واستخدام وإعادة تصدير fpenv ، واستوردتها الوحدة B من A وتستخدمها ، فهذا يشير إلى أنه مهما حصل على fpenv A ، سيحصل B على نفس الشيء. قد يعني ذلك أنني كمضيف لدي خيارات أقل مما كنت سأفعله إذا لم يكن لدى B هذا الاستيراد ، لكن هذا جيد. الشيء الأساسي هو أنني بصفتي مضيفًا أعرف أنهم بحاجة إلى أن يكونوا متشابهين ، لذا يمكنني تجنب كسرهم.

sunfishcode أنا قلق من أنك تتوقع أن تكون الواردات / الصادرات قادرة على التعبير أكثر مما تستطيع (أو على الأقل مما يمكنها التعبير عنه بسهولة). هل يمكنك إعطاء مثال عن برنامج متعدد المثيلات يجب التحقق من صحته (بسبب الاستخدام المتواصل لـ fpenv ) ومثال لبرنامج متعدد المثيلات لا يجب التحقق من صحته (بسبب الاستخدام غير المتسق لـ fpenv ) ، وتوضيح استخدام نوع استيراد يؤدي إلى التحقق من صحة أحد والآخر رفض؟

RossTate ، لا أعتقد أن استخدام fpenv "الخطأ" من المفترض أن يكون خطأ في التحقق من الصحة ، ولكنه قد يسمح للبرنامج بملاحظة الدلالات غير المتسقة التي لم يكن يتوقعها أو قد يؤدي إلى تقييد مضيف موزع.

RossTate لا يوجد مثال لبرنامج يجب عدم التحقق من صحته :-). لا يتعلق الأمر بالتقاط البرامج التي تستخدم قيم fpenv غير المتناسقة عن طريق الخطأ. يتعلق الأمر بالسماح للبرامج التي تحتاج إلى حساب متسق بطلب ذلك.

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

لذلك لا يوجد سحر هنا ولا إبطال. إنه يعمل مثل القيم العادية.

حسنا. آسف ، لقد قلت إنك بحاجة إلى معرفة التوافق المطلوب "مقدمًا" ، الأمر الذي طردني.

يبدو أن ما تصفه بعد ذلك يجب أن يكون قادرًا على التأثير في التجميع (إلا إذا كنت تريد أن يتم تجميعها بالفعل لاستدعاءات الوظيفة) ، فهل سيتم استيراد fpenv "مسبقًا" في ذلك الوقت؟

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

الخوارزميات التبادلية المطبقة في الأجهزة لها قيود قليلة جدًا مفروضة عليها (فقط الحد الأقصى للخطأ النسبي على x86). إنها جداول بحث مشفرة في تنفيذ المعالج. لا توجد واجهة برمجة تطبيقات للحصول على معلمات هذه الجداول ، لذا فإن الطريقة الوحيدة لمحاكاتها هي تفريغ 16 جيجا بايت تمثل إخراج 4 بايت لكل إدخال 4 بايت.

Maratyszcza نعم ، هذا صحيح. لكن لحسن الحظ ، لا أتطلع إلى محاكاة أي شيء هنا. أنا أتطلع في المقام الأول إلى إعطاء التطبيقات طريقة لتوضيح احتياجاتهم حتى أتمكن من تجنب القيام بأشياء من شأنها كسرها.

RossTate في معظم التطبيقات ، الفكرة هي أن هناك قيمة واحدة فقط ممكنة fpenv ، لذا فإن معرفة أي fpenv قيد الاستخدام لا يؤثر أبدًا على أي قرار يتخذه مثل هذا المحرك. لذلك أعتقد أن الاستيراد المنتظم سيكون كافياً في المستقبل المنظور.

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

انتقلت SIMD المريحة إلى المرحلة 1 في اجتماع CG في وقت سابق اليوم ، ولدينا مستودعنا الخاص على https://github.com/WebAssembly/relaxed-simd ، يرجى تقديم المشكلات ومواصلة المناقشات هناك.

لقد قدمت https://github.com/WebAssembly/relaxed-simd/issues/1 لالتقاط ما أعتقد أنه المناقشة الرئيسية هنا ، حول "الاتساق" والاقتراحات المختلفة حول كيفية تحديد ذلك.

شكراً لكم جميعاً على كل هذا النقاش ، وأتطلع إلى المزيد!