Design: pThreads أي ETA؟

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

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

sunfishcode ، عادل بما فيه الكفاية ، ولكن بعد ذلك أقترح إنشاء مثل هذه القائمة. لا أعتقد أن أداة تعقب المشكلات هي بديل مناسب لذلك.

هناك قائمة w3 العامة . لا تواجه حركة مرور كثيفة بالرغم من ذلك. هناك أيضًا IRC على ما أعتقد؟ أعتقد أنه كان موجودًا على موقع الويب في وقت ما ، ولكن سيكون من الجيد أن يتم ربطهما بشكل مباشر في قسم المجتمع على موقع الويب. سأفتح مشكلة ولكني لست متأكدًا من السبل التي تفضل الكشف عنها للجمهور

التعليمات هنا:

• https://github.com/WebAssembly/design/blob/master/Contributing.md
• http://webassembly.org/community/feedback/

كنا نوجه الناس لاستخدام جيثب. لا يحبها الجميع ، لكن من الأفضل أن يكون لديك مكان واحد على كثير.

مرحبًا @ rossberg-chromium وشكرًا على إجابتك في الوقت المناسب.

ولكن يرجى الاحتفاظ بمتعقب المشكلة لإيداع القضايا.

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

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

--ر

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

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

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

ومع ذلك ، نتوقع اعتماد نهج JavaScript SharedArrayBuffer بشكل أو بآخر في WebAssembly. لقد شارك الكثير منا في هذه المواصفات منذ بدايتها. سيضيف إمكانات منخفضة المستوى شبيهة بما تمتلكه C ++ ، بالإضافة إلى واجهة برمجة تطبيقات تشبه العقود الآجلة. لديها مجال للنمو مع طلبات ذاكرة أكثر من الاتساق التسلسلي. هناك عمل مستمر لإنشاء نموذج ذاكرة رسمي لها.

SAB في "المرحلة 4" في TC39 ، مما يعني أنها جاهزة ، وجاهزة للشحن ، وجاهزة للاستخدام. أتوقع أن اعتماده في WebAssembly لن يكون صعبًا للغاية.

jfbastien شكرا لك على المعلومات الثاقبة.

ومع ذلك ، نتوقع اعتماد نهج JavaScript SharedArrayBuffer بشكل أو بآخر في WebAssembly. (...)
SAB في "المرحلة 4" في TC39 ، مما يعني أنها جاهزة ، وجاهزة للشحن ، وجاهزة للاستخدام. أتوقع أن اعتماده في WebAssembly لن يكون صعبًا للغاية.

باهر. أنا حريص على التخلص من الأمر باستخدام الكثير من كود C ++ الذي يتضور جوعاً ببساطة من أجل استخدام خيوط المعالجة.
أستخدم WebWorkers بانتظام في تطبيقات TS / JS الخاصة بي واسمحوا لي أن أقول إنني لست معجبًا بهم ، لكن يمكنهم البدء في البداية.

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

افهم تمامًا احتياجات MVP للخروج بسرعة (أعتقد أن هذا هو السبب في إسقاط AST لتتحول إلى قائمة على التكديس) والعناية التي تحتاجها للتخطيط لمزيد من الخطوات.

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

بصفتي مستخدمًا قديمًا لـ emscripten ، أود أن أرى WebAssembly أكثر فصلًا عن حدود مكدس تطبيق Javascript:

يجب على Wasm فقط 1) أن يهدف إلى أعلى أداء و 2) يوفر مآخذ وذاكرة / خيوط و GDI و fs مع بعض معايير Posix / Unix / BSD. بهذه الطريقة ، ستكون طبقة رقيقة تشبه نظام التشغيل يمكن دمجها في الأجهزة المحمولة كنظام أساسي مستهدف موحد وفي الخوادم للتنافس على التطبيقات القابلة للنشر على السحابة.

هل هذا هو الاتجاه الذي يسير نحو المستقبل على المدى الطويل أم أنني أفتقد القارب تمامًا؟

أشكرك مجددا لأجل عملك،

روبرتو

تم فصل Wasm بالتأكيد عن بعض حدود المكدس بسبب كيفية فصلنا للسكان المحليين عن ما يحتاجه مترجم مثل LLVM لوضعه في الذاكرة التي يمكن للمستخدم الوصول إليها.

