معالجة البيانات المتدفقة

الموسوعة الحرة

في علوم الحاسوب ، تُعدّ معالجة التدفقات (المعروفة أيضًا بمعالجة تدفق الأحداث ، أو معالجة تدفق البيانات ، أو معالجة التدفقات الموزعة ) نموذجًا برمجيًا ينظر إلى التدفقات ، أو تسلسلات الأحداث في الزمن، باعتبارها المدخلات والمخرجات المركزية للحساب . تشمل معالجة التدفقات برمجة تدفق البيانات ، والبرمجة التفاعلية ، ومعالجة البيانات الموزعة . [ 1 ] تستخدم أنظمة معالجة التدفقات خوارزميات التدفق لتتبع المعالجة المتوازية لتدفقات البيانات. تتضمن حزمة البرامج لهذه الأنظمة مكونات مثل نماذج البرمجة ولغات الاستعلام ، للتعبير عن الحساب؛ وأنظمة إدارة التدفقات للتوزيع والجدولة ؛ ومكونات الأجهزة للتسريع ، بما في ذلك وحدات الفاصلة العائمة ، ووحدات معالجة الرسومات ، ومصفوفات البوابات المنطقية القابلة للبرمجة الميدانية . [ 2 ]

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

خلال ثمانينيات القرن العشرين، تم استكشاف معالجة البيانات المتدفقة ضمن برمجة تدفق البيانات . ومن الأمثلة على ذلك لغة SISAL .

التطبيقات

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

تُعد معالجة البيانات المتدفقة مناسبة بشكل خاص للتطبيقات التي تتميز بثلاث خصائص:

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

تتضمن أمثلة السجلات داخل التدفقات ما يلي:

  • في الرسومات، قد يتكون كل سجل من معلومات الرأس والمتجه العمودي واللون للمثلث.
  • في معالجة الصور، قد يكون كل سجل عبارة عن بكسل واحد من الصورة.
  • في جهاز ترميز الفيديو، قد يكون كل سجل عبارة عن 256 بكسل، مما يشكل كتلة بيانات كبيرة.
  • في معالجة الإشارات اللاسلكية، يمكن أن يكون كل سجل عبارة عن سلسلة من العينات المستلمة من هوائي.

بالنسبة لكل سجل، تقتصر المعالجة عادةً على القراءة من المدخلات، وإجراء العمليات على البيانات، وكتابة النتيجة إلى المخرجات. من الممكن وجود مدخلات ومخرجات متعددة، ولكن لا تتم قراءة الذاكرة والكتابة إليها في نفس التطبيق. [ 4 ]

أمثلة على التعليمات البرمجية

للتوضيح، تُظهر مقاطع الشفرة التالية كيفية اكتشاف الأنماط ضمن تدفقات الأحداث. يُبين المثال الأول معالجة تدفق بيانات باستخدام استعلام SQL مستمر : وهو استعلام جارٍ يُعالج البيانات الواردة بناءً على الطوابع الزمنية ومدة النافذة. يُوضح مقطع الشفرة هذا عملية ربط بين تدفقين من البيانات: أحدهما يُمثل الأسهم ordersوالآخر يُمثل الأسهم الناتجة trades. [ 5 ] يُخرج الاستعلام تدفقًا لجميع الطلبات التي تطابقت مع صفقة خلال ثانية واحدة من وضع الطلب. يتم فرز تدفق الإخراج حسب الطابع الزمني؛ في هذه الحالة، ينشأ الطابع الزمني من ordersالتدفق نفسه.

حدد DataStream Orders.TimeStamp و Orders.orderId و Orders.ticker و Orders.amount و Trade.amount من جدول Orders مع ربطه بجدول Trades باستخدام ( RANGE INTERVAL ' 1 ' SECOND FOLLOWING ) ON Orders.orderId = Trades.orderId ;​​​​​​​​​

يكشف جزء آخر من نموذج التعليمات البرمجية عن حفلات الزفاف ضمن سلسلة من الأحداث الخارجية، مثل قرع أجراس الكنائس، وظهور رجل يرتدي بدلة رسمية أو بدلة صباحية، وامرأة ترتدي ثوبًا أبيض، ونثر الأرز. الحدث "المركب" أو "المعقد" هو الحدث الرئيسي المستنتج من هذه الأحداث المكونة له: في هذه الحالة، هو وقوع حفل زفاف. [ 6 ]

عندما يكون جنس الشخص يساوي "رجل" وملابس الشخص تساوي "بدلة رسمية" متبوعًا بـ Person.Clothes EQUALS "gown AND (جرس الكنيسة أو أرز طائر) خلال ساعتين حفل زفاف أكشن

مقارنة بالنماذج الموازية السابقة

اعتمدت الحواسيب الأولى على نموذج التنفيذ التسلسلي. تستخدم وحدات المعالجة المركزية التقليدية بنية تعليمات واحدة وبيانات واحدة (SISD) ، أي أنها تُنفذ عملية واحدة في كل مرة. [ 7 ] مع ازدياد متطلبات الحوسبة، نما حجم البيانات المطلوب معالجتها بسرعة، مما كشف عن قصور نماذج البرمجة التسلسلية. ولذلك، تم استكشاف مناهج مختلفة لتمكين الحوسبة واسعة النطاق، وذلك بشكل أساسي من خلال استغلال التنفيذ المتوازي.

كان من أبرز نتائج هذه الجهود تقنية SIMD (تعليمات واحدة، بيانات متعددة) ، وهي بنية تسمح بتعليمات واحدة بالعمل على عناصر بيانات متعددة في آن واحد. في المعالجات الدقيقة للأغراض العامة، تُنفذ تقنية SIMD غالبًا عبر SIMD داخل سجل (SWAR) . ومن خلال دمج هياكل تنفيذ منفصلة لتدفقات التعليمات المختلفة، يمكن أيضًا تحقيق التوازي MIMD (تعليمات متعددة، بيانات متعددة) . [ 7 ] [ 8 ]

على الرغم من فعالية هذه النماذج، إلا أن تطبيقاتها المادية تواجه قيودًا صارمة، بما في ذلك متطلبات محاذاة الذاكرة، وتكاليف التزامن، ومحدودية قابلية التوسع. ونتيجة لذلك، لم ينجُ سوى عدد قليل نسبيًا من معالجات SIMD كمكونات مستقلة؛ حيث تم دمج معظمها في وحدات المعالجة المركزية للأغراض العامة. [ 8 ] [ 9 ]

