Design: ما هي سلاسل ويب التجميع؟

يبدو أن هناك إصدارًا من emscripten-fastcomp يستخدم WebWorkers لتنفيذ سلاسل الرسائل:
https://github.com/juj/emscripten-fastcomp/tree/pthreads

نظرًا لأن سلاسل الرسائل مدرجة حاليًا كميزة ما بعد الإصدار 1 ،

متفق عليه ، الانتقال إلى أي مرحلة.

فيما يتعلق بهذه المشكلة ، في # 103 ، أقترح أن ننظر إلى ضمانات التقدم إلى الأمام على النحو المحدد في لجنة معايير C ++.

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

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

باستخدام سلاسل الرسائل المستندة إلى العامل_ ، لإنشاء سلسلة رسائل ، سينشئ تطبيق wasm عاملاً (في الإصدار 1 ، من خلال الاتصال بـ JS ؛ بعد تكامل WebIDL ، عن طريق استيراد Worker API وإنشاء العامل مباشرةً). لمشاركة كومة wasm / الحالة العالمية بين العمال ، سيكون كائن الوحدة النمطية wasm نفسه postMessage() ed مباشرة إلى العامل الوجهة ، متماثلًا مع كيفية مشاركة الفرد في SharedArrayBuffer ( الواردات من الوحدة النمطية WebAssembly سيتم إعادة استيرادها في الوجهة).

الايجابيات:

• متماثل مع تعيين pthreads-to-asm.js + SAB الواضح أن Jukka يعمل ويجتاز مجموعة اختبار pthread.
• يمكن مشاركة أي عدد من وحدات wasm بين أي عدد من العمال مما يسمح بتكوينات معبرة جدًا في حالات استخدام منفذ التطبيق غير الكامل لـ wasm.
• لا يوجد تغيير حقيقي لمنصة الويب أو واجهات برمجة تطبيقات الويب مقارنة بـ JS + SAB.

سلبيات:

• العمال حاليًا لديهم ذاكرة كبيرة (نظرًا لأن كل منهم يتضمن سياق تنفيذ JS مستقل ( JSRuntime / Isolate ، إلخ)).
• في حين أنه من الممكن بالتأكيد للعامل أن يتجنب إنشاء سياق JS إذا لم يتم استيراد JS في العامل (بمجرد أن يكون لدينا تكامل wasm + WebIDL) ، فلن تكون هذه مهمة ضمنية بسيطة (بسبب التبعيات العرضية والتقاطع طبيعة العمال). أيضًا ، هناك حالة الاستيراد الديناميكي لـ JS (في عامل خالٍ من JS سابقًا) والأعباء غير المرتبطة بـ JS والتي قد يكون من الصعب القضاء عليها. بالتأكيد مهتم بسماع ما تقوله المتصفحات الأخرى حول هذا الموضوع. لكنني أشعر بالقلق من أن سلاسل الرسائل لن تقلص بشكل موثوق عبر جميع المتصفحات لسنوات عديدة.

لذلك ، البديل هو خيوط WebAssembly الخالصة. بشكل أساسي ، ستحدد المواصفات كيفية إنشاء سلاسل الرسائل وإتلافها وضمها وما إلى ذلك. ستكون الخيوط منطقيًا "داخل" وحدة وستكون لجميع سلاسل الرسائل إمكانية الوصول إلى نفس الكرات الأرضية والواردات وما إلى ذلك. ماذا يحدث عندما يستدعي مؤشر ترابط غير رئيسي استيرادًا (في المتصفح) هو JS؟ (هذه الفكرة بأكملها منncbray) سيتم حظر مؤشر ترابط الاستدعاء وسيتم تنفيذ الاستدعاء على مؤشر الترابط الرئيسي للوحدة (تلك التي تم تحميل الوحدة عليها ، والتي تحتوي على Realm وما إلى ذلك) ، كأنها setTimeout(importedFun.bind(args to import call)) .

الايجابيات:

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

سلبيات:

• زيادة زمن الوصول مقارنةً بالمكالمة المتزامنة واختناق التسلسل على مؤشر الترابط الرئيسي. الحل البديل هنا هو أنه عندما نحصل على روابط WebIDL ، يمكننا تحديد آلية الاشتراك (على سبيل المثال ، سمة طريقة WebIDL الجديدة) التي تعلن واجهات برمجة التطبيقات أنه يمكن استدعاؤها بشكل متزامن من مؤشرات ترابط wasm.

عدم عرض هذه الأشياء على أنها حصرية للطرفين يوحي بوجود هجين مثير:

• يمكن مشاركة وحدة مع العديد من العمال (كما هو موضح أعلاه) ، وداخل كل عامل ، يمكن أن تفرز أي عدد من سلاسل الرسائل النقية التي يحتوي عليها هذا العامل + الوحدة.
  
  
  
  • سيكون العامل المحتوي هو "الخيط الرئيسي" لغرض استيراد المكالمات على مؤشرات الترابط النقية.
  
  
• يسمح هذا لتطبيق wasm بالتحكم بدقة في عدد حلقات الأحداث وسياقات JS التي ينشئها.
  
  
  
  • على سبيل المثال ، أتوقع أن يكون للعبة عامل واحد من OffscreenCanvas (لا توجد مؤشرات ترابط نقية ، فقط يتم عرضها على مؤشر ترابط العامل بدون مقاطعة) ، وعامل IDB واحد (ربما بضع سلاسل نقية) ، وواحد "الكل خيوط الخلفية الأخرى "عامل (مع جميع الخيوط الأخرى كخيوط نقية).
  
  
  • في الحد الأقصى ، بعد أن تم تمييز جميع واجهات برمجة تطبيقات الويب المهمة بأنها قابلة للاستدعاء مباشرة من سلاسل نقية ، فإن التطبيق المثالي سيخلق حصريًا سلاسل رسائل نقية.
  
  

من منصة الويب POV ، لا أعتقد أن أيًا من هذين الأمرين يغير النموذج جذريًا طالما أننا نحدد بعناية أشياء مثل حالة كومة كائنات إعدادات البرنامج النصي (مرة أخرى ، على الرغم من ذلك ، مماثلة لـ setTimeout ). أيضًا ، خيوط الصنف الصافية قابلة للوصف وقابلة للتعبئة من حيث asm.js + SAB: الخيط غير الرئيسي المستدعي يستخدم الذاكرة المشتركة لإدراج عمل الخيط الرئيسي ثم futexWait() s للرد.

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

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

يمكننا أيضًا تطوير منصة الويب بطريقتين:

• السماح لبعض واجهات برمجة تطبيقات الويب مثل GL لاستخدامها خارج سلسلة الرسائل الرئيسية ، ولكن لا يزال من موضوع واحد فقط.
• لا يعمل هذا الأسلوب مع العديد من حالات استخدام نظام الملفات على الرغم من ذلك: تتوقع التطبيقات أن تكون قادرة على read / write من سلاسل رسائل متعددة دون القيام بقفزات ضمنية ، وليس هناك سبب وجيه لمنع ذلك. يمكننا تحديد بعض واجهات برمجة التطبيقات للعمل من سلاسل عمليات متعددة (مع بعض القيود).

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

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

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

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

لا أعتقد أننا نريد أن يصبح العمال "خيوط من العدم" من خلال الاتصال بأي كود WASM يرغبون فيه. ما معرف pthreads التي يحصلون عليها؟ كيف يعمل TLS؟ ما لم تكن إدارة الخيط محكمًا لـ WASM ، ستكون هناك بعض الأسئلة الصعبة للإجابة عليها.

أنا أحب كود WASM الذي يتفاعل مع العمال التعسفيين. شيء ما على طول خط منافذ الرسائل + نسخ البيانات المجمعة ، إذا لم يكن هناك شيء آخر؟ (نعم ، هذا يبدو وكأنه خطوة إلى الوراء ، سأحاول تبريره في مكان آخر.)

إعادة استيراد وحدات ES6 المرتبطة على نوع postMessage تخيفني. إنه يحل بعض المشكلات السيئة ولكنه يبدو أيضًا وكأنه مطرقة كبيرة ستحطم حتماً شيئًا آخر. سأحتاج إلى التفكير في العواقب.

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

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

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