مع الخيوط ، خاصة إذا لم تكن قائمة على العمال ، ستحصل على المزيد من القوة هناك.

ومع ذلك ، سيكون من الجيد الحصول على مزيد من التفاصيل حول أفكارك الدقيقة. ما هي حالة الاستخدام ، وكيف تتغلب عليها في C ++ ، وكيف يمكن أن تفعل ذلك تطبيقات wasm؟

لا أتوقع منك أن تأتي بكل الإجابات! فقط ما يتبادر إلى الذهن الآن. لدى Fwiw C ++ بعض الاقتراحات لحدود المكدس. تحقق من المجموعة الفرعية SG14.

آسف على التفاصيل المنخفضة ، أنا أقل من 👶🌯. سوف يجيب بشكل أفضل في وقت لاحق!

آسف على التفاصيل المنخفضة ، أنا تحت a: baby :: burrito : . سوف يجيب بشكل أفضل في وقت لاحق!

أنت تحت بوريتو صغير؟ مضحك جدا

تضمين التغريدة

أنت تحت بوريتو صغير؟ مضحك جدا

حرفيا ، طفل ملفوف.

مرحبًا jfbastien ،

سيكون من الجيد الحصول على مزيد من التفاصيل حول أفكارك الدقيقة. ما هي حالة الاستخدام ، وكيف تتغلب عليها في C ++ ، وكيف يمكن أن تفعل ذلك تطبيقات wasm؟

بشكل عام ، تتعلق حالة الاستخدام الخاصة بي ببناء برنامج محاكاة ، في الجزء الحسابي يكون الحد هو الجهاز فقط ، وذلك بفضل تقنيات C ++ و C / OpenCL و GPU.

في الواجهة الأمامية ، أثبت المكدس HTML5 + CSS + Javascript + Typescript أنه طريقة صالحة ومثبتة ومحمولة لتطوير تطبيقات معقدة متوسطة الحجم.

_ T he JS Web Stack (مع إضافة لغة منظمة مثل Typescript) جيدة جدًا هذه الأيام لدرجة أنني لا أشعر بالحاجة إلى اللجوء إلى emscripten أو تجربة wasm لمعظم التطبيقات.

أنا أتفق تمامًا تقريبًا على الأهداف عالية المستوى وحالات استخدام Webassembly وأكثر من ذلك على مستند تضمين المحتوى بخلاف الويب .

_ ستكون W ebAssembly تقنية ذات صلة (على الأقل بالنسبة لي) إذا كانت ستسمح بأن تكون أسرع (إلى حد كبير تطبيق C الأصلي بالإضافة إلى 5٪ على سبيل المثال) استخدم ذاكرة أكبر وأكثر حرية ، وأن يكون لديك منافذ / مآخذ منفذة بالكامل والسماح بتشغيل سلاسل الرسائل مثل أي نظام تشغيل عادي.

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

من أجل النعومة ، سأفصلها تدريجياً عن جافا سكريبت. إذا كان لدي مترجمين أصليين بأي لغة ، فأنا لست بحاجة إلى البرمجة النصية ، وعلى أي حال يمكنني تضمين Duktape / Lua / أيا كان ببساطة عن طريق التجميع في مصادر C.

في مكان ما على موقع Mozilla رأيت مستندات حول تنفيذ معالجة DOM الأصلية لـ wasm: لا أعتقد أنه سيكون مفيدًا للغاية لأن معالجة DOM متسلسلة بطبيعتها وهي أحد الجوانب الأكثر استهلاكا للوقت في مكدس HTML5 / CSS / JS: إذا أنا أكتب لغة متعددة الخيوط فائقة السرعة فقط لأجعل تغييرات DOM الخاصة بي متسلسلة في الانتظار في قائمة الانتظار ، ثم يختفي الأداء بالكامل ومن الأفضل نسخ بعض الكتابة النصية بدلاً من استخدام C / C ++. في هذه الحالة ، أفضل الوصول المباشر إلى OpenGL (في البداية مع بعض تطبيقات WebGL ثم OpenGL الأصلي). سيكون الوصول إلى بطاقة الرسوميات مفيدًا في تقديم إمكانيات GPU / CUDA بأعباء صغيرة أو بدون أعباء.
(ذهبت للتو للتحقق من هذا وحصلت على المشكلة رقم 273 لمعالجة هذا)

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

لا أتوقع منك أن تأتي بكل الإجابات! فقط ما يتبادر إلى الذهن الآن. لدى Fwiw C ++ بعض الاقتراحات لحدود المكدس. تحقق من المجموعة الفرعية SG14.

بالتأكيد سأفعل.

شكرا على صبرك ووقتك.

روب

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

jjpe سيكون هذا طلبًا لسلسلة أدوات معينة (مثل emscripten) تستهدف wasm ، بدلاً من هذا الريبو ، لأنها مشكلة تتعلق باختيار سلسلة أدوات للتنفيذ أو ABI بدلاً من شيء يتعلق بمنصة wasm في حد ذاتها. (على سبيل المثال ، يمكنك فتح مشكلة على https://github.com/kripken/emscripten/)

يبدو أن بعض الأشياء التي اقترحتها في رسالتي السابقة مدرجة في أحدث اقتراح WASI.
نرى:
https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

عبور الأصابع.

--ر

FWIW الحالة الحالية هي أن Chrome يقوم بشحن دعم سلاسل الرسائل في الإصدار 74 ، و Firefox به تطبيق لم يتم شحنه بعد ، ولدى Emscripten دعم pthreads (https://emscripten.org/docs/porting/pthreads.html) باستخدام wasm متاح الآن.

(تعد WASI أيضًا واجهة برمجة تطبيقات لاستدعاء النظام ، والتي تكون في الغالب متعامدة مع ما إذا كان تضمين صنف معين أو سلسلة أدوات تدعم الخيوط / الذرات أم لا).

هل هناك أي مستندات حول كيفية استخدام واجهات برمجة تطبيقات خيوط Chrome و Firefox؟

إنه نوع من مزيج من الأشياء. يقوم محرك wasm الخاص بالمستعرض بتنفيذ امتداد الخيوط / الذرات إلى مواصفات wasm (https://github.com/WebAssembly/threads/tree/master/proposals/threads) والذي يسمح بتكوين مثيل لذكريات wasm المشتركة. على الويب ، يمكنك إنشاء عامل ويب ، وإرسال الذاكرة (وأي وحدات نمطية مرتبطة بها) إلى العامل عبر postMessage. ثم تقوم بإنشاء مثيل للوحدة مع الذاكرة المشتركة على العامل (وعلى الخيط الرئيسي ، أو عامل آخر) وتشترك المثيلات في ذاكرتها. نظرة عامة على اقتراح المواصفات (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) لها مثال صغير ، لكني لست على علم بالآخرين.

مرحبًا dschuff وشكرًا على الإجابة أعلاه.
في رسالتي السابقة ، كنت أشير إلى رسالة سابقة ، لا تتضمن فقط pthreads بل تطورًا مرغوبًا فيه للوسم إلى شيء أكثر شبهاً بالنواة التي رأى البعض منا اتباعها واستخدام emscripten منذ عام 2010 بمثابة تقنية اختراق حقيقية.
راجع: https://github.com/WebAssembly/design/issues/992#issuecomment -285055578.

بعد تسع سنوات من ظهور emscripten ، وما يقرب من خمس سنوات بعد إعلانات wasm ، تم إحراز تقدم ضئيل في تحويل wasm إلى تقنية خادم قابلة للتطبيق.

للأسف ، لأننا نحتاج إلى معيار للتطبيقات المحمولة ، وأفضل طريقة للقيام بذلك كانت IMHO هي تنفيذ نواة صغيرة (مثل BSD / Linux) مع POSIX Thread و Berkeley Sockets + نظام ملفات ظاهري آمن قائم بذاته (مع المستخدمين والمجموعات كافية). أصر على قول إتش سبنسر القديم: "أولئك الذين لا يفهمون UNIX محكوم عليهم بإعادة اختراعها".

ما زلت أرغب في الحفاظ على إيماني ، لذا فإن WASI هي خطوة في الاتجاه الصحيح.

--ر

ملاحظة: لا يزال موقع emscripten 2010 صخريًا ، نظرًا لأنه يعمل في المتصفح الخالد ، وهو المتصفح الذي لا يُذكر الذي لا يُقهر والمستخدم في معظم المؤسسات والذي سيرى أجسام Firefox و Safari تطفو بواسطة (محركاتهما على الأقل).