ومن الأمثلة الأساسية لهذه النماذج برنامج يقوم بإضافة مصفوفتين، تحتوي كل منهما على 100 متجه مكون من أربعة عناصر (بإجمالي 400 قيمة عددية).

النموذج التقليدي المتسلسل

في النموذج التسلسلي القياسي، يتم تنفيذ العملية بشكل تكراري باستخدام حلقة واحدة:

for ( int i = 0 ; i < 400 ; i ++ ) { result [ i ] = source0 [ i ] + source1 [ i ]; }

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

نموذج SIMD المتوازي، سجلات معبأة (SWAR)

// لكل متجه for ( int elem = 0 ; elem < 100 ; elem ++ ) { vectorSum ( result [ elem ], source0 [ elem ], source1 [ elem ]); }

يُقدّم هذا النموذج شرحًا تجريديًا للنموذج من خلال افتراض vector_sumتعليمة عامة. وبينما يعكس هذا التجريد كيفية عمل التعليمات الداخلية عمليًا، فإنه يُغفل تفاصيل التنفيذ المادي الأساسية - مثل تنسيقات البيانات الصريحة وعرض بتات المكونات - من أجل الوضوح.

من خلال العمل على هياكل البيانات المضغوطة، تقلل هذه الطريقة عدد تعليمات الحساب الفردية المطلوبة لمعالجة مكونات المصفوفة. كما يتم تقليل عبء التحكم في الحلقات والقفزات نتيجة لانخفاض عدد التكرارات. وتُعد هذه المكاسب في الكفاءة نتيجة مباشرة لتنفيذ عمليات حسابية متعددة في وقت واحد ضمن خطوة تنفيذ تعليمات واحدة. [ 10 ]

مع ذلك، ولأن سجل SIMD المعبأ له سعة عرض بت ثابتة، فإن قابلية التوسع محدودة بطبيعتها بالحد الأقصى لحجم السجل. في هذه الحالة، يكون تسريع الأجهزة محدودًا بعرض متجه أربع عمليات متوازية، وهو معيار تكوين في بنى مثل AltiVec و Streaming SIMD Extensions (SSE) . [ 11 ]

نموذج التدفق المتوازي (SIMD/MIMD)

// هذه لغة افتراضية لأغراض التوضيح. العناصر = مصفوفة streamElement ([ رقم ، رقم ])[ 100 ] النواة = نسخة streamKernel ( "@arg0[@iter]" ) النتيجة = kernel . invoke ( العناصر )

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

تستطيع المترجمات المُحسّنة لهذا النموذج إجراء تحويلات آلية واسعة النطاق للبرمجيات، مثل فكّ الحلقات . يسمح هذا التجريد بتوسيع نطاق الإنتاجية بسلاسة مع سعة الأجهزة، مما يُتيح استخدام مئات وحدات الحساب والمنطق (ALUs). [ 13 ] [ 14 ] ويضمن تقليل أنماط الوصول المعقدة وغير المتوقعة إلى البيانات إمكانية الوصول إلى نسبة أعلى من ذروة سعة تنفيذ الأجهزة.

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

عند تطبيقها على بنى معمارية عامة مثل وحدات المعالجة المركزية القياسية، غالبًا ما أسفرت تجريدات معالجة البيانات المتدفقة عن مكاسب محدودة في الأداء، حيث أشارت بعض الدراسات التاريخية إلى تسريع التنفيذ بمقدار 1.5 ضعف تقريبًا. [ 16 ] في المقابل، حققت معالجات البيانات المتدفقة المخصصة المبكرة زيادات في الأداء تتجاوز 10 أضعاف، ويعود ذلك أساسًا إلى ملفات التسجيل المُدارة بواسطة الأجهزة المتخصصة ومستويات أعلى من وحدات التنفيذ المتوازية. [ 17 ]

على الرغم من اختلاف مرونة نماذج التنفيذ، فإن أجهزة معالجة البيانات المتدفقة تفرض عمومًا قيودًا صارمة على كلٍ من تعقيد النواة وأحجام أبعاد التدفق. فعلى سبيل المثال، افتقرت أجهزة معالجة الرسومات المخصصة للمستهلكين تاريخيًا إلى دعم العمليات الحسابية عالية الدقة، وإلى إمكانيات توجيه المؤشرات المعقدة، وفرضت حدودًا صارمة على الحد الأقصى لعدد التعليمات. [ 18 ]

بحث

ظهرت الأبحاث المبكرة في مجال معالجة البيانات المتدفقة في أواخر التسعينيات وأوائل الألفية الثانية، مدفوعةً بجهودٍ لزيادة كثافة العمليات الحسابية في خطوط معالجة الرسومات والحوسبة عالية الأداء. وقد ريادت مشاريع أكاديمية، لا سيما في جامعة ستانفورد ، بنى معالجة البيانات المتدفقة المبكرة وتصاميم المترجمات التي أثبتت أهميتها للأجهزة الحديثة المتوازية للبيانات. [ 3 ] [ 19 ] في الوقت نفسه، استكشف باحثون صناعيون، من بينهم فرق في شركة AT&T ، معالجات مُحسَّنة لمعالجة البيانات المتدفقة لتحسين معالجة الإشارات وأحمال عمل الاتصالات، مع التطور السريع في أداء وحدات معالجة الرسومات وقابليتها للبرمجة. [ 1 ] [ 20 ]

في أعقاب هذه الجهود التأسيسية، انتقل النموذج من الأجهزة التجريبية المتخصصة إلى أنظمة البرمجيات السائدة، مما أدى إلى تطوير العديد من لغات وأطر معالجة البيانات المتدفقة المخصصة. [ 12 ]

اعتبارات البرمجة وتخطيط البيانات

