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

في،شارك تشو هونغلين، مهندس الحوسبة عالية الأداء في شركة تينسنت، خوارزمية فريقه وممارسات تحسين المشغل لضرب المصفوفات منخفضة التعقيد في عرض تقديمي بعنوان "FalconGEMM: تجاوز ذروة الأجهزة بضرب المصفوفات منخفضة التعقيد".

في مواجهة التحدي المتمثل في أن مكتبات العمليات الناضجة مثل cuBLAS قد رفعت أداء ضرب المصفوفات إلى ما يقارب ذروة الأداء على مستوى الأجهزة، وأن نطاق التحسين التقليدي على مستوى النواة يتقلص باستمرار، بدأ الفريق من جديد من منظور تعقيد الخوارزمية. بالاعتماد على خوارزميات ضرب المصفوفات منخفضة التعقيد مثل Strassen وAlphaTensor، قاموا ببناء إطار عمل موحد لخوارزميات المصفوفات منخفضة التعقيد (LCMA). من خلال الجمع بين لغة QDSL، ودمج العمليات، والنواة المستمرة، والجدولة الدقيقة، ونموذج التكلفة، حوّلوا الميزة النظرية المتمثلة في "تقليل عدد عمليات الضرب" إلى مكاسب فعلية في الأداء على وحدات معالجة الرسومات (GPUs).

في اختبارات FP16 و BF16 لـ NVIDIA H20، يتفوق FalconGEMM على cuBLAS في عدد كبير من أشكال المصفوفات، مع تحسينات في ذروة الأداء تبلغ حوالي 10%-16%، مع الحفاظ على دقة عددية تتوافق بشكل أساسي مع ضرب المصفوفات القياسي في معيار نموذج اللغة.

قامت شركة HyperAI بتجميع وتلخيص المحتوى المشترك دون تغيير معناه الأصلي.

تابع حساب WeChat الرسمي "HyperAI" وقم بالرد باستخدام الكلمة المفتاحية "" في الخلفية.0801 مُجمِّع الذكاء الاصطناعييمكنك الحصول على عرض تقديمي بصيغة PPT للمتحدث المعتمد بالنقر على "...".

انطلاقاً من ستراسن، نعيد فحص فضاء التحسين لضرب المصفوفات.

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

اقترح فولكر ستراسن خوارزمية ستراسن عام 1969. في أبسط عمليات ضرب المصفوفات من الرتبة 2×2، تتطلب الطريقة التقليدية 8 عمليات ضرب، بينما تعتمد خوارزمية ستراسن على إعادة تجميع مصفوفة الإدخال، مما يقلل عدد عمليات الضرب إلى 7 فقط، ثم تستخدم عمليات جمع وطرح إضافية لاستعادة النتيجة النهائية، وهو ما يعادل تقليل عدد عمليات الضرب بمقدار 1/8. إذا كانت المعاملات أعدادًا قياسية فقط، فإن هذا التوفير غير مجدٍ؛ ولكن عندما تصبح المعاملات مصفوفات فرعية، يصبح الفرق في التعقيد بين جمع المصفوفات (O(N²)) وضرب المصفوفات (O(N³)) كبيرًا.وهذا يجعل "إجراء عملية ضرب مصفوفة واحدة أقل والعديد من عمليات جمع المصفوفات الإضافية" ذا قيمة عملية.

إذا تم استخدام خوارزمية ستراسن بشكل تكراري، يمكن تقليل عدد عمليات الضرب بشكل أكبر. على سبيل المثال، يتطلب ضرب مصفوفة كتلية 4×4 تقليديًا 64 عملية ضرب كتلية، بينما يتطلب استخدام طبقتين من خوارزمية ستراسن 49 عملية فقط. مع ذلك، فإن زيادة عدد الطبقات التكرارية تُضيف أيضًا المزيد من عمليات الجمع، وتنظيم البيانات، وعبء الوصول إلى الذاكرة.لذلك، غالباً ما تستخدم الأنظمة العملية عدداً محدوداً من الطبقات فقط، ساعيةً إلى تحقيق التوازن بين تقليل العمليات الحسابية والتكاليف الإضافية.

في عام 2022، وسّع برنامج AlphaTensor من DeepMind هذا النطاق الخوارزمي بشكل أكبر. فهو يحوّل عملية ضرب المصفوفات إلى مسألة تحليل الموترات، ويستخدم التعلم المعزز للبحث عن طرق تحليل ذات رتبة أقل، مما يدل على أنه بالإضافة إلى طريقة ستراسن الكلاسيكية، قد يكون هناك عدد كبير من خوارزميات ضرب المصفوفات المختلفة ذات التعقيد المنخفض في ظل أشكال M وN وK المختلفة.

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

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

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

بعد وضع وصف موحد للخوارزمية، كانت الخطوة التالية هي إيجاد تطبيق مناسب لوحدة معالجة الرسومات (GPU). جرب الفريق CUDA وTriton وTiLang وQDSL. قدمت CUDA أقوى تحكم في الأجهزة، ولكن عند التعامل مع عدد كبير من خوارزميات LCMA المختلفة، تطلبت السجلات والذاكرة المشتركة وهياكل الجمع الوسيطة تعديلات محددة، مما أدى إلى ارتفاع تكاليف التوسعة والصيانة.

يحقق Triton أداءً قريبًا من أداء CUDA في سيناريوهات Strassen الأساسية، ولكن عند توسيع نطاق الخوارزمية لتشمل هياكل كتل أكبر، فإنه يحتاج إلى إعادة استخدام دقيقة لمخازن السجلات عبر عمليات حسابية وسيطة متعددة، مما يجعل Triton عرضةً لتجاوزات إضافية. يوفر TiLang مرونة أكبر في التحكم في السجلات والذاكرة المشتركة، ولكن أداءه في اختبارات الفريق كان لا يزال أقل بنحو 51-101 TP3T من Triton. بالنسبة لـ Strassen الأساسية، مع مكسب نظري يبلغ 12.51 TP3T فقط، فإن هذه الخسارة كبيرة بما يكفي لتقويض مكاسب الخوارزمية.

أخير،اختار الفريق لغة QDSL كواجهة خلفية رئيسية لتنفيذ FalconGEMM. توفر لغة QDSL دقة تطوير قريبة من CUDA، مع امتلاكها أيضًا قدرات توليد التعليمات البرمجية ودعمها لتقنية PTX المدمجة. وهذا يُسهّل عملية نقل التطبيقات عالية الأداء الحالية، وهو مناسب لتوليد التعليمات البرمجية على دفعات بناءً على أوصاف LCMA المختلفة، مما يوفر مرونة أكبر للتكامل اللاحق والتحسين المُخصّص.

من LCMA إلى FalconGEMM، نقل المكاسب الخوارزمية إلى وحدات معالجة الرسومات

يمكن تقسيم أبسط تطبيق لـ Strassen GPU إلى عدة خطوات: دمج المصفوفات الفرعية A و B لتوليد 7 أزواج إدخال جديدة؛ تنفيذ 7 عمليات ضرب مصفوفات عامة مجمعة؛ وأخيرًا دمج مجموعات النتائج الوسيطة السبع في المصفوفة النهائية C. بالمقارنة مع عملية ضرب المصفوفات العامة العادية، فإن جزء ضرب المصفوفات المكثف حسابيًا هو 7/8 فقط من الأصل.لذلك، طالما أن الوقت الإضافي الذي يقضيه في المعالجة المسبقة واللاحقة أقل من 1/8 من الحمل الحسابي الموفر، فهناك فرصة إجمالية لتحقيق فوائد.

أجرى الفريق اختباراته الأولية على معالج NVIDIA H20. يتميز هذا المعالج بنطاق ترددي عالٍ للذاكرة واستهلاك منخفض نسبيًا للقدرة الحسابية القصوى، مما يجعله مناسبًا تمامًا لهذا النهج القائم على "زيادة بعض عمليات معالجة البيانات مقابل تقليل الحمل الحسابي". عند أحجام مصفوفات تبلغ 2048×3 تقريبًا وما فوق، أظهر التطبيق الأساسي مكاسب ثابتة. مع ذلك، عند الأحجام الأصغر، تزداد نسبة دمج المدخلات وكتابة النتائج الوسيطة ودمج المخرجات بسرعة، مما يؤدي بسهولة إلى استهلاك الحمل الحسابي المُوفَّر.

لذا، تحوّل تركيز التحسين اللاحق من نموذج GEMM نفسه إلى الوصول إلى الذاكرة الوسيطة. ويُعدّ دمج العمليات الطريقة الأكثر مباشرة.حاول الاحتفاظ بالنتائج الوسيطة على الشريحة قدر الإمكان، بدلاً من كتابتها بشكل متكرر إلى الذاكرة العامة.مع ذلك، فإن دمج المدخلات A/B مباشرةً في GEMM غير مناسب، لأن نفس الكتلة الفرعية قد تُستخدم بواسطة عدة وحدات SM، مما يؤدي بسهولة إلى تحميل وجمع البيانات بشكل مكرر. في المقابل، يُعد دمج Batched GEMM و Combine H بعد المعالجة أكثر جدوى.

يكمن التحدي الحقيقي في أن نتائج ستراسن السبع الوسيطة تُسهم في المصفوفات الفرعية الأربع النهائية بطرق مختلفة. فإذا استُخدمت H كوحدة متوازية، فقد تكتب عدة مصفوفات فرعية في نفس المصفوفة C في آنٍ واحد، مما يؤدي إلى تعارضات ذرية حادة؛ أما إذا استُخدمت C كوحدة متوازية، فسيتم حساب بعض قيم H بشكل متكرر بواسطة مصفوفات فرعية مختلفة. كلا النهجين يُلغي فوائد تقليل عمليات الضرب.

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

يُقلل هذا النهج المدمج بشكل ملحوظ من عمليات الوصول الإضافية إلى الذاكرة التي يُدخلها خوارزمية ستراسن، إلا أن زيادة دقة المجموعة تؤدي إلى اختلال في توزيع الحمل. فعلى سبيل المثال، عند إجراء عملية ضرب مصفوفة بحجم 4096³، قد يتسبب الجدولة ذات الدقة المنخفضة في هدر ما يقارب 211 TP3T من موارد المعالجة الإضافية، حتى أنها تتجاوز مقدار التخفيض الحسابي الذي تُحققه خوارزمية ستراسن نفسها والبالغ 12.51 TP3T.

تحقيقا لهذه الغاية،استلهم الفريق فكرة تقسيم المجموعة إلى اثنين من وحدات إدارة النظام (SMs) من Stream-K للتنفيذ عند الضرورة.لا تزال طبقة الجدولة تستخدم المجموعة كوحدة أساسية، ولكن يمكن تحسين التنفيذ الفعلي بشكل أكبر إلى البلاطة، مما يقلل من وقت الخمول لوحدة إدارة المهام الخلفية ويحسن استخدام الأجهزة مع الحفاظ على مزايا إعادة استخدام البيانات على مستوى المجموعة.

مع ذلك، بعد حل مشكلة موازنة الأحمال، ظهرت مشكلة جديدة: اختناق ذاكرة التخزين المؤقت من المستوى الثاني (L2). فبعد تقسيم المجموعات، قد تختلط أنواع مختلفة من عمليات الضرب الوسيطة ضمن نفس الموجة، وتصبح البيانات المُستخدَمة مستقلة، مما يؤدي إلى انخفاض ملحوظ في معدل نجاح الوصول إلى ذاكرة التخزين المؤقت من المستوى الثاني. في الوقت نفسه، كان برنامج GEMM يستهلك بالفعل موارد Tensor Cores بكثافة، وعندما يقترب ضغط الوصول إلى الذاكرة من أقصى طاقته، يصل معالج H20 إلى حد استهلاكه للطاقة. في الاختبارات الفعلية، انخفض تردد النواة من حوالي 1.8 جيجاهرتز إلى 1.6 جيجاهرتز، مما أدى إلى انخفاض في الأداء الحسابي، وفقد البرنامج بعضًا من مزايا الدمج مرة أخرى.

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

