"إبطاء البرامج أسرع بكثير من تسريع أجهزة الكمبيوتر"
منذ ذلك الحين ، تم اعتبار هذا البيان قانون ويرث . إنه ينفي بشكل فعال قانون مور ، الذي ينص على أن عدد الترانزستورات في المعالجات قد تضاعف منذ حوالي عام 1965. إليكم ما كتبه ويرث في مقال "Call for Slim Software" :
"منذ حوالي 25 عامًا ، كان محرر النصوص التفاعلي 8000 بايت فقط ، وكان المترجم 32 كيلو بايت ، بينما تتطلب أحفادهم الحديثة ميغا بايت. هل كل هذه البرامج المتضخمة أصبحت أسرع؟ لا ، العكس تماما. إذا لم تكن الأجهزة أسرع بألف مرة ، لكانت البرامج الحديثة غير قابلة للاستخدام تمامًا ".
من الصعب الاختلاف مع هذا.
برامج السمنة
مشكلة تطوير البرمجيات الحديثة حادة للغاية. يشير ويرث إلى جانب مهم: الوقت. يقترح أن السبب الرئيسي للبرنامج المتضخم هو قلة وقت التطوير.
يوجد اليوم سبب آخر لسمنة البرامج - التجريد. وهذه مشكلة أكثر خطورة بكثير. لم يسبق للمطورين كتابة برامج من الصفر ، لكن هذه لم تكن مشكلة من قبل.
حاول Dijkstra و Wirth تحسين جودة الكود وطوروا مفهوم البرمجة المنظمة. لقد أرادوا إخراج البرمجة من الأزمة ، وكان يُنظر إلى البرمجة لبعض الوقت على أنها حرفة حقيقية للمهنيين الحقيقيين. اهتم المبرمجون بجودة البرامج ، وأعربوا عن تقديرهم لوضوح وكفاءة الكود.
تلك الأيام قد ولت.
مع ظهور لغات عالية المستوى مثل Java و Ruby و PHP و Javascript ، أصبحت البرمجة أكثر تجريدًا بحلول عام 1995 عندما كتب ويرث مقالته. جعلت اللغات الجديدة البرمجة أسهل بكثير وأخذت الكثير. كانت موجهة للكائنات وجاءت مجمعة مع أشياء مثل IDEs وجمع القمامة.
أصبح من السهل على المبرمجين العيش ، لكن عليهم أن يدفعوا مقابل كل شيء. كلما كان العيش أسهل ، قل التفكير. في منتصف التسعينيات ، توقف المبرمجون عن التفكير في جودة برامجهم ، كما كتب المطور روبن مارتن في مقالته "كان نيكلاوس ويرث على حق ، وهذه هي المشكلة" . في الوقت نفسه ، بدأ استخدام المكتبات على نطاق واسع ، ودائمًا ما تكون وظيفتها أكثر من ضرورية لبرنامج معين.
نظرًا لأن المكتبة ليست مصممة لمشروع معين ، فمن المحتمل أن تحتوي على وظائف أكثر قليلاً مما تحتاجه حقًا. لا مشكلة ، كما تقول. ومع ذلك ، فإن الأشياء تضيف بسرعة كبيرة. حتى الأشخاص الذين يحبون المكتبات لا يريدون إعادة اختراع العجلة. وهذا يؤدي إلى ما يسمى جحيم التبعية. كتب نيكولا دوزا تدوينة عن هذا الموضوع في جافاسكريبت .
قد لا تبدو المشكلة كبيرة ، لكنها في الواقع أكثر خطورة مما تعتقد. على سبيل المثال ، كتب نيكولا دوسا تطبيقًا بسيطًا لقائمة المهام. إنه يعمل في متصفحك مع HTML و Javascript. كم عدد التبعيات التي تعتقد أنها استخدمت؟ 13000. ثلاثة عشر. ألف. إثبات .
الأرقام مجنونة ، لكن المشكلة ستزداد. كلما تم إنشاء مكتبات جديدة ، سيزداد أيضًا عدد التبعيات في كل مشروع.
هذا يعني أن المشكلة التي حذر منها نيكلاوس ويرث في عام 1995 ستزداد سوءًا بمرور الوقت.
ماذا أفعل؟
يقترح روبن مارتن أن الطريقة الجيدة للبدء هي تقسيم المكتبات. بدلاً من بناء مكتبة واحدة كبيرة تقوم بأفضل ما في وسعها ، ما عليك سوى إنشاء العديد من المكتبات.
وبالتالي ، يتعين على المبرمج فقط اختيار المكتبات التي يحتاجها حقًا ، متجاهلاً الوظيفة التي لن يستخدمها. فهي لا تقوم فقط بتثبيت عدد أقل من التبعيات نفسها ، ولكن المكتبات المستخدمة سيكون لها أيضًا تبعيات أقل.
نهاية قانون مور
لسوء الحظ ، لا يمكن أن يستمر تصغير الترانزستورات إلى الأبد وله حدوده المادية. ربما سيتوقف قانون مور عن العمل عاجلاً أو آجلاً. يقول البعض أن هذا قد حدث بالفعل. في السنوات العشر الماضية ، توقفت سرعة الساعة وقوة أنوية المعالج الفردية بالفعل عن النمو كما اعتادوا.
على الرغم من أنه من السابق لأوانه دفنه. هناك عدد من التقنيات الجديدة التي تعد باستبدال الإلكترونيات الدقيقة للسيليكون. على سبيل المثال ، تقوم Intel و Samsung وشركات أخرى بتجربة الترانزستورات بناءً على الهياكل النانوية الكربونية (الأسلاك النانوية) ، وكذلك باستخدام الرقائق الضوئية.
تطور الترانزستورات. التوضيح: سامسونج
لكن بعض الباحثين يتخذون نهجًا مختلفًا. يقترحون مناهج أنظمة جديدة للبرمجة لتحسين كفاءة البرامج المستقبلية بشكل كبير. وبالتالي ، من الممكن "إعادة تشغيل" قانون مور برمجيًا ، مهما بدا رائعًا في ضوء ملاحظات نيكلاوس ويرث حول السمنة في البرامج. ولكن ماذا لو تمكنا من عكس هذا الاتجاه؟
تقنيات تسريع البرمجيات
نشرت مجلة Science مؤخرًا مقالًا مثيرًا للاهتمام بقلم علماء من مختبر علوم الكمبيوتر والذكاء الاصطناعي في معهد ماساتشوستس للتكنولوجيا (CSAIL MIT). يسلطون الضوء على ثلاث مجالات ذات أولوية لمزيد من تسريع الحساب:
- أفضل البرامج
- خوارزميات جديدة
- المزيد من الأجهزة المحسّنة.
يؤكد المؤلف الرئيسي للعمل العلمي تشارلز ليسيرسون على بدانة أطروحة البرمجيات . ويقول إن فوائد تصغير الترانزستورات كانت عظيمة لدرجة أنه لعقود من الزمن ، تمكن المبرمجون من تحديد أولويات جعل الكود أسهل للكتابة بدلاً من تسريع التنفيذ. يمكن التسامح مع عدم الكفاءة لأن رقائق الكمبيوتر الأسرع تكون دائمًا مخصصة لسمنة البرامج.
يقول ليسيرسون: "لكن في الوقت الحاضر ، سيتطلب المزيد من التقدم في مجالات مثل التعلم الآلي والروبوتات والواقع الافتراضي قوة حوسبة هائلة لم يعد بإمكان التصغير توفيرها". "إذا أردنا تسخير الإمكانات الكاملة لهذه التقنيات ، يجب علينا تغيير نهجنا في الحوسبة."
في جزء البرنامج ، يُقترح إعادة النظر في إستراتيجية استخدام المكتبات ذات الوظائف الزائدة ، لأن هذا مصدر عدم الكفاءة. يوصي المؤلفون بالتركيز على المهمة الرئيسية - زيادة سرعة تنفيذ البرنامج ، وليس على سرعة كتابة الكود.
في كثير من الحالات ، يمكن بالفعل زيادة الأداء آلاف المرات ، وهذا ليس من قبيل المبالغة. على سبيل المثال ، استشهد الباحثون بضرب مصفوفتين 4096 × 4096. بدأوا بالتنفيذ في Python كواحدة من أشهر اللغات عالية المستوى. على سبيل المثال ، إليك تنفيذ من أربعة أسطر في Python 2:
for i in xrange(4096):
for j in xrange(4096):
for k in xrange(4096):
C[i][j] += A[i][k] * B[k][j]يحتوي الكود على ثلاث حلقات متداخلة ، وتستند خوارزمية الحل إلى منهج الجبر المدرسي.
لكن اتضح أن هذا النهج الساذج غير فعال للغاية بالنسبة لقوة الحوسبة. على أجهزة الكمبيوتر الحديثة ، سيتم تشغيله لمدة سبع ساعات تقريبًا ، كما هو موضح في الجدول أدناه.
| الإصدار | التنفيذ | وقت (أوقات) التنفيذ | GFLOPS | تسارع مطلق | تسارع نسبي | النسبة المئوية لذروة الأداء |
|---|---|---|---|---|---|---|
| 1 | بايثون | 25552.48 | 0.005 | 1 | - | 0.00 |
| 2 | جافا | 2372.68 | 0.058 | أحد عشر | 10.8 | 0.01 |
| 3 | ج | 542.67 | 0.253 | 47 | 4.4 | 0.03 |
| 4 | حلقات متوازية | 69.80 | 1.97 | 366 | 7.8 | 0.24 |
| خمسة | نموذج فرق تسد | 3.80 | 36.18 | 6727 | 18.4 | 4.33 |
| 6 | + التوجيه | 1.10 | 124.91 | 23224 | 3.5 | 14.96 |
| 7 | + intristics AVX | 0.41 | 337.81 | 52806 | 2.7 | 40.45 |
يؤدي التبديل إلى لغة برمجة أكثر كفاءة إلى زيادة سرعة تنفيذ التعليمات البرمجية بشكل كبير. على سبيل المثال ، سيتم تشغيل برنامج Java أسرع 10.8 مرة ، وبرنامج C أسرع بـ 4.4 مرة من Java. وبالتالي ، فإن التبديل من Python إلى C يعني تنفيذ برنامج أسرع بمقدار 47 مرة.
وهذه مجرد بداية التحسين. إذا قمت بكتابة الكود مع مراعاة خصائص الجهاز الذي سيتم تنفيذه عليه ، فيمكنك زيادة السرعة بمقدار 1300 مرة أخرى. في هذه التجربة ، تم تشغيل الكود أولاً بالتوازي على جميع النوى الـ 18 لوحدة المعالجة المركزية (الإصدار 4) ، ثم استخدمنا التسلسل الهرمي لذاكرة التخزين المؤقت للمعالج (الإصدار 5) ، وأضفنا التوجيه (الإصدار 6) ، وقمنا بتطبيق إرشادات محددة من إضافات المتجهات المتقدمة (AVX) في الإصدار 7. أحدث إصدار محسّن تستغرق الشفرة 0.41 ثانية فقط ، وليس 7 ساعات ، أي أكثر من 60 ألف مرة أسرع من كود بايثون الأصلي.
علاوة على ذلك ، على بطاقة رسومات AMD FirePro S9150 ، يعمل نفس الرمز في 70 مللي ثانية فقط ، و 5.4 مرة أسرع من الإصدار 7 الأكثر تحسينًا على معالج للأغراض العامة ، و 360 ألف مرة أسرع من الإصدار 1.
فيما يتعلق بالخوارزميات ، يقترح الباحثون نهجًا ثلاثي الأبعاد يتضمن استكشاف مجالات مشكلة جديدة ، وتوسيع نطاق الخوارزميات وتكييفها للاستفادة بشكل أفضل من الأجهزة الحديثة.
على سبيل المثال ، تعمل خوارزمية Strassen لمضاعفة المصفوفة بنسبة 10٪ أخرى على تسريع أسرع إصدار من الكود رقم 7. وبالنسبة للمشكلات الأخرى ، توفر الخوارزميات الجديدة مكاسب أكثر في الأداء. على سبيل المثال ، يوضح الرسم البياني التالي التقدم المحرز في كفاءة الخوارزميات لحل مشكلة التدفق الأقصى بين عامي 1975 و 2015. زادت كل خوارزمية جديدة من سرعة الحساب بعدة أوامر من حيث الحجم ، وفي السنوات اللاحقة تم تحسينها بشكل أكبر.
كفاءة الخوارزميات لحل مشكلة التدفق الأقصى على رسم بياني مع n = 10 12 رأس و m = n 11 حافة
وهكذا ، فإن تحسين الخوارزميات يساهم أيضًا في "محاكاة" قانون مور برمجيًا.
أخيرًا ، فيما يتعلق بهندسة الأجهزة ، يدعو الباحثون إلى تحسين الأجهزة بحيث يمكن حل المشكلات باستخدام عدد أقل من الترانزستورات. يتضمن التحسين استخدام معالجات أبسط وإنشاء أجهزة تتكيف مع تطبيقات محددة ، مثل وحدة معالجة الرسومات (GPU) التي تم تكييفها لرسومات الكمبيوتر.
يقول تاو شاردل ، المؤلف المشارك لورقة البحث: "يمكن أن تكون المعدات المصممة خصيصًا لمناطق معينة أكثر كفاءة وتستخدم عددًا أقل من الترانزستورات ، مما يسمح بتشغيل التطبيقات أسرع بعشرات إلى مئات المرات". "بشكل عام ، ستعمل تحسينات الأجهزة على تحفيز البرمجة المتوازية بشكل أكبر من خلال إنشاء مناطق إضافية على الشريحة للاستخدام المتوازي."
الاتجاه نحو الموازاة مرئي بالفعل. كما هو موضح في الرسم التخطيطي ، في السنوات الأخيرة ، زاد أداء وحدة المعالجة المركزية فقط بسبب الزيادة في عدد النوى.
أداء SPECint من النوى الفردية والمعالجات أحادية ومتعددة النواة من 1985 إلى 2015. الوحدة الأساسية هي معالج دقيق موديل 1985 80386 DX
بالنسبة لمشغلي مراكز البيانات ، يمكن حتى لأقل تحسن في أداء البرنامج أن يترجم إلى مكاسب مالية كبيرة. ليس من المستغرب أن تقود شركات مثل Google و Amazon الآن مبادرات لتطوير وحدات المعالجة المركزية المتخصصة الخاصة بها. تعمل معالجات Google TPU (العصبية) التي تم إصدارها لأول مرة وشرائح AWS Graviton في مراكز بيانات Amazon .
بمرور الوقت ، قد يتم اتباع قادة الصناعة من قبل مالكي مراكز البيانات الأخرى ، حتى لا يخسروا أمام المنافسين في الكفاءة.
كتب الباحثون أنه في الماضي ، أدت مكاسب الأداء المتفجرة في المعالجات ذات الأغراض العامة إلى الحد من نطاق تطوير المعالجات المتخصصة. الآن لا يوجد مثل هذا القيد.
قال البروفيسور تشارلز ليسيرسون ، المؤلف المشارك للبحث: "ستتطلب مكاسب الإنتاجية أدوات ولغات برمجة وأجهزة جديدة لتمكين تصميم أكثر كفاءة مع أخذ السرعة في الاعتبار". "هذا يعني أيضًا أن المبرمجين بحاجة إلى فهم أفضل لكيفية توافق البرامج والخوارزميات والأجهزة معًا ، بدلاً من النظر إليها بمعزل عن غيرها."
من ناحية أخرى ، يقوم المهندسون بتجربة التقنيات التي يمكن أن تعزز أداء وحدة المعالجة المركزية. هذه هي الحوسبة الكمومية ، التخطيط ثلاثي الأبعاد ، الدوائر الدقيقة فائقة التوصيل ، الحوسبة العصبية ، استخدام الجرافين بدلاً من السيليكون ، إلخ. ولكن حتى الآن هذه التقنيات في مرحلة التجارب.
إذا توقف أداء وحدة المعالجة المركزية عن النمو بالفعل ، فسنجد أنفسنا في واقع مختلف تمامًا. ربما يتعين علينا حقًا إعادة النظر في أولويات البرمجة لدينا ، وسوف يستحق المتخصصون في المجمع وزنهم ذهباً.
إعلان
هل تحتاج إلى خادم قوي ؟ تقدم شركتنا خوادم ملحمية - خوادم افتراضية مزودة بوحدة معالجة مركزية AMD EPYC وتردد نواة لوحدة المعالجة المركزية يصل إلى 3.4 جيجاهرتز. سيثير الحد الأقصى من التكوين إعجاب أي شخص - 128 نواة لوحدة المعالجة المركزية ، وذاكرة وصول عشوائي 512 جيجابايت ، و 4000 جيجابايت من ذاكرة الوصول العشوائي.