في الثلاثاء 9 حزيران (يونيو) 2015 الساعة 2:05 صباحًا ، كتب Nick Bray [email protected] :

منذ أن تحدثنا ، كنت أحاول كشف كرة شعر غير واضحة
القضايا المتفاعلة ونقاط البداية غير المفصلة (إعادة: سطح api + ffi

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

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

بعد قراءة مواصفات Web Worker ، فهي تتمحور حول JS. لا
تشتري لك الكثير ما لم يكن الخيط يحتوي على حلقة حدث ضمنية (نمط JS)
وعزل JS محلي الخيط. في هذه الحالة ، قد يكون من المنطقي معالجتها
كعامل. (لكن هذا النوع من الخيوط قد لا يكون موجودًا ، اعتمادًا على الآخر
خيارات التصميم.) لدي بعض المخاوف الأخرى حول كيفية حياة العامل
المحدد وحقيقة أن "أصل" التطبيق يمكن أن يختلف لكل موضوع ، لكنني
أعتقد أن هذه القضايا يمكن تأجيلها في الوقت الحالي.

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

لا أعتقد أننا نريد العمال أن يصبحوا "خيوط من العدم"
يدعو إلى أي كود WASM يحلو لهم. ما معرف pthreads التي يحصلون عليها؟
كيف يعمل TLS؟ ما لم تكن إدارة الخيط محكمًا لـ WASM ، فهناك
ستكون بعض الأسئلة الصعبة للإجابة عليها.

السؤال هو كيف يمكن للعامل أن يدخل في كود wasm؟ سيتعين عليهم ذلك
الحصول على إشارة إلى وحدة wasm بطريقة ما ، ويفترض أن يكون ذلك أولاً
postMessage () 'د لهم.

أنا أحب كود WASM الذي يتفاعل مع العمال التعسفيين. شيئا ما
على طول خط منافذ الرسائل + نسخ البيانات المجمعة ، إذا لم يكن هناك شيء آخر؟ (نعم،
هذا يبدو وكأنه خطوة إلى الوراء ، سأحاول تبريره في مكان آخر.)

إعادة استيراد وحدات ES6 المرتبطة على نوع postMessage تخيفني.
إنه يحل بعض المشكلات السيئة ولكنه يبدو أيضًا وكأنه مطرقة كبيرة
حطم شيئا آخر حتما. سأحتاج إلى التفكير خلال
عواقب.

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

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

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

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/WebAssembly/spec/issues/104#issuecomment -110178097.

اتفق مع titzer على أننا قد نرغب في دعم البرمجة غير المتزامنة من خلال السماح لـ wasm بالمشاركة مباشرة في حلقة الحدث (التي ليست امتدادًا للخيال). على مستوى عالٍ ، أعتقد أننا سنرى:

1. التطبيقات ذات C ++ POV المحمولة التي لا تريد أي غير متزامن ، فهي تريد خيوط نقية والعديد منها ويمكن أن تقتصر على سلاسل نقية (باستخدام العمال فقط لتجنب الاختناقات حتى يتم استدعاء جميع واجهات برمجة تطبيقات الويب المهمة مباشرة من خالص خيوط wasm).
2. التطبيقات التي تحتوي على POV على الويب والتي تتكون من وحدات JS ، ووحدات wasm ، تعتمد على أطر عمل الويب الشائعة ، وتستخدم الكثير من عدم التزامن. هذا هو المكان الذي نحتاج فيه بالتأكيد إلى القوة الكاملة للعمل المشترك والتكامل الجيد مع حلقة الحدث والوعود وما إلى ذلك.

وأعتقد أن كلتا حالتي الاستخدام ستهم كثيرًا في المستقبل المنظور.

من منظور C ++ ، يمكننا تعيين 2 POVs التي يقترحها

1. Codebase الذي يصدر _start .
2. Codebase الذي يصدر شيئًا مثل معالج select أو epoll معالج.

المترجم الفوري (lua ، python ، ...) يمكن أن يتلاءم بشكل جيد مع 2 ، ويمكن للتطبيقات معالجة حلقة حدث JS مع معالجة أحداث وحدة wasm ، بما في ذلك بعض واصفات الملفات ومعالجة الأنابيب التي لا تستطيع JS القيام بها عادةً إلا أنها كانت يمكن وحدة. لأكون واضحًا ، أنا لا أقول إننا نعرض epoll كما هو ، لكن شيئًا قريبًا منه لا يزال مناسبًا بشكل جيد لمنصة الويب.

IIUC، select / epoll قد يصل إلى مستوى المنع المتزامن لمجموعة محدودة من أحداث حلقة الحدث. لقد تم اقتراح ذلك منذ فترة طويلة بشكل مستقل للعاملين في JS ، ومن المحتمل أن ندفع ذلك إلى الأمام (إنه امتداد شامل للمنصة التي من المحتمل أن يكون لها عواقب دلالية واسعة ، وليس شيئًا يمكننا القيام به محليًا في wasm) ، لكنني أعتقد إذا أردنا الاندماج مع النظام الأساسي للويب _existing_ ، فهذه ليست الأوليات المنطقية للقيام بذلك: علينا السماح بالعودة إلى حلقة الحدث مما يعني أن يكون تسجيل نفسها هو معالج العامل onmessage (والذي يمكن أن يكون معبرًا عنها بطريقة wasm-y) والمشاركة مع الأشكال الأخرى من قوائم انتظار المهام الدقيقة / النانو / بيكو المحددة بالفعل في مواصفات HTML5. هذا يعني أنه إذا كان بإمكانك أن تجعل المتصفح يتصل بـ JS ، فيجب أن تكون قادرًا على الاتصال بـ wasm (وهو أمر ممكن تمامًا في MVP حيث يمكنك فقط الحصول على JS للاتصال بـ wasm ، لكننا ننظّر لعالم حيث العامل (أو حتى الموضوع الرئيسي) _ فقط_ يحتوي على wasm). (استثناء: أنا بخير ترك معالجات الأحداث المضمنة كـ JS فقط إلى الأبد :)

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

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

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

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

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

أيضًا ، تم تصميم WebAssembly نفسه ليكون مستقلاً عن JS ، وسيكون من الممكن الحصول على سلاسل WebAssembly بدون رمز JS على المكدس.

شكرا لك. من الجيد سماع ذلك.

ما الأشياء هنا التي نحتاج إلى اتخاذ قرار بشأنها بالنسبة إلى MVP ، وما الأشياء التي يمكن أن تنتظر حتى نقدم الذاكرة المشتركة بالفعل؟

لا أرى أنه يحظر بشكل مباشر أي شيء في MVP. ومع ذلك ، بالنسبة لشيء مركزي للغاية ، يبدو أنه يجب أن تكون لدينا فكرة واضحة جدًا عن الميزة (وبعض التجارب التجريبية) قبل أن يتم إنهاء / إصدار MVP بالفعل. لا أرى "block_binary" ، بالرغم من ذلك.

تم تفصيل بعض المشكلات على WebWorkers هنا: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/2

FWIW ، كلاهما من القضايا الضمنية والأخرى التي نتوقع معالجتها في FF.

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

@ lars-t-hansen بالنسبة للعمال الذين لم يبدأوا قبل العودة إلى حلقة الحدث ، عندما تقول "مسموحًا بالمواصفات" ، هل تقصد فقط بالمواصفات التي لا تحدد وقت إحراز تقدم أم أنها تذكر هذه الحالة على وجه التحديد؟ بالنسبة للقيود المفروضة على عدد سلاسل الرسائل ، فأنت على حق ، فالمطلوب (بالإضافة إلى حصة أكبر) هو بعض الأخطاء المرئية للإشارة إلى تجاوز الحصة النسبية.

أعتقد أن ضمان التقدم إلى الأمام هو ما نريده هنا ، بما يتماشى مع ورقة Torvald Riegel N4439 إلى لجنة معايير C ++ .

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

jfbastien ، لم أقرأ هذه الورقة بعد لكنني أوافق ، شيء من هذا القبيل مرغوب فيه.

(سأكتب لمعايير الويب الخاصة بنا ، الأشخاص يعيدون مواصفات العامل.)

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

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

@ lars-t-hansen Hah ، نقطة جيدة فيما يتعلق بإمكانية الملاحظة عبر الشبكة (خاصةً عندما تأخذ في الاعتبار مزامنة XHR في الخيط الرئيسي)> :)

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