ومن الجدير بالذكر أنالأساس الرئيسي لتحسينات الجدولة هذه هو النواة المستمرة.على عكس النواة العادية حيث يخرج مُستشار المهام (CTA) بعد إكمال كتلة، تسمح النواة المستمرة لمستشار المهام بالبقاء على خدمة البث (SM) لفترة طويلة، مُستمرًا في قبول المهام اللاحقة. وهذا يمنح المطورين مرونة أكبر في التحكم بترتيب تنفيذ المجموعات والوحدات، ويُمكّن من إعادة استخدام موارد الشريحة. وبالتالي، يُمكن أيضًا إنجاز تقسيم المهام، وإعادة ترتيب الجدولة، وتحسين التخزين المؤقت ضمن النواة نفسها.

من إعادة ترتيب ذاكرة التخزين المؤقت إلى نموذج التكلفة، تحسين الأداء الأقصى 10%-16%

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

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

في هذا النموذج، يُقابل انخفاض عدد عمليات الضرب في الخوارزمية منخفضة التعقيد مكاسب حسابية، بينما تُشكل عمليات دمج البيانات الإضافية والوصول المتكرر إلى الذاكرة عبئًا إضافيًا على الذاكرة؛ ويُقلل تحسين الدمج المذكور آنفًا من تكلفة الوصول إلى الذاكرة هذه. لذلك، يستطيع FalconGEMM تحديد حدود الفائدة لخوارزمية GEMM التقليدية ومخططات LCMA المختلفة بناءً على أشكال M وN وK المختلفة، ويختار تلقائيًا التنفيذ الأنسب.

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

أُجري اختبار الأداء بشكل أساسي على معالج NVIDIA H20. وتُظهر النتائج أنه في سيناريوهات ضرب المصفوفات المختلفة ذات الدقة المنخفضة،يتفوق FalconGEMM على cuBLAS في عدد كبير من الأشكال، مع تحسينات في الأداء القصوى تبلغ حوالي 10%–16%.بعد الانتهاء من تقسيم المجموعة وإعادة ترتيب ذاكرة التخزين المؤقت، يمكن للشكل الكبير الحصول بشكل مستقر على الفوائد الحسابية التي توفرها الخوارزمية منخفضة التعقيد، كما يتم تحسين أداء الشكل الصغير، ويتم تجنب انخفاض التردد الناتج عن جدار الطاقة الناجم عن ارتعاش ذاكرة التخزين المؤقت L2.

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

إلى جانب الأداء، تُعدّ الدقة العددية مسألة بالغة الأهمية يجب على برنامج FalconGEMM التحقق منها. وقد واجه الفريق أخطاءً كبيرة في التجارب الأولية منخفضة الدقة، ويعود ذلك أساسًا إلى تغييرات في ترتيب جمع الأعداد العشرية. فعلى سبيل المثال، A+C+B−C تساوي جبريًا A+B، ولكن في حسابات الأعداد العشرية ذات الدقة المحدودة، لا تكون هاتان القيمتان متطابقتين تمامًا بالضرورة.

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

يُخفف أسلوب الدمج من هذه المشكلة. إذ يحافظ مُخرَج WGMMA على دقة FP32، بينما يقوم FalconGEMM بدمج قيم C النهائية وتجميعها مباشرةً على الشريحة باستخدام FP32، ثم يُعيد تحويلها إلى الدقة المستهدفة بعد اكتمال الحساب. وبالمقارنة مع كتابة النتائج الوسيطة منخفضة الدقة بشكل متكرر بين عدة نوى مستقلة، تُقلل هذه الطريقة من عمليات تحويل الدقة، مما يسمح للأخطاء الناتجة عن تغييرات ترتيب الحساب بالبقاء في البتات الأدنى من FP32.

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

في المرحلة التالية، يخطط الفريق لمواصلة العمل في اتجاهين: أولهما، تعزيز دمج خوارزمية Combine A/B من خلال تعديل ترتيب مجموعات الدفعات وحلقات K لتقليل الوصول إلى الذاكرة لنتائج الإدخال الوسيطة؛ وثانيهما، توسيع نطاق خوارزمية LCMA لتشمل آلية الانتباه. تتميز آلية الانتباه السريع (Flash Attention) بنسبة عالية بين العمليات الحسابية والذاكرة، وإذا أمكن دمج خوارزميات المصفوفات منخفضة التعقيد مع تجزئة الكتل وخطوط المعالجة، فقد تُحقق إمكانات أداء جديدة.

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