Workload–Runtime Signatures of Parallel Scaling Bottlenecks: A Cross-Language Empirical Study of Rust, Julia, Haskell, and Python

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

لقد سعى دراسة حديثة إلى تجاوز مجرد تصنيفات السرعة البسيطة لفهم الميكانيكا المحددة لهذه الإخفاقات. فحص باحثون من المعهد النمساوي للتكنولوجيا أربع لغات برمجة شائعة: Rust وJulia وHaskell وPython. وقد اختيرت هذه اللغات لأنها تمثل فلسفات متباينة جدًا حول كيفية إدارة العمل المتوازي. تمنح لغة Rust المبرمج تحكمًا صارمًا في الذاكرة دون تنظيف تلقائي، وتستخدم لغة Julia مترجمًا "في الوقت المناسب" (Just-In-Time) لتحسين الكود أثناء التشغيل، وتعتمد لغة Haskell على نظام فريد من التقييم المؤجل والخيوط (threads) خفيفة الوزن، بينما تتقيد لغة Python، رغم شعبيتها، بقفل عالمي يجبرها على استخدام عمليات منفصلة للقيام بالأعمال الثقيلة. لم يكتف الفريق بتشغيل هذه اللغات على عدد قليل من المهام، بل أنشأوا بيئة محكومة لمراقبة سلوك كل لغة تحت ظروف محددة. لقد اختبروا ثلاثة أنواع متميزة من العمل: مهمة فرز تتطلب دمجًا مستمرًا للنتائج، وبحثًا هندسيًا يتضمن إيجاد أقرب النقاط في مجموعة كبيرة، وعملية جمع بسيطة تتطلب تنسيقًا ضئيلًا بين العمال. وقاموا بتشغيل هذه المهام مع عامل واحد، واثنين، وأربعة، وثمانية، وستة عشر عاملًا، باستخدام مدخلات ذات أحجام متفاوتة، ولم يقيسوا الوقت الإجمالي فحسب، بل قاسوا بدقة كيف يتم استهلاك ذلك الوقت.

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

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

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

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