lukewagner ، توفر مواصفات عامل الخدمة (https://slightlyoff.github.io/ServiceWorker/spec/service_worker/) الحد الأدنى من التبرير لسلوك "قتل عامل" (في الواقع ، نقص واجهة المستخدم لمربع حوار نصي بطيء ، راجع قسم "مدى الحياة") ولكن لا توجد إرشادات فعلية حول كيفية تجنب التعرض لإطلاق النار. بالنسبة لعامل حسابي في سياق SAB ، يعتبر ترخيص القتل مزعجًا بشكل خاص ، لأن الوضع الافتراضي لمثل هذا العامل سيكون أنه ينتظر متغير شرط لمزيد من العمل ، وليس أنه يعود إلى حلقة الحدث الخاصة به.

تم تقديم الخطأ ضد مواصفات WHATWG هنا: https://www.w3.org/Bugs/Public/show_bug.cgi؟id=29039.

ربما يمكن لـ slightlyoff أن يتناغم مع عامل الويب + عامل الخدمة و "رخصة القتل".

أعتقد أن تشغيل Webasm في بيئات أحادية العملية بشكل صارم سيكون ممكنًا حتى لو كانت المواصفات تتطلب وجود واجهة برمجة تطبيقات على مستوى pthreads؟ بما أنه لا يمكن ضمان التوازي ، على عكس التزامن ، فإن التطبيق سيكون حراً في التعامل مع "pthreads" التي تم إنشاؤها على أنها كتل يتم جدولتها بشكل تعسفي؟

هل ستضمن المواصفات أي ضمانات أكثر صرامة من الوقت الحقيقي السهل؟

وافق emanuelpalm على أن التطبيق الصحيح يمكن أن يحاكي نظام المعالج الفردي.

الوقت الفعلي الصعب ليس شيئًا أعتقد أنه يمكننا ضمانه بشكل عام لأن WebAssembly لا يعرف مسبقًا الجهاز الذي سيتم تشغيله عليه. أرى أن هذا القيد مشابه لخوارزميات الوقت الثابت الواعدة: لا يعرف الملف .wasm كيف سيتم تخفيضه بالفعل وما الضمانات التي يمكن أن يتوقعها من JIT والجهاز الذي سيتم تنفيذه عليه.

أنا متحمس حقًا بشأن هذا:
http://images.nvidia.com/events/sc15/SC5105-open-source-cuda-compiler.html
https://developer.nvidia.com/CUDA-LLVM-Compiler

هل من أفكار إذا كان تنفيذ حلقة متوازية forall ممكنًا في Web Assembly؟

كيف يمكن أن يبدو خط الأنابيب كطريقة ملموسة للتجربة؟
web assembly -> wasm binary -> chrome -> gpu

يبدو أنه من الأنسب أن يكون لديك شيء مثل:
web assembly -> binary (jit?) -> chrome -> gpu

jbondc أعتقد أن تفكيرك أقرب إلى C ++ التوازي TS ، والذي يتطلب دعم وقت التشغيل. قد يكون ذلك ممكنًا ، لكن WebAssembly ليس لديه حاليًا عمل مستمر لوحدات معالجة الرسومات. إنه مهم ، لكنه ليس التركيز الأساسي لـ MVP. يختلف عمل فريق روبرت تمامًا عما سيفعله WebAssembly (على الرغم من أنه قد يستفيد من هذا العمل).

نعم يبدو هذا صحيحًا:
https://github.com/cplusplus/parallelism-ts/blob/master/parallelism-ts.pdf

ولكن أكثر اهتماما بكتابة لغتي الخاصة التي يتم تجميعها وصولا إلى Web Assembly (ولديها دعم موازٍ).

أعتقد أن أفضل شيء يمكن وينبغي أن يفعله wasm هو توفير بدائل الأجهزة الأولية للتوازي ( الخيوط و SIMD ) ضمن نموذج وحدة المعالجة المركزية للأغراض العامة الذي يفترضه WebAssembly إلى ويب قابلة

أفكار حول شيء مثل هذا:
http://www.actor-framework.org/pdf/manual.pdf
https://github.com/actor-framework/actor-framework
https://www.youtube.com/watch؟v=VOFOj3LLXRk

هل هذه قصة محتملة؟

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

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

إنه ليس مستوى أعلى من التجريد. "نموذج الممثل" (https://en.wikipedia.org/wiki/Actor_model) هو نموذج نظري مختلف للتفكير في الحساب (مقابل آلة تورينج محدودة).

استنادًا إلى الأجهزة (مثل وحدة معالجة الرسومات من Nvidia) ، يمكنك تنفيذ بعض الممثلين العابرين للمراسلة في جهاز افتراضي. بالطريقة التي أراها ، إذا كان Chrome أو Chakra أو Firefox أو Webkit سيطبقون مطابقة النمط + ممثل مثل شيء ، فسنحصل على التوازي C ++ مجانًا ، ومشاركة الذاكرة + الخيوط ، وأي نموذج آخر متزامن تقريبًا.

ذات صلة في حالة رغبة شخص ما في اختراق شيء ما:
https://github.com/solodon4/Mach7

jbondc إنها ليست SMP

JSStats أنا أحاول أكثر أن أنظر إلى اللبنات الأساسية الجيدة. أفضل الأجهزة موجودة هنا بالفعل.

هناك مناقشة جيدة حول الأجهزة هنا:
http://amturing.acm.org/acm_tcc_webcasts.cfm (هندسة الكمبيوتر)

الخيوط / تصميم الذاكرة المشتركة سيء.
Hewitt's Actor Model أو بعض أشكاله هو السبيل للذهاب.

كمثال ملموس ، هذا عمل جيد:
http://2014.rtss.org/wp-content/uploads/2014/12/RTSS2014-sifakis-distr.pdf

صفحة 34. المواضيع سيئة.
صفحة 48. نموذج جيد.

صفحة 59-60. يمكن تطبيق "binary jit" هنا: مولد BIP الموزع.

سأحاول بعض التجارب في الأشهر المقبلة ، وآمل أن ينضم آخرون.

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

jbondc إذا كنت تخطط لإجراء بعض التجارب ، فيرجى فتح مشكلة جديدة للإبلاغ عن النتائج التي توصلت إليها. شكرا!

sunfishcode سيفعل ، لكنه

لأي شخص مهتم بـ BIP:
http://www-verimag.imag.fr/New-BIP-tools.html

هل التفكير إذن باستخدام خيوط WASM ، فإن هذا الرمز مثل هذا يمكن تجميعه في عمليات التحميل / التخزين الذري؟

class FastBlockableMutex {
 protected:
  atomic<bool> mIsLocked;
  atomic<int> mWaiters;
  atomic<int> mBlockers;
  mutex mMutex;

};

jbondc سيحتاج إلى تعليمات
نعم ، يمكن الوصول إلى الذرات طالما أن الحجم خالٍ من القفل. من المحتمل أن يذهب Mutex إلى ذرة ثم إلى شيء يشبه الفوركس. أتوقع أن يكون النموذج قريبًا من هذا .

jbondc ليست فكرة توفير سلاسل ومقارنة

malthe Ya ، بعد إجراء بعض الأبحاث ، هذا ما يفعله ponylang:
https://github.com/ponylang/ponyc/blob/master/src/libponyrt/actor/actor.c
https://github.com/ponylang/ponyc/blob/master/src/common/pony/detail/atomics.h

هناك أيضًا بعض أنماط التوازي المثيرة للاهتمام مع HPX:
https://www.youtube.com/watch؟v=6Z3_qaFYF84&feature=youtu.be&t=16m1s
https://github.com/STEllAR-GROUP/hpx/tree/master/external/atomic/boost/atomic/detail

ثم برمجة GPU:
https://www.youtube.com/watch؟v=KHa-OSrZPGo
https://github.com/ponylang/ponyc/issues/1330
http://llvm.org/docs/NVPTXUsage.html

binji سيعالج في اقتراح المواضيع . إغلاق.