يُعدّ تعقيد ربط الخوارزميات ببنى الأجهزة مع الحفاظ على سرعة تطوير البرمجيات وأداء وقت التشغيل تحديًا رئيسيًا في الحوسبة المتوازية. وقد خفّفت أجهزة المعالجة المتدفقة المبكرة، مثل نموذج ستانفورد إيماجين الأولي، من هذا التحدي باستخدام نموذج برمجة أحادي الخيوط يُجرّد تخصيص الذاكرة، وتوابع البيانات، وجدولة الوصول المباشر إلى الذاكرة (DMA) . [ 21 ] وقد انبثق هذا التقسيم للمهام من أبحاث أُجريت في معهد ماساتشوستس للتكنولوجيا (MIT) وجامعة ستانفورد، والتي أظهرت أن المبرمجين البشريين يتمتعون بكفاءة عالية في تقسيم الخوارزميات على مستوى عالٍ، بينما تتفوق أدوات التجميع الآلي في تحسين إجراءات تخصيص الذاكرة المعقدة وجدولة العمليات. [ 22 ] [ 23 ] في المقابل، تنقل بنى المعالجات متعددة النوى غير المتماثلة، مثل محرك النطاق العريض الخلوي ، عبء تقسيم البنية، ومزامنة العمليات، وموازنة الأحمال مباشرةً إلى مطوّر البرمجيات. [ 24 ]

يؤثر تصميم بنية البيانات بشكل كبير على كفاءة تنفيذ النماذج المتوازية، ويتطلب عادةً الاختيار بين مصفوفة من البنى (AoS) وبنية من المصفوفات (SoA) . في هندسة البرمجيات للأغراض العامة، يُمثل المطورون عادةً كيانات البيانات في الذاكرة - على سبيل المثال، موقع جسيم في الفضاء ثلاثي الأبعاد، ولون كرة، وحجمها - كما هو موضح أدناه: [ 25 ]

// جسيم في فضاء ثلاثي الأبعاد. struct Particle { double x ; double y ; double z ;// 8 بت لكل قناة، لنفترض أننا نهتم بنظام ألوان RGB فقط، بايت غير مُوقّع للون [ 3 ]؛ حجم من نوع float ؛ // ... وقد تتبع ذلك العديد من السمات الأخرى... };

عند وجود كيانات متعددة متسلسلة، يتم تخصيصها من طرف إلى طرف، مُشكلةً بنية مصفوفة الهياكل (AoS) . إذا عالجت خوارزمية سمةً واحدةً فقط عبر جميع العناصر - مثل تعديل الإحداثيات ثلاثية الأبعاد فقط - فيجب على محرك التنفيذ تخطي السمات غير المستخدمة في الذاكرة. ولأن خطوط التخزين المؤقت التقليدية تجلب البيانات من الذاكرة في كتل متجاورة، فإن تحميل السمات غير الضرورية يؤدي إلى استخدام غير فعال للتخزين المؤقت وهدر في عرض نطاق الذاكرة . علاوة على ذلك، تتطلب عمليات SIMD القياسية أن تكون عناصر الإدخال متجاورة ومحاذية بشكل صحيح في الذاكرة لملء مسارات المتجهات بكفاءة. [ 25 ]

لتحسين تدفق البيانات وتنفيذ المتجهات، يمكن فصل السمات إلى كتل متوازية منفصلة باستخدام بنية المصفوفات (SoA) . يعزل تمثيل SoA الحقول المتطابقة في مصفوفات فردية متجاورة، كما هو موضح أدناه:

بنية الجسيم { مزدوج * س ؛ مزدوج * ص ؛ مزدوج * ع ؛unsigned byte * colorRed ; unsigned byte * colorBlue ; unsigned byte * colorGreen ;float * size ; };

بينما يُحسّن تصميم بنية المصفوفات (SoA) مسارات البيانات الموحدة، فإنه يُدخل مفاضلات معمارية واضحة. إذا كان على روتين ما أن يعمل في آنٍ واحد على سمات متعددة ومتباينة لكيان واحد، فقد تتواجد هذه السمات متباعدة في الذاكرة الافتراضية ، مما يؤدي إلى أخطاء جسيمة في ذاكرة التخزين المؤقت وزيادة في تكلفة ترجمة العناوين. علاوة على ذلك، فإن ضمان استيفاء كل مصفوفة منفصلة لحدود محاذاة ذاكرة الأجهزة قد يستلزم إضافة بيانات إضافية، مما يزيد من إجمالي مساحة الذاكرة المستخدمة. كما تصبح إدارة الذاكرة الديناميكية معقدة للغاية عند إضافة عناصر أو إزالتها، حيث تتطلب التعديلات نقل العناصر بشكل متزامن عبر مصفوفات متعددة غير متصلة. [ 26 ]

في المقابل، تستخدم بنى معالجة البيانات المتدفقة المخصصة بشكل مكثف تجريدات هيكلية لتوحيد هذه التخطيطات. في خطوط أنابيب رؤوس وحدات معالجة الرسومات (GPU) الحديثة، يوفر الجهاز عددًا ثابتًا من خانات السمات - تاريخيًا، تم توحيدها عند حوالي 16 خط إدخال. [ 27 ] يحدد التطبيق عدد المكونات وتنسيق نوع البيانات لكل تدفق إدخال، على الرغم من أن دعم الجهاز يقتصر عادةً على أنواع البيانات الرقمية الأولية. ترتبط هذه السمات المستقلة بكتلة ذاكرة متماسكة عبر مُعامل خطوة صريح. من خلال ضبط خطوة البايت بين عناصر المصفوفة المتتالية، يمكن للمطورين تنسيق تدفق البيانات إما كمصفوفات متداخلة من الهياكل (AoS) أو هياكل منفصلة من المصفوفات (SoA). في مرحلة التنفيذ، يجمع جهاز GPU تلقائيًا هذه السمات المتباينة في حزمة معلمات موحدة - مثل بنية نواة صريحة أو سجلات عامة مدمجة - وينفذ العمليات بالتوازي، ويوزع نتائج الإخراج إلى مخزن مؤقت للإخراج لمراحل خط أنابيب المعالجة اللاحقة. [ 28 ]

تُقدّم أُطر معالجة البيانات المتدفقة الحديثة تجريدات "الأول في الأول خارج" (FIFO) لتمثيل مسارات تنفيذ البيانات كبنى طوبولوجية منفصلة وموجهة. يسمح هذا التصميم للمطورين بتحديد تبعيات البيانات المتوازية بشكل صريح، مع تمكين بيئة التشغيل من تنسيق تخصيص الذاكرة وحدود الخيوط وجدولة المهام عبر النواة بشفافية. [ 29 ]

يُعدّ RaftLib أحد تطبيقات نموذج البث هذا في لغة C++ ، وهو مكتبة قوالب مفتوحة المصدر تُمكّن المطورين من ربط نوى حسابية مستقلة في رسم بياني لتدفق البيانات باستخدام عوامل تشغيل تدفق C++ المُحمّلة بشكل زائد. [ 30 ] ولتوضيح هذا النموذج، يقوم الكود التالي بتهيئة دفق غير متزامن لتوليد النصوص مرتبط بنواة إخراج قياسية:

استيراد < raft > ; استيراد < raftio > ;استيراد std ؛باستخدام String = std :: string ;باستخدام RaftKernel = raft :: kernel ؛ باستخدام RaftKernelStatus = raft :: kstatus ؛ باستخدام RaftMap = raft :: map ؛ باستخدام RaftPrint = raft :: print ؛class HelloWorld : public RaftKernel { public : HelloWorld () { output . addPort < String > ( "0" ); }virtual RaftKernelStatus run () { output [ "0" ]. push ( "Hello World \n " ); return raft :: stop ; } };int main ( int argc , char * argv []) { // إنشاء نواة الطباعة RaftPrint < String > p ;// إنشاء نواة برنامج Hello World HelloWorld hello ;// إنشاء كائن خريطة RaftMap m ;// إضافة النوى إلى الخريطة، يتم تنفيذ كل من hello و p بشكل متزامن m += hello >> p ;// تنفيذ الخريطة m . exe ();return 0 ; }

نماذج الحوسبة

إلى جانب لغات البرمجة الإجرائية عالية المستوى ، تُبنى تطبيقات معالجة البيانات المتدفقة رسميًا عبر نماذج حسابية متميزة . وتشمل هذه النماذج نماذج تدفق البيانات المهيكلة وأطر العمل المتزامنة القائمة على العمليات (مثل شبكات عمليات كان )، والتي تمثل رياضيًا التبعيات الحسابية ومراحل التنفيذ المتسلسلة. [ 31 ]

مقارنات بين معمارية المعالجات

تاريخيًا، اعتمدت وحدات المعالجة المركزية للأغراض العامة (CPUs) على هياكل وصول إلى الذاكرة متعددة المستويات ومعقدة بشكل متزايد للتخفيف من التفاوت المتزايد في الأداء بين سرعات تنفيذ النواة الخام وعرض نطاق الذاكرة الخارجية. ولإخفاء زمن استجابة الذاكرة هذا، تُخصص نسبة كبيرة من مساحة شريحة وحدة المعالجة المركزية التقليدية لتتبع ذاكرة التخزين المؤقت الآلي، والتنبؤ بالتفرعات، ومنطق التنفيذ التخميني. ونتيجة لذلك، لا يُخصص سوى جزء ضئيل من مساحة الأجهزة - يُقدر تاريخيًا بأقل من 10% - مباشرةً لوحدات الحساب والمنطق (ALUs). [ 32 ]

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

للحفاظ على أعلى إنتاجية، تستخدم معالجات التدفق ناقلات ذاكرة عريضة ومخصصة. اعتمدت التصاميم المبكرة على عوارض متقاطعة متعددة الأجزاء عبر عرض ناقل متفاوت (مثل طوبولوجيات 128 بت أو 256 بت)، مع إعطاء الأولوية لعرض نطاق الذاكرة على زمن الاستجابة. وهذا يختلف عن منصات الحوسبة العددية التقليدية، التي اعتمدت تقليديًا على قنوات ذاكرة أحادية أضيق. علاوة على ذلك، تظل مسارات الوصول إلى الذاكرة داخل محرك التدفق قابلة للتنبؤ بدرجة كبيرة؛ حيث يتم تحديد حدود أبعاد بيانات التدفق بشكل صريح عند استدعاء النواة، مما يحول عمليات التوجيه غير المباشرة متعددة المؤشرات إلى سلاسل توجيه غير مباشرة محدودة تؤدي إلى مناطق ذاكرة تدفق محددة. [ 32 ]

نظراً لتنظيم وحدات التنفيذ في مجموعات حسابية متوازية كثيفة تُدار بواسطة نماذج تحكم VLIW و SIMD المتقاربة ، تتم معالجة عمليات القراءة والكتابة عبر عمليات نقل متدفقة مجمعة. تفصل هذه الأنظمة بيانات التطبيق الوسيطة، وتُنجز غالبية مهام الحساب مباشرةً على الشريحة من خلال تسلسل هرمي واضح لعرض نطاق البيانات ثلاثي المستويات. [ 33 ]

مشاكل الأجهزة في الحلقة

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

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

أمثلة تاريخية وتطور

الهندسة المعمارية المبكرة المخصصة

  • كومودور أميغا بليتر (1985): تطبيق مبكر لمعالجة البيانات على شكل تدفق. عمل جهاز أميغا بليتر كمعالج رسومات مساعد مخصص، قادر على دمج ما يصل إلى ثلاثة مصادر تدفق بتات ذاكرة مختلفة من خلال عمليات منطقية بتية لتوليد تدفق إخراج واحد. نقلت هذه الآلية البيانات بنطاق ترددي إدخال يصل إلى 42 ميغابت في الثانية، متجاوزةً وحدة المعالجة المركزية الرئيسية لتسريع عرض الرسومات ثنائية الأبعاد. [ 36 ]
  • مشروع ستانفورد إيماجن (1996-2002): بتمويل من وكالة مشاريع الأبحاث الدفاعية المتقدمة ( DARPA ) وشركة إنتل وشركة تكساس إنسترومنتس ، كان هذا المشروع البحثي الأكاديمي رائدًا في مجال بنية المعالجة المتدفقة الحديثة. وقد طوّر المشروع شريحة نموذجية مرنة تجمع بين مجموعة من وحدات الحساب والمنطق (ALUs) وملف سجلات متدفقة مركزي مُدار بواسطة برمجيات (SRF) لزيادة كفاءة الطاقة والإنتاجية الحسابية إلى أقصى حد.
  • ستانفورد ميريماك (2004): مبادرة أكاديمية لاحقة وسّعت نطاق بنية Imagine Streaming لتشمل مجال الحوسبة الفائقة. وقد استخدمت شبكات ربط متخصصة لتقديم أداء عالٍ مقابل التكلفة لأحمال العمل الحاسوبية العلمية مقارنةً بأجهزة الحوسبة العنقودية القياسية في عصرها. [ 37 ]
  • معالجات ستريم، ستورم-1 (2007): منتج تجاري منبثق عن مشروع ستانفورد إيماجين. استهدفت بنية ستورم-1 أسواق معالجة الإشارات الرقمية المتطورة، مثل مؤتمرات الفيديو والمراقبة الرقمية. وقد رفعت الأداء من 30 إلى 220 مليار عملية في الثانية (GOPS) من خلال تجميع وحدات الحساب والمنطق المتدفقة على شريحة واحدة.

وحدات معالجة الرسومات (GPUs)

تمثل وحدات معالجة الرسومات الحديثة (GPUs) التطور التجاري الأكثر انتشارًا لمعالجة البيانات المتدفقة. وقد أدى تطورها المعماري إلى تحويل الأجهزة من خطوط أنابيب جامدة ذات وظائف ثابتة إلى محركات تدفق للأغراض العامة: [ 38 ]

  • عصر الوظائف الثابتة (ما قبل عام 2001): لم توفر أجهزة الرسومات المبكرة وصولاً صريحاً للمطورين إلى معالجة البيانات المتدفقة. كانت عمليات البث مُجرّدة بالكامل داخل واجهات برمجة تطبيقات الرسومات (APIs)، مما حدّ من تخصيص الأجهزة.
  • برمجة الرؤوس المبكرة (2001-2002): قدمت البنى الدقيقة مثل ATI R200 وNvidia NV20 تحكمًا صريحًا للمبرمج، ولكن حصريًا لخطوط معالجة الرؤوس. وظلت معالجة الأجزاء/البكسلات مرتبطة بالنماذج القديمة. وقد حدّ غياب التنفيذ المشروط (دعم التفرع) تمامًا من استخدام هذه الرقاقات المبكرة لنماذج رياضية خطية بسيطة، مثل محاكاة ديناميكيات الموائع الأساسية.
  • تدفق التحكم الديناميكي (2003-2004): قدمت بنى معمارية مثل ATI R300 وNvidia NV40 تدفق تحكم مرنًا وتفرعًا. ورغم القيود المفروضة على عدد التعليمات وعمق تداخل الحلقات، سمحت هذه الرقاقات بتفرع تدفقات البيانات بناءً على حالات الحساب أثناء التشغيل.
  • بنى التدفق الموحدة (2006–حتى الآن): قامت الأجيال اللاحقة بتوحيد مسارات معالجة الرؤوس والبكسلات المستقلة في مصفوفات متجانسة من نوى التدفق القابلة للبرمجة. وقد أدخلت التحسينات في الأجهزة آليات تدفق متخصصة، مثل العمليات الذرية على مستوى الأجهزة ومخازن الإلحاق/الاستهلاك الديناميكية، مما أتاح الحوسبة المعقدة للأغراض العامة باستخدام وحدات معالجة الرسومات (GPGPU). وقد أدى هذا التطور إلى ظهور خطوط إنتاج مخصصة لمراكز البيانات للحوسبة عالية الأداء (HPC)، بما في ذلك علامتي Nvidia Tesla وAMD FireStream.

محرك النطاق العريض الخلوي

طُوِّر معالج Cell بواسطة تحالف بين سوني وتوشيبا وآي بي إم (STI)، ويعمل كبنية تدفق هجينة عند اقترانه بسلاسل أدوات برمجية متخصصة. يحتوي المعالج على وحدة تحكم رئيسية - وحدة معالجة الطاقة (PPE) - ومجموعة من المعالجات المساعدة المتجهة تُسمى وحدات المعالجة التآزرية (SPEs). ونظرًا لأن كل وحدة SPE تمتلك مساحة ذاكرة تعليمات مستقلة وعداد برنامج، فإن المعالج يعمل كبيئة متعددة التعليمات والبيانات (MIMD). ومع ذلك، ونظرًا للقيود الشديدة على الذاكرة المحلية، يجب على البرامج استخدام أوامر الوصول المباشر إلى الذاكرة (DMA) الصريحة لتدفق البيانات بشكل متسلسل عبر وحدات SPE. عندما يُعاد هيكلة خوارزميات البرامج بالكامل لتتوافق تمامًا مع نموذج برمجة التدفق هذا، فإن كفاءة تنفيذ الجهاز تُضاهي كفاءة معالجات التدفق المخصصة. [ 24 ]

مكتبات ولغات برمجة البث المباشر

تعتمد معظم أطر معالجة البيانات المتدفقة على لغات برمجة عامة راسخة مثل C و C++ و Java . وتُوسّع هذه الأنظمة إمكانيات اللغة الأساسية من خلال واجهات برمجة تطبيقات مخصصة (APIs)، أو تعليمات برمجية مخصصة للمترجم، أو لغات خاصة بالمجال (DSLs) لتحديد كتل تنفيذ النواة المحدودة وهياكل البيانات المتدفقة. بالإضافة إلى ذلك، تعمل لغات التظليل القابلة للبرمجة عالية المستوى بشكل أساسي كلغات معالجة بيانات متدفقة موجهة للأجهزة. [ 39 ]

البيئات الأكاديمية والمفتوحة المصدر

  • Auto-Pipe: تم تطويره بواسطة مختبر الحوسبة الفائقة القائمة على التدفق (SBS) في جامعة واشنطن في سانت لويس . وهو يوفر بيئة تطوير غير متجانسة تقوم بتنسيق خطوط الأنابيب عبر وحدات المعالجة المركزية (عبر C/C++ أو Java)، ووحدات FPGA (عبر Verilog/VHDL )، ووحدات معالجة الرسومات (عبر CUDA ).
  • BeepBeep: مكتبة معالجة تدفق الأحداث خفيفة الوزن ومبنية على لغة جافا، تم تصميمها بواسطة مختبر علوم الحاسوب الرسمي في جامعة كيبيك في شيكوتيمي .
  • بروك: امتداد أساسي للغة تدفق البيانات المتوازية تم تطويره بواسطة جامعة ستانفورد لتجريد برمجة وحدة معالجة الرسومات.
  • لغة CAL Actor : لغة برمجة عالية المستوى لتدفق البيانات مصممة لكتابة عوامل التشغيل ذات الحالة (الممثلين) التي تحول تدفقات الرموز الواردة إلى تدفقات إخراج حتمية.
  • Cal2Many: إطار عمل للمترجم من جامعة هالمستاد يقوم بترجمة كود CAL عالي المستوى إلى مصدر منخفض المستوى خاص بالهدف، بما في ذلك لغة C المتوازية ونماذج وصف الأجهزة.
  • لغة برمجة DUP : لغة برمجة تدفقية تم تطويرها بشكل متزامن من قبل جامعة ميونخ التقنية وجامعة دنفر .
  • HSTREAM: امتداد للمترجم من المصدر إلى المصدر قائم على التوجيهات مصمم لتسهيل معالجة التدفق عبر موارد تنفيذ وحدة المعالجة المركزية ووحدة معالجة الرسومات غير المتجانسة على غرار أنماط تجميع OpenMP.
  • RaftLib : مكتبة قوالب مفتوحة المصدر مكتوبة بلغة C++ تستخدم عوامل تشغيل تدفق البيانات الأصلية في C++ (>>) لتجميع نوى حسابية متزامنة في بنى تدفق بيانات موحدة. [ 30 ]
  • Sh : مكتبة برمجة أساسية تم تطويرها في جامعة واترلو لتشغيل برامج البث على وحدات معالجة الرسومات، والتي كانت بمثابة قاعدة التعليمات البرمجية لـ RapidMind .
  • S-Net: لغة تنسيق تم تصميمها في جامعة هيرتفوردشاير والتي تفصل تمامًا منطق تنسيق التدفق عن الخوارزميات الهيكلية.
  • SPar: لغة خاصة بمجال C++ صممتها مجموعة نمذجة التطبيقات (GMAP) في الجامعة البابوية الكاثوليكية في ريو غراندي دو سول للتعبير عن التوازي في التدفق عبر التعليقات التوضيحية للسمات.
  • StreamIt: لغة متخصصة وبنية تحتية للمترجمات تم تطويرها في معهد ماساتشوستس للتكنولوجيا مصممة خصيصًا لتحسين خطوط الأنابيب المتوازية.
  • WaveScript: لغة معالجة تدفق وظيفية تم تطويرها في معهد ماساتشوستس للتكنولوجيا وتم تحسينها للتعامل مع تدفقات المستشعرات عالية المعدل وشبكات الإشارات الموزعة.

البنى التجارية والخاصة

  • Embiot (Telchemy) : وكيل تحليلات مضمن خفيف الوزن مصمم لمعالجة تدفقات المستشعرات مباشرة داخل بيئات الحوسبة الطرفية ذات الموارد المحدودة.
  • Floodgate: محرك معالجة تدفق البيانات الذي كان يُدمج تاريخيًا مع محرك Gamebryo لإدارة توزيعات المهام متعددة النوى على أجهزة ألعاب الفيديو الاستهلاكية.
  • Jacket (AccelerEyes) : محرك تجاري مصمم لتجميع وتسريعهياكل الحوسبة MATLAB مباشرة عبر وحدات تدفق GPU.
  • OpenHMPP : نموذج برمجة قائم على التوجيهات مصمم لتبسيط نشر نوى البث على مسرعات متعددة النوى غير متجانسة .
  • PeakStream : شركة تجارية منبثقة عن مشروع ستانفورد بروك، استحوذت عليها جوجل لاحقًا في عام 2007.
  • RapidMind : منصة برمجية تجارية تطورت من مكتبة Sh التابعة لجامعة واترلو، والتي استحوذت عليها شركة إنتل لاحقًا في عام 2009.
  • SPADE (IBM): محرك معالجة البيانات المتدفقة التصريحي، والذي يعمل كلغة أساسية لتدفق البيانات التصريحي لمنصة System S المؤسسية من IBM. [ 40 ]
  • TStreams : وقت تشغيل لتدفق المهام التصريحي تم تطويره في مختبر أبحاث هيوليت-باكارد كامبريدج لاستغلال التزامن متعدد النوى.

لغات الأجهزة الخاصة بالبائع

  • Brook+: تطبيق تجاري مُحسَّن من AMD ومُسرَّع بالأجهزة لإطار عمل لغة Stanford Brook .
  • CUDA (بنية الحوسبة الموحدة للأجهزة) : منصة الحوسبة المتوازية الخاصة بشركة Nvidia ونموذج واجهة برمجة التطبيقات لتنفيذ نوى البث على أجهزة الرسومات.
  • Intel Ct : امتداد لغة C/C++ التاريخي من Intel المصمم لتحويل حلقات البيانات إلى متجهات وتدفقها تلقائيًا عبر المعالجات متعددة النوى.
  • StreamC: لغة معالجة متدفقة طورتها شركة Stream Processors, Inc. ، وتعتمد مباشرة على البنية الدقيقة لمعالج Stanford Imagine.

محركات معالجة الأحداث الموزعة ومعالجة الأحداث المعقدة (CEP)

  • أباتشي نيفي : نظام متكامل للوجستيات البيانات مصمم لأتمتة وإدارة تدفق البيانات المستمر الموجه بين أنظمة البرمجيات.
  • أباما: محرك معالجة الأحداث المعقدة وتحليلات البث عالي الإنتاجية ومنخفض زمن الوصول، تم تطويره بواسطة شركة Software AG.
  • والارو: إطار عمل مفتوح المصدر وموزع لمعالجة تدفق البيانات المرنة، مصمم للتعامل مع المقاييس ذات زمن الاستجابة المنخفض.
  • WSO2 Stream Processor / Siddhi: محرك مفتوح المصدر، أصلي للسحابة، لمعالجة البث والأحداث المعقدة، يقوم باستيعاب وتحليل والتفاعل مع التدفقات في الوقت الفعلي عبر استعلامات تشبه SQL.

أنظمة تنفيذ موزعة وعلى نطاق الحوسبة السحابية

تصنف البنية التحتية الحديثة للبيانات على مستوى المجموعات بنى تدفق البيانات بناءً على نماذج تنفيذها:

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

خدمات البث السحابي المُدارة

  • خدمة أمازون ويب سيرفيسز (AWS) كينيسيس : خدمة سحابية مُدارة للمعالجة في الوقت الفعلي لتدفقات البيانات الموزعة واسعة النطاق.
  • جوجل كلاود داتا فلو : خدمة سحابية مُدارة بالكامل تقوم بتنفيذ خطوط أنابيب معالجة موحدة للتدفقات والدفعات بناءً على بنية أباتشي بيم.
  • IBM Streams / Streaming Analytics: بيئات تنفيذ سحابية ومحلية لتطبيقات البث منخفضة زمن الوصول المكتوبة بلغة SPL .
  • تحليلات Microsoft Azure Stream : محرك معالجة أحداث معقدة مُدار في الوقت الفعلي مصمم لتقييم تدفقات البيانات من التطبيقات وأجهزة إنترنت الأشياء.
  • معالجة تدفق MongoDB Atlas: محرك توجيه تدفق قاعدة بيانات مُدار مصمم لمعالجة وتجميع تغييرات المستندات النشطة بشكل مستمر.
  • SQLStreamBuilder (Eventador): واجهة مُدارة تُمكّن من الكشف المستمر عن الأنماط المعقدة عبر هياكل Kafka من خلال استعلامات SQL التصريحية القياسية.

انظر أيضاً

مراجع

  1. 1 2 مقدمة موجزة لمعالجة البيانات المتدفقة
  2. ↑ FCUDA: تمكين التجميع الفعال لنوى CUDA على FPGAs
  3. 1 2 ريكسنر، سكوت؛ دالي، وليام J.؛ كاباسي، أويفال J.؛ خيلاني، بروسك؛ لوبيز لاغوناس، أبيلاردو؛ ماتسون، بيتر ر. أوينز، جون د. (1998). “بنية فعالة لعرض النطاق الترددي لمعالجة الوسائط” (PDF) . مايكرو . 31 .
  4. ↑ "معالج تدفق البيانات Imagine" . وقائع المؤتمر الدولي IEEE لتصميم الحاسوب: VLSI في الحواسيب والمعالجات . 2002. الصفحات 141-146 . doi : 10.1109/ICCD.2002.1106783 . 
  5. ↑ AliciaLiMicrosoft. "JOIN - استعلام تحليلات البث" . learn.microsoft.com . تم الاسترجاع في 9 يوليو 2026 .
  6. ↑ لوكهام، ديفيد سي. (2002). قوة الأحداث: مقدمة في معالجة الأحداث المعقدة في أنظمة المؤسسات الموزعة . بوسطن: أديسون-ويسلي. ISBN 978-0-201-72789-0.
  7. 1 2 فلين، مايكل ج. (سبتمبر 1972). "بعض تنظيمات الحاسوب وفعاليتها" . معاملات IEEE في مجال الحواسيب . C-21 (9): 948-960 . doi : 10.1109/TC.1972.5009071 . ISSN 1557-9956 . 
  8. 1 2 هينيسي، جون ل.؛ باترسون، ديفيد أ.؛ كوزيراكيس، كريستوس (2026). هندسة الحاسوب: منهج كمي ( الطبعة السابعة). سان فرانسيسكو: مورغان كوفمان للنشر، وهي علامة تجارية تابعة لدار النشر إلسيفير. ISBN  978-0-443-15407-2.
  9. ↑ "أطروحة دكتوراه بعنوان "المعالجات الدقيقة المتجهة" لكرست أسانوفيتش" . people.eecs.berkeley.edu . تاريخ الاسترجاع: 9 يوليو 2026 .
  10. ↑ فيشر، راندال جيه؛ ديتز، هنري جي. (1999). تشاتيرجي، سيدهارتا؛ برينس، جان إف؛ كارتر، لاري؛ فيرانتي، جين؛ لي، تشيوان؛ سيهر، ديفيد؛ يو، بن-تشونغ (محررون). "الترجمة البرمجية لتقنية SIMD ضمن سجل" . اللغات والمترجمات للحوسبة المتوازية . برلين، هايدلبرغ: سبرينغر: 290-305 . doi : 10.1007/3-540-48319-5_19 . ISBN 978-3-540-48319-9.
  11. ↑ "دليل مرجعي لتحسين معمارية Intel® 64 و IA-32، المجلد 1" . Intel . تم الاطلاع عليه بتاريخ 9 يوليو 2026 .
  12. 1 2 3 ستيفنز، روبرت (1997-07-01). "دراسة استقصائية لمعالجة البيانات المتدفقة" . مجلة أكتا إنفورماتيكا . 34 (7): 491-541 . doi : 10.1007/s002360050095 . ISSN 1432-0525 . 
  13. ↑ مجلة IEEE للدوائر المتكاملة: "معالج تدفق قابل للبرمجة 512 GOPS لمعالجة الإشارات والصور والفيديو" ، جامعة ستانفورد وشركة Stream Processors.
  14. ↑ خيلاني، دالي، ريكسنر، كاباسي، أوينز وتولز: "استكشاف قابلية التوسع في VLSI لمعالجات التدفق" ، جامعة ستانفورد وجامعة رايس.
  15. ↑ كاباسي، يو جيه؛ دالي، دبليو جيه؛ آن، جيه إتش؛ ماتسون، بي؛ أوينز، جيه دي (2003). "معالجات التدفق القابلة للبرمجة" . مجلة IEEE Computer . 36 (8).
  16. ↑ غوماراجو وروزنبلوم، "معالجة البيانات المتدفقة في المعالجات ذات الأغراض العامة" ، جامعة ستانفورد.
  17. ↑ كاباسي، دالي، ريكسنر، خيلاني، أوينز، آن وماتسون، "معالجات التدفق القابلة للبرمجة" ، جامعات ستانفورد، رايس، كاليفورنيا (ديفيس) ومختبرات الخزانات.
  18. ↑ أوينز، جون د.؛ لوبك، ديفيد؛ جوفينداراجو، ناجا؛ هاريس، مارك؛ كروجر، ينس؛ ليفون، آرون إي.؛ بورسيل، تيموثي ج. (2005). "دراسة استقصائية للحوسبة للأغراض العامة على أجهزة الرسومات" (ملف PDF) . يوروغرافيكس .
  19. ↑ "نظام تظليل إجرائي في الوقت الحقيقي لأجهزة الرسومات القابلة للبرمجة" . graphics.stanford.edu . تم الاطلاع عليه بتاريخ 9 يوليو 2026 .
  20. ↑ "مشروع ميريماك - ستانفورد للحاسوب العملاق المتدفق" . موقع المجموعة الإلكتروني . مؤرشف من الأصل في 18 ديسمبر 2013. تم الاطلاع عليه في 9 مارس 2017 .
  21. ↑ "هندسة التدفق" . cva.stanford.edu . تم الاطلاع عليه بتاريخ 2026-07-09 .
  22. ↑ "StreamIt" . groups.csail.mit.edu . تم الاطلاع عليه بتاريخ 2026-07-09 .
  23. ↑ ثيس، ويليام؛ كارتشمارك، ميخال؛ أماراسينغ، سامان (2002). "StreamIt: لغة لتطبيقات البث المباشر" (ملف PDF) . CC '02: وقائع المؤتمر الدولي الحادي عشر حول بناء المترجمات .
  24. 1 2 جونز، سي آر؛ بروكنشاير، دي إيه (2007-09-01). "مقدمة إلى بنية محرك النطاق العريض الخلوي" . مجلة آي بي إم للبحوث والتطوير . 51 (5): 503-519 . doi : 10.1147/rd.515.0503 . ISSN 0018-8646 . 
  25. 1 2 هومان، هولجر؛ لينين ، فرانسوا (2017/10/10). "SoAx: هيكل C++ عام للصفائف للتعامل مع الجسيمات في رموز HPC" . arXiv.org . تم الاسترجاع بتاريخ 2026-07-09 .
  26. ↑ شارب، أماندا ك. "تحولات تخطيط الذاكرة" . إنتل . تم الاسترجاع في 2026-07-09 .
  27. ↑ "مواصفات الرؤوس - ويكي OpenGL" . wikis.khronos.org . مؤرشف من الأصل بتاريخ 17 فبراير 2026. تم الاطلاع عليه بتاريخ 9 يوليو 2026 .
  28. ↑ "الخصائص | luma.gl" . luma.gl. مؤرشف من الأصل بتاريخ 19-06-2025 . تم الاطلاع عليه بتاريخ 09-07-2026 .
  29. ↑ بيرد، جيه سي؛ لي، بي؛ تشامبرلين، آر دي (2015). "RaftLib: مكتبة قوالب C++ لمعالجة البيانات المتوازية عالية الأداء" (ملف PDF) . المؤتمر الدولي للبرمجة المتوازية . doi : 10.1145/2712386.2712400 .
  30. 1 2 RaftLib/RaftLib ، RaftLib، 2026-07-08 ، تم الاسترجاع في 2026-07-09
  31. ↑ لي، إي إيه؛ باركس، تي إم (1995). "شبكات معالجة تدفق البيانات" (ملف PDF) . وقائع معهد مهندسي الكهرباء والإلكترونيات . 83 (5): 773-801 .
  32. 1 2 3 دالي، دبليو جيه؛ كاباسي، يو جيه؛ خيلاني، بي؛ آهن، جيه إتش (2004). معالجة البيانات المتدفقة على برنامج Imagine (ملف PDF) . مختبر أنظمة الحاسوب بجامعة ستانفورد.
  33. 1 2 ريكسنر، س. (2001). بنية معالج التدفق (دكتوراه). جامعة ستانفورد.
  34. ↑ دالي، بيل (28 مايو 2002). "نظرة عامة على معالجة البيانات المتدفقة" (ملف PDF) .
  35. ↑ تراب، ماتياس؛ دولنر، يورغن (2007-07-03). "الدمج الآلي لبرامج التظليل في الوقت الحقيقي" . ورقة بحثية قصيرة من مؤتمر يوروغرافيكس 2007 : 53-56 .
  36. ↑ كومودور-أميغا، إنك، محرر (1989). دليل مرجعي لأجهزة أميغا . سلسلة المراجع التقنية لأميغا (طبعة منقحة ومحدثة ). ريدينغ، ماساتشوستس: أديسون-ويسلي. ISBN  978-0-201-18157-9.
  37. ↑ دالي، ويليام جيه؛ لابونت، فرانسوا؛ داس، أبيشيك؛ هانراهان، باتريك؛ آهن، جونغ-هو؛ غوماراجو، جايانث؛ إيريز، ماتان؛ جاياسينا، نوان؛ باك، إيان؛ نايت، تيموثي جيه؛ كاباسي، أوجفال جيه. (15 نوفمبر 2003). "ميريماك: الحوسبة الفائقة باستخدام التدفقات" . SC '03: وقائع مؤتمر ACM/IEEE للحوسبة الفائقة لعام 2003. ACM: 35. doi : 10.1145/1048935.1050187 . ISBN 978-1-58113-695-1.
  38. ↑ "CSDL | جمعية IEEE للحاسبات" . www.computer.org . تم الاطلاع عليه بتاريخ 9 يوليو 2026 .
  39. ↑ ميميتي، سوجب؛ بلانا، صبري (أكتوبر 2018). "HSTREAM: امتداد لغوي قائم على التوجيهات للحوسبة المتدفقة غير المتجانسة" . المؤتمر الدولي لهندسة وعلوم الحوسبة IEEE لعام 2018 : 138-145 . doi : 10.1109/CSE.2018.00026 .
  40. ↑ جيديك، بوغرا؛ أندرادي، هنريك؛ وو، كون-لونغ؛ يو، فيليب س.؛ دو، ميونغتشول (9 يونيو 2008). "SPADE: محرك معالجة تدفق البيانات التصريحي للنظام" . وقائع مؤتمر ACM SIGMOD الدولي لإدارة البيانات لعام 2008. SIGMOD '08. نيويورك، نيويورك، الولايات المتحدة الأمريكية: رابطة آلات الحوسبة: 1123-1134 . doi : 10.1145/1376616.1376729 . ISBN 978-1-60558-102-6.