ما زلت أفكر في استخدام داكِس لوظائف المضيف الأصلية (native) لعمليات مكلفة.
على الورق، المنطق واضح. انقل الحسابات الثقيلة خارج WebAssembly، ونفّذها بكفاءة أكبر في بيئة المضيف، وقلّل بعضاً من التكاليف الإضافية على طول الطريق.
لكن تسريع جزء واحد من مسار التنفيذ لا يعني تلقائياً أن عبء العمل بأكمله سيصبح أسرع بالمقدار نفسه. وهذا يهمّ بينما يدفع داكِس لإحضار الأسواق المالية إلى السلسلة (onchain) مع مؤسسات مرخّصة من الاتحاد الأوروبي، حيث يجب أن تعمل البنية في النهاية تحت أحمال عمل حقيقية، لا أن تبدو فعّالة فقط على الورق. ما لا أعرفه بعد هو ما إذا كانت تصميمات وظائف المضيف لدى داكِس تزيل عنق زجاجة يهيمن فعلاً على أحمال العمل الواقعية، أم أنها تُسرّع أعمالاً يتبين لاحقاً أنها جزء أصغر من إجمالي زمن التنفيذ.
التفاصيل التي تستحق المتابعة هي: ما هي العمليات التي تنتقل خارج WASM، وكم تصبح أسرع، وما مقدار عبء عمل داكِس النموذجي التي تمثلها تلك العمليات.
توفر البنية سبباً جيداً لتوقّع تحسّن. لكن هذا دليل أضعف من رؤية نفس نوع عبء العمل ينتج مكسباً مادياً وقابلاً للتكرار في الممارسة.
لا يهمّني كثيراً التسريع النظري لبدائية واحدة بقدر ما يهمّني مقدار ما يغيّره ذلك في أداء عبء العمل الذي يشغّله داكِس فعلياً.
السؤال هو: هل أزال داكِس عنق زجاجة حقيقي في النظام، أم أنه فقط سرّع جزءاً من المسار دون نقل الأداء الكلي بعيداً جداً.
أنا أتابع مقاييس أداء (benchmarks) خاصة بداكِس تعزل مكسب وظائف المضيف وتُظهر مقدار ما تُمثله على مستوى عبء العمل.

#dusk $DUSK @Dusk