پردازش جریان

از ویکیپدیا، دانشنامه آزاد
رفتن به ناوبری پرش به جستجو

پردازش جریان یکپارادایم برنامه نویسی کامپیوتری است ، معادل برنامه نویسی جریان داده ، پردازش جریان رویداد و برنامه نویسی واکنشی ، [1] که به برخی برنامه ها اجازه می دهد به راحتی از شکل محدودی از پردازش موازی بهره برداری کنند. چنین برنامه هایی می توانند از واحدهای محاسباتی متعددی مانند واحد نقطه شناور در واحد پردازش گرافیکی یا آرایه های دروازه ای قابل برنامه ریزی زمینه ای (FPGA) ، [2] بدون مدیریت صریح تخصیص ، همگام سازی یا ارتباط بین آن واحدها استفاده کنند.

پارادایم پردازش جریان با محدود کردن محاسبات موازی که می تواند انجام دهد ، نرم افزار و سخت افزار موازی را ساده می کند. با توجه به دنباله ای از داده ها (یک جریان ) ، یک سری عملیات ( توابع هسته ) برای هر عنصر در جریان اعمال می شود. توابع هسته معمولاً به صورت خط لوله هستند و استفاده مجدد بهینه از حافظه محلی روی تراشه به منظور به حداقل رساندن از دست دادن پهنای باند ، مرتبط با تعامل حافظه خارجی ، انجام می شود. جریان یکنواخت ، جایی که یک تابع هسته برای همه عناصر جریان اعمال می شود ، معمولی است. از آنجا که هسته و انتزاعات جریان وابستگی داده ها را آشکار می کند ، ابزارهای کامپایلر می توانند وظایف مدیریت تراشه را به طور کامل خودکار کرده و بهینه کنند. سخت افزار پردازش جریان می تواند از امتیازدهی استفاده کندبه عنوان مثال ، برای شروع دسترسی مستقیم به حافظه (DMA) هنگامی که وابستگی ها مشخص می شوند. حذف مدیریت دستی DMA پیچیدگی نرم افزار را کاهش می دهد ، و حذف مربوط به سخت افزار I/O ذخیره شده ، وسعت ناحیه داده ای را که باید توسط واحدهای محاسباتی تخصصی مانند واحدهای منطق حسابی درگیر خدمات باشد ، کاهش می دهد .

در طول دهه 1980 پردازش جریان در برنامه نویسی جریان داده مورد بررسی قرار گرفت . به عنوان مثال می توان به زبان SISAL (جریان و تکرار در یک زبان تکلیف واحد) اشاره کرد.

برنامه های کاربردی

پردازش جریان در اصل یک سازش است که توسط یک مدل داده محوری هدایت می شود که برای برنامه های سنتی DSP یا GPU (مانند پردازش سیگنال تصویر ، ویدئو و دیجیتال ) بسیار خوب عمل می کند ، اما برای پردازش های عمومی با دسترسی بیشتر به داده های تصادفی کمتر ( مانند پایگاه های داده). با فدا کردن انعطاف پذیری در مدل ، مفاهیم امکان اجرای آسان تر ، سریعتر و کارآمدتر را فراهم می کند. بسته به زمینه ، ممکن است طراحی پردازنده برای حداکثر کارایی یا یک انعطاف پذیری مناسب باشد.

پردازش جریان به ویژه برای برنامه هایی مناسب است که دارای سه ویژگی کاربردی هستند: [ نیاز به ذکر منبع ]

  • شدت محاسبه ، تعداد عملیات حسابی در هر ورودی/خروجی یا مرجع حافظه جهانی. امروزه در بسیاری از برنامه های پردازش سیگنال بیش از 50: 1 است و با پیچیدگی الگوریتمی افزایش می یابد.
  • موازی کاری داده ها در صورتی وجود دارد که یک تابع یکسان برای همه رکوردهای یک جریان ورودی اعمال شود و تعدادی از رکوردها به طور همزمان بدون انتظار نتایج از رکوردهای قبلی پردازش شوند.
  • محل داده یک نوع خاص از مکان زمانی است که در برنامه های پردازش سیگنال و رسانه رایج است ، جایی که داده ها یک بار تولید می شوند ، یک یا دو بار بعداً در برنامه خوانده می شوند و هرگز دوباره نمی خوانند. جریانهای میانی بین هسته ها و همچنین داده های متوسط ​​در توابع هسته می توانند این منطقه را مستقیماً با استفاده از مدل برنامه نویسی پردازش جریان تصرف کنند.

نمونه هایی از سوابق در جریانها عبارتند از:

  • در گرافیک ، هر رکورد ممکن است اطلاعات راس ، عادی و رنگ یک مثلث باشد.
  • در پردازش تصویر ، هر رکورد ممکن است یک پیکسل از یک تصویر باشد.
  • در رمزگذار ویدئو ، هر رکورد ممکن است 256 پیکسل باشد که یک بلوک کلان داده را تشکیل می دهد. یا
  • در پردازش سیگنال بی سیم ، هر رکورد می تواند دنباله ای از نمونه های دریافت شده از آنتن باشد.

برای هر رکورد فقط می توانیم از ورودی بخوانیم ، روی آن عملیات انجام دهیم و در خروجی بنویسیم. مجاز است چندین ورودی و چند خروجی داشته باشید ، اما هرگز قسمتی از حافظه که هم قابل خواندن باشد و هم قابل نوشتن باشد.

مقایسه با پارادایم های موازی قبلی

کامپیوترهای اصلی از یک الگوی اجرایی متوالی شروع به کار کردند. پردازنده های سنتی مبتنی بر SISD هستند ، به این معنی که آنها به طور مفهومی فقط یک عملیات را در یک زمان انجام می دهند. با تکامل نیازهای محاسباتی جهان ، حجم داده های مدیریت شده به سرعت افزایش می یابد. واضح بود که مدل برنامه نویسی متوالی نمی تواند با افزایش نیاز به قدرت پردازشی کنار بیاید. تلاشهای مختلفی برای یافتن راههای جایگزین برای انجام حجم زیادی از محاسبات هزینه شده است ، اما تنها راه حل این بود که از سطحی از اجرای موازی استفاده کرد. نتیجه این تلاشها SIMD بود ، یک الگوی برنامه نویسی که اجازه می داد یک دستورالعمل را در موارد مختلف داده (متفاوت) اعمال کند. بسیاری از اوقات، SIMD که در یک مورد استفاده قرار گرفت SWARمحیط. با استفاده از ساختارهای پیچیده تر ، می توان موازی سازی MIMD نیز داشت .

اگرچه آن دو پارادایم کارآمد بودند ، اما پیاده سازی های دنیای واقعی با محدودیت هایی از مشکلات همسویی حافظه تا مسائل همگام سازی و موازی سازی محدود روبرو بودند. تنها چند پردازنده SIMD به عنوان قطعات مستقل زنده ماندند. اکثر آنها در CPU های استاندارد جاسازی شده بودند.

یک برنامه ساده را در نظر بگیرید که دو آرایه شامل 100 بردار 4 جزء (یعنی در مجموع 400 عدد) را جمع می کند.

الگوی مرسوم و متوالی

برای  ( int  i  =  0 ؛  i  <  400 ؛  i ++ ) 
    نتیجه [ i ]  =  source0 [ i ]  +  source1 [ i ] ؛

این پارادایم متوالی است که بیشتر آشنا است. تغییرات وجود دارد (مانند حلقه های داخلی ، ساختارها و موارد دیگر) ، اما در نهایت به همین ساختار می انجامد.

پارادایم SIMD موازی ، ثبت های بسته بندی شده (SWAR)

برای  ( int  el  =  0 ؛  el  <  100 ؛  el ++ )  // برای هر بردار 
    برآورد_جمله ( نتیجه [ el ] ،  source0 [ el ] ،  source1 [ el ]) ؛

این در واقع بیش از حد ساده شده است. فرض می کند که دستورالعمل vector_sumکار می کند. اگرچه این چیزی است که در مورد دستورالعمل ذاتی اتفاق می افتد ، اما در واقع اطلاعات زیادی مانند تعداد اجزای بردار و قالب داده آنها در اینجا مورد توجه قرار نمی گیرد. این برای شفافیت انجام می شود.

با این حال ، می توانید ببینید که این روش تعداد دستورات رمزگشایی شده از numElements * componentsPerElement را به numElements کاهش می دهد . تعداد دستورات پرش نیز کاهش می یابد ، زیرا حلقه کمتر اجرا می شود. این دستاوردها از اجرای موازی چهار عمل ریاضی حاصل می شود.

اما آنچه اتفاق افتاد این است که رجیستر بسته بندی شده SIMD مقدار مشخصی داده را در خود نگه می دارد ، بنابراین امکان ایجاد موازی کاری بیشتر وجود ندارد. با فرض انجام چهار عملیات موازی ، سرعت افزایش تا حدودی محدود می شود (لطفاً توجه داشته باشید که این مورد برای AltiVec و SSE معمول است ).

پارادایم جریان موازی (SIMD/MIMD)

// این یک زبان تخیلی برای اهداف تظاهرات است. 
عناصر  =  آرایه  streamElement ([ تعداد ،  شماره ]) [ 100 ] 
هسته  =  نمونه  streamKernel ( "@arg0 [iter]" ) 
result  =  kernel . فراخوانی ( عناصر )

در این پارادایم ، کل مجموعه داده تعریف می شود ، نه اینکه هر بلوک جزء به طور جداگانه تعریف شود. توصیف مجموعه داده ها در دو ردیف اول فرض می شود. پس از آن ، نتیجه از منابع و هسته استنباط می شود. برای سادگی ، نگاشت 1: 1 بین داده های ورودی و خروجی وجود دارد ، اما نیازی به این نیست. هسته های کاربردی نیز می توانند بسیار پیچیده تر باشند.

پیاده سازی این پارادایم می تواند یک حلقه داخلی را "باز کند". این اجازه می دهد تا توان با پیچیدگی تراشه مقیاس بندی شود و به راحتی از صدها ALU استفاده شود. [3] [4] حذف الگوهای داده پیچیده ، بیشتر این قدرت اضافی را در دسترس قرار می دهد.

در حالی که پردازش جریان شاخه ای از پردازش SIMD/MIMD است ، نباید آنها را اشتباه گرفت. اگرچه پیاده سازی های SIMD اغلب می توانند به صورت "جریان" کار کنند ، اما عملکرد آنها قابل مقایسه نیست: مدل الگوی استفاده بسیار متفاوتی را پیش بینی می کند که به خودی خود عملکرد بسیار بیشتری را امکان پذیر می کند.

توجه شده است که وقتی روی پردازنده های عمومی مانند CPU استاندارد اعمال می شود ، تنها می توان به سرعت 1.5 برابر رسید. [5] در مقابل ، پردازنده های جریان موقت به راحتی به بیش از 10 برابر عملکرد می رسند ، که عمدتا به دسترسی کارآمدتر به حافظه و سطوح بالاتر پردازش موازی نسبت داده می شود. [6]

اگرچه انواع مختلفی از انعطاف پذیری توسط مدل مجاز است ، پردازنده های جریان معمولاً محدودیت هایی را بر هسته یا اندازه جریان اعمال می کنند. به عنوان مثال ، سخت افزارهای مصرف کننده اغلب توانایی انجام ریاضیات با دقت بالا را ندارند ، فاقد زنجیره پیچیده غیرمستقیم یا محدودیت کمتری در تعداد دستورالعمل های قابل اجرا هستند.

تحقیق

پروژه های پردازش جریان دانشگاه استنفورد شامل پروژه سایه زنی قابل برنامه ریزی استنفورد در سال 1999 بود. [7] نمونه اولیه ای به نام Imagine در سال 2002 توسعه یافت. [8] پروژه ای به نام Merrimac تا حدود 2004 اجرا شد. [9] AT&T همچنین در مورد جریان پردازنده های پیشرفته به عنوان واحدهای پردازش گرافیکی به سرعت در هر دو سرعت و عملکرد تکامل یافتند. [1] از همان روزهای اولیه ، ده ها زبان پردازش جریان و همچنین سخت افزار تخصصی توسعه یافته است.

یادداشت های مدل برنامه نویسی

فوری ترین چالش در حوزه پردازش موازی به نوع معماری سخت افزاری مورد استفاده بستگی ندارد ، بلکه برنامه ریزی سیستم مورد نظر در محیطی واقعی با عملکرد قابل قبول چقدر آسان است. ماشین هایی مانند Imagine از یک مدل تک رشته ای با وابستگی های خودکار ، تخصیص حافظه و زمانبندی DMA استفاده می کنند . این به خودی خود نتیجه تحقیقات MIT و استنفورد در یافتن لایه بندی بهینه وظایف بین برنامه نویس ، ابزار و سخت افزار است. برنامه نویسان در نگاشت الگوریتم ها به سخت افزار موازی ، ابزارها و برنامه نویسان را در کشف هوشمندترین طرح های تخصیص حافظه و غیره مورد توجه قرار می دهند. طرح های MIMD مانند Cell، که برای آن برنامه نویس باید با پارتیشن بندی برنامه در چندین هسته برخورد کند و با همگام سازی فرایند و متعادل سازی بار برخورد کند. امروزه ابزارهای برنامه نویسی چند هسته ای کارآمد به شدت وجود ندارد.

اشکال برنامه نویسی SIMD مسئله Array-of-Structures (AoS) و Structure-of-Arrays (SoA) بود . برنامه نویسان اغلب می خواستند ساختارهای داده با معنای "واقعی" بسازند ، برای مثال:

 // ذره ای در فضای سه بعدی. 
struct  particle_t  { 
    شناور  x ،  y ،  z ؛           // حتی یک آرایه! 
    رنگ بایت بدون علامت  [ 3 // 8 بیت در هر کانال ، بگویید ما فقط به اندازه شناور RGB اهمیت می دهیم . // ... و بسیاری از ویژگیهای دیگر ممکن است دنبال شود ... } ؛  
     
    

آنچه اتفاق افتاد این است که آن ساختارها سپس در آرایه هایی جمع آوری شدند تا همه چیز به خوبی سازماندهی شود. این مجموعه ای از ساختارها است(AoS). هنگامی که ساختار در حافظه قرار می گیرد ، کامپایلر داده های ترکیبی تولید می کند ، به این معنا که همه ساختارها به هم متصل هستند ، اما بین مثال ، ویژگی "اندازه" یک نمونه ساختار و همان عنصر یک جابجایی ثابت وجود دارد. از نمونه زیر افست به تعریف ساختار بستگی دارد (و احتمالاً موارد دیگری که در اینجا مانند سیاست های کامپایلر در نظر گرفته نشده است). مشکلات دیگری نیز وجود دارد. به عنوان مثال ، سه متغیر موقعیت را نمی توان به این شکل SIMD کرد ، زیرا مطمئن نیست که آنها در فضای ممتد حافظه اختصاص داده شوند. برای اطمینان از اینکه عملیات SIMD می تواند روی آنها کار کند ، آنها باید در یک "مکان حافظه بسته" یا حداقل در یک آرایه گروه بندی شوند. مشکل دیگر در "رنگ" و "xyz" نهفته استدر مقادیر بردار سه جزء تعریف شود. پردازنده های SIMD معمولاً فقط از عملیات 4 جزء پشتیبانی می کنند (البته برخی استثنائات).

این نوع مشکلات و محدودیت ها باعث می شود که شتاب SIMD در پردازنده های استاندارد بسیار تند و زننده باشد. راه حل پیشنهادی ، ساختار آرایه ها (SoA) به شرح زیر است:

struct  particle_t  { 
    float  * x ،  * y ،  * z ؛ 
    بایت بدون امضا  * colorRed ، * colorBlue ، * colorGreen ؛ شناور * اندازه ؛    
     

برای خوانندگانی که با C تجربه ندارند ، '*' قبل از هر شناسه به معنای اشاره گر است. در این حالت ، از آنها برای اشاره به اولین عنصر آرایه استفاده می شود که بعداً اختصاص داده می شود. برای برنامه نویسان جاوا ، این تقریباً معادل "[]" است. اشکال در اینجا این است که ویژگی های مختلف می توانند در حافظه پخش شوند. برای اطمینان از این که باعث از بین رفتن حافظه پنهان نمی شود ، باید همه "قرمز" های مختلف ، سپس همه "سبزها" و "آبی ها" را به روز کنیم.

برای پردازنده های جریان ، استفاده از ساختارها تشویق می شود. از نظر کاربردی ، همه ویژگی ها را می توان با کمی انعطاف پذیری تعریف کرد. با در نظر گرفتن GPU ها به عنوان مرجع ، مجموعه ای از ویژگی ها (حداقل 16) در دسترس است. برای هر ویژگی ، برنامه می تواند تعداد اجزا و قالب اجزا را بیان کند (اما در حال حاضر فقط انواع داده های اولیه پشتیبانی می شوند). سپس ویژگی های مختلف به یک بلوک حافظه متصل می شوند ، احتمالاً گامی بین عناصر "متوالی" از ویژگی های یکسان تعیین می شود ، و به طور م allowingثر به داده های درون برگشته اجازه می دهد. هنگامی که پردازنده گرافیکی پردازش جریان را آغاز می کند ، تمام ویژگی های مختلف را در یک مجموعه واحد از پارامترها جمع آوری می کند (معمولاً این یک ساختار یا یک "متغیر جهانی جادویی" به نظر می رسد) ، عملیات را انجام می دهد ونتایج را برای پردازش بعدی (یا بازیابی) به برخی از مناطق حافظه پراکنده می کند.

چارچوب های پردازش جریان مدرن تر ، یک رابط شبیه FIFO برای ساختار داده ها به عنوان یک جریان واقعی ارائه می دهند. این چکیده ابزاری را برای تعیین وابستگی داده به طور ضمنی فراهم می کند در حالی که زمان اجرا/سخت افزار را قادر می سازد از مزایای کامل آن دانش برای محاسبات کارآمد استفاده کند. یکی از ساده ترین روشهای پردازش جریان [برای نقل قول مورد نیاز ] و کارآمدترین [برای نقل قول ] تا به امروز برای C ++ ، RaftLib است ، که هسته های محاسبه مستقل را با هم به عنوان نمودار جریان داده با استفاده از عملگرهای جریان C ++ پیوند می دهد. به عنوان مثال:

#شامل  <raft> شود
#شامل  <raftio>
#شامل  <cstdlib>
#شامل  <string> شود

class  hi  :  public  raft :: kernel 
{ 
public : 
    hi ()  :  raft :: kernel () 
    { 
       خروجی . addPort <  std :: string  > (  "0"   
    }

     قایق مجازی :: kstatus  run () 
    { 
        خروجی [  "0"  ]. push (  std :: string (  "سلام جهان \ n "  )  
        بازگشت (  قایق :: توقف  ) ؛  
    } 


int 
main (  int  argc ،  char  ** argv  ) 
{ 
    / ** هسته چاپ فوری ** / 
    raft :: print <  std :: string  >  p ؛ 
    / ** سلام هسته فوری جهان **/ 
    سلام  سلام ؛ 
    / ** ایجاد یک شیء نقشه **/ 
    raft :: map  m ؛ 
    / ** افزودن هسته به نقشه ، هر دو hello و p همزمان اجرا می شوند **/ 
    m  +=  hello  >>  p ؛ 
    / ** نقشه را اجرا کنید **/ 
    m . exe ()؛
    بازگشت (  EXIT_SUCCESS  ) ؛ 
}

مدلهای محاسبه برای پردازش جریان

مدلهای محاسبه (MoCs) جدا از مشخص کردن برنامه های جاری به زبانهای سطح بالا ، به طور گسترده ای به عنوان مدلهای جریان داده و مدلهای مبتنی بر فرایند استفاده می شوند.

معماری پردازنده عمومی

از لحاظ تاریخی ، CPU ها به دلیل افزایش عملکرد در مقایسه با پهنای باند حافظه خارجی نسبتاً آهسته ، پیاده سازی سطوح مختلف بهینه سازی دسترسی به حافظه را آغاز کردند. با افزایش این شکاف ، مقادیر زیادی از ناحیه قالب برای پنهان کردن تاخیرهای حافظه اختصاص داده شد. از آنجا که دریافت اطلاعات و کدگذاری برای آن چند ALU گران است ، منطقه بسیار کمی به ماشین های ریاضی واقعی اختصاص داده می شود (به عنوان یک تخمین تقریبی ، آن را کمتر از 10 consider در نظر بگیرید).

معماری مشابهی در پردازنده های جریان وجود دارد اما به لطف مدل برنامه نویسی جدید ، میزان ترانزیستورهای اختصاص داده شده به مدیریت در واقع بسیار اندک است.

پردازنده های جریان از نقطه نظر کل سیستم ، معمولاً در یک محیط کنترل شده وجود دارند. پردازنده های گرافیکی در یک برد افزودنی وجود دارد (به نظر می رسد این امر در Imagine نیز صدق می کند ). CPU ها کار کثیف مدیریت منابع سیستم ، اجرای برنامه ها و موارد دیگر را انجام می دهند.

پردازنده جریان معمولاً مجهز به یک گذرگاه حافظه سریع ، کارآمد و اختصاصی است (سوئیچ های عرضی در حال حاضر متداول هستند ، در گذشته از چند باس استفاده می شده است). میزان دقیق خطوط حافظه بستگی به محدوده بازار دارد. همانطور که نوشته شده است ، هنوز اتصالات گسترده 64 بیتی در اطراف (سطح ابتدایی) وجود دارد. اکثر مدل های میان رده از ماتریس سوئیچ سریع 128 بیتی سریع (4 یا 2 بخش) استفاده می کنند ، در حالی که مدل های سطح بالا حجم زیادی از حافظه (در واقع تا 512 مگابایت) را با یک نوار عرضی کمی کندتر که عرض آن 256 بیت است ، به کار می گیرند. در مقابل ، پردازنده های استاندارد از Intel Pentium تا Athlon 64 تنها دارای یک گذرگاه داده 64 بیتی هستند.

الگوهای دسترسی به حافظه بسیار قابل پیش بینی تر است. در حالی که آرایه ها وجود دارند ، ابعاد آنها در فراخوانی هسته ثابت می شود. چیزی که بیشتر با یک غیر مستقیم چند اشاره گر مطابقت دارد ، یک زنجیره غیرمستقیم است ، اما به هر حال تضمین می شود که در نهایت از یک ناحیه حافظه خاص (داخل یک جریان) بخواند یا بنویسد.

به دلیل ماهیت SIMD واحدهای اجرایی پردازنده جریان (خوشه های ALU) ، انتظار می رود عملیات خواندن/نوشتن به صورت عمده انجام شود ، بنابراین حافظه ها برای پهنای باند زیاد و نه با تاخیر کم بهینه می شوند (این تفاوت با Rambus و DDR SDRAM است ، برای مثال). این همچنین امکان مذاکرات کارآمد باس حافظه را فراهم می کند.

بیشتر (90)) کار پردازنده جریان روی تراشه انجام می شود و تنها 1 of از کل داده های جهانی باید در حافظه ذخیره شوند. اینجاست که دانستن زمان و وابستگی های هسته مفید است.

از نظر داخلی ، یک پردازنده جریان دارای برخی مدارات ارتباطی و مدیریت هوشمند است ، اما آنچه جالب است پرونده ثبت جریان (SRF) است. این از نظر مفهومی یک حافظه پنهان بزرگ است که در آن داده های جریان ذخیره می شوند تا به صورت انبوه به حافظه خارجی منتقل شوند. به عنوان یک ساختار نرم افزاری شبیه به حافظه پنهان برای ALU های مختلف، SRF بین تمام خوشه های مختلف ALU به اشتراک گذاشته می شود. مفهوم کلیدی و نوآوری که در اینجا با تراشه استنفورد Imagine انجام می شود این است که کامپایلر قادر است حافظه را به صورت مطلوب و کاملاً شفاف برای برنامه نویس به صورت خودکار و اختصاص دهد. وابستگی بین توابع هسته و داده ها از طریق مدل برنامه نویسی مشخص می شود که کامپایلر را قادر می سازد تا تجزیه و تحلیل جریان را انجام دهد و SRF ها را به طور مطلوب بسته بندی کند. به طور معمول ، این حافظه نهان و مدیریت DMA می تواند اکثر برنامه های پروژه را به خود اختصاص دهد ، چیزی که پردازنده جریان (یا حداقل تصور کنید) کاملاً خودکار می کند. آزمایشات انجام شده در استنفورد نشان داد که کامپایلر در برنامه ریزی حافظه عملکرد بهتری یا بهتر از زمانی که شما آن را با تلاش زیاد تنظیم کرده اید ، انجام داده است.

مدرکی وجود دارد ؛ ممکن است خوشه های زیادی وجود داشته باشد زیرا فرض بر این است که ارتباط بین خوشه ای نادر است. از نظر داخلی ، هر خوشه می تواند از مقدار بسیار کمتری از ALU ها به طور مثر استفاده کند ، زیرا ارتباطات درون خوشه ای متداول است و بنابراین باید بسیار کارآمد باشد.

برای نگه داشتن این ALU ها با داده ها ، هر ALU مجهز به پرونده های ثبت محلی (LRF) است که اساساً رجیسترهای قابل استفاده آن هستند.

این الگوی دسترسی به داده های سه لایه ، دور نگه داشتن داده های موقت را از حافظه های کند آسان می کند ، بنابراین اجرای سیلیکون را بسیار کارآمد و در مصرف انرژی صرفه جویی می کند.

مشکلات سخت افزاری در حلقه

اگرچه می توان به طور قابل ملاحظه ای از سرعت بالایی انتظار داشت (حتی از پردازنده های گرافیکی اصلی هنگام محاسبه به صورت جریان) ، اما همه برنامه ها از این مزیت برخوردار نیستند. تأخیرهای ارتباطی در واقع بزرگترین مشکل هستند. اگرچه PCI Express این امر را با ارتباطات دو طرفه بهبود بخشید ، اما کارکردن GPU (و احتمالاً پردازنده جریان عمومی) به احتمال زیاد زمان زیادی طول می کشد. این بدان معناست که استفاده از آنها برای مجموعه های داده کوچک معمولاً غیرمولد است. از آنجا که تغییر هسته یک عملیات نسبتاً گران است ، معماری جریان همچنین جریمه هایی را برای جریانهای کوچک در نظر می گیرد ، رفتاری که به عنوان اثر جریان کوتاه نامیده می شود .

Pipelining یک عمل بسیار گسترده و بسیار مورد استفاده در پردازنده های جریان است ، با GPU های دارای خطوط لوله بیش از 200 مرحله. هزینه تغییر تنظیمات بستگی به تغییر تنظیمات دارد ، اما در حال حاضر همیشه گران در نظر گرفته می شود. برای اجتناب از این مشکلات در سطوح مختلف خط لوله ، تکنیک های زیادی مانند "shadber shader" و "atlases text" به کار گرفته شده است. این تکنیک ها به دلیل ماهیت GPU ها بازی محور هستند ، اما مفاهیم برای پردازش جریان عمومی نیز جالب هستند.

مثالها

  • Blitter در ناخدا آمیگا اولیه (حدود 1985) پردازنده گرافیکی قادر به ترکیب سه جریان منبع 16 بردار کمی جزء در 256 راه برای تولید یک جریان خروجی متشکل از 16 بردار کمی مولفه است. مجموع پهنای باند جریان ورودی تا 42 میلیون بیت در ثانیه است. پهنای باند جریان خروجی تا 28 میلیون بیت در ثانیه است.
  • تصور کنید ، [10] به سرپرستی پروفسور ویلیام دالی از دانشگاه استنفورد ، یک معماری انعطاف پذیر است که هم سریع و هم از نظر انرژی کارآمد است. این پروژه که در ابتدا در 1996 طراحی شد ، شامل معماری ، ابزارهای نرم افزاری ، پیاده سازی VLSI و یک تابلوی توسعه بود که توسط DARPA ، Intel و Texas Instruments تأمین مالی شده است .
  • یکی دیگر از پروژه های استنفورد به نام Merrimac [11] با هدف توسعه یک ابررایانه مبتنی بر جریان است. مریماک قصد دارد از معماری جریان و شبکه های پیوسته پیشرفته برای ارائه عملکرد بیشتر در واحد هزینه نسبت به رایانه های علمی مبتنی بر خوشه که از همان فناوری ساخته شده اند ، استفاده کند.
  • از طوفان 1 خانواده از جریان پردازنده، وارز ، یک اسپین آف تجاری استنفورد تصور کنید پروژه، طی یک سخنرانی از ویژگی های در اعلام شد ISSCC 2007. خانواده شامل چهار عضو اعم از 30 GOPS به 220 GOPS 16 بیت (میلیاردها عملیات در ثانیه) ، همه در TSMC در یک فرایند 130 نانومتری ساخته شده اند. این دستگاه ها هدف نهایی بازار DSP شامل ویدئو کنفرانس ، چاپگرهای چند منظوره و تجهیزات نظارت تصویری دیجیتالی را هدف قرار می دهند .
  • GPU ها پردازنده های جریان گسترده و درجه مصرف کننده [2] هستند که عمدتا توسط AMD و Nvidia طراحی شده اند . نسلهای مختلفی که باید از نظر پردازش جریان مورد توجه قرار گیرند:
    • Pre-R2xx/NV2x: پشتیبانی صریحی از پردازش جریان ندارد. عملیات هسته در API پنهان شده بود و انعطاف پذیری بسیار کمی برای استفاده عمومی فراهم می کرد.
    • R2xx/NV2x: عملیات جریان هسته به صراحت تحت کنترل برنامه نویس قرار گرفت اما فقط برای پردازش راس (قطعات هنوز از پارادایم های قدیمی استفاده می کردند). هیچ پشتیبانی انشعابی انعطاف پذیری را به شدت مختل می کند اما برخی از انواع الگوریتم ها قابل اجرا هستند (به ویژه شبیه سازی سیال با دقت پایین).
    • R3xx/NV4x: پشتیبانی انعطاف پذیر از انشعابات ، اگرچه هنوز محدودیت هایی در تعداد عملیات قابل اجرا و عمق بازگشت شدید ، و همچنین دستکاری آرایه وجود دارد.
    • R8xx: از ضمیمه/مصرف بافرها و عملیات اتمی پشتیبانی می کند. این نسل آخرین هنر است.
  • نام تجاری AMD FireStream برای خط تولید HPC
  • نام تجاری Nvidia Tesla برای خط تولید HPC
  • پردازشگر سلولی از STI ، ائتلافی از سرگرمی های کامپیوتری سونی ، توشیبا ، و آی بی ام ، یک معماری سخت افزار است که می تواند مانند یک پردازشگر جریان با پشتیبانی نرم افزار مناسب عمل است. این دستگاه شامل یک پردازنده کنترل کننده ، PPE (عنصر پردازش قدرت ، یک IBM PowerPC ) و مجموعه ای از پردازنده های SIMD ، به نام SPEs (عناصر پردازش هم افزایی) است که هریک دارای شمارنده برنامه مستقل و حافظه دستورالعمل هستند.دستگاه. در مدل برنامه نویسی بومی ، تمام برنامه ریزی DMA و برنامه به برنامه نویس واگذار می شود. این سخت افزار یک گذرگاه زنگ سریع در بین پردازنده ها برای ارتباطات محلی فراهم می کند. از آنجا که حافظه محلی برای دستورالعمل ها و داده ها محدود است ، تنها برنامه هایی که می توانند از این معماری به طور مثر استفاده کنند یا نیاز به رد پای کوچک حافظه دارند یا به مدل برنامه نویسی جریان پایبند هستند. با یک الگوریتم مناسب عملکرد Cell می تواند با پردازنده های جریان خالص رقابت کند ، اما این تقریباً همیشه نیاز به طراحی مجدد کامل الگوریتم ها و نرم افزار دارد.

جریان کتابخانه ها و زبان های برنامه نویسی

اکثر زبانهای برنامه نویسی برای پردازنده های جریان با جاوا ، C یا C ++ شروع می شوند و برنامه های افزودنی را اضافه می کنند که دستورالعمل های خاصی را ارائه می دهد تا به توسعه دهندگان برنامه اجازه دهد تا هسته ها و/یا جریانها را برچسب گذاری کنند. این امر در مورد اکثر زبان های سایه زا نیز صدق می کند ، که می توان آنها را تا حدی زبان برنامه نویسی جریان تلقی کرد.

نمونه های غیر تجاری زبان های برنامه نویسی جریان عبارتند از:

  • Ateji PX Free Edition ، بیان ساده برنامه نویسی جریان ، مدل Actor و الگوریتم MapReduce را در JVM فعال می کند.
  • Auto-Pipe ، از آزمایشگاه ابر رایانه های مبتنی بر جریان در دانشگاه واشنگتن در سنت لوئیس ، یک محیط توسعه برنامه برای پخش برنامه های کاربردی است که امکان نوشتن برنامه ها برای سیستم های ناهمگن (CPU ، GPGPU ، FPGA) را فراهم می کند. برنامه ها را می توان در هر ترکیبی از C ، C ++ و جاوا برای CPU توسعه داد. Verilog یا VHDL برای FPGA ها. Cuda در حال حاضر برای GPGPU های انویدیا استفاده می شود. Auto-Pipe همچنین هماهنگی اتصالات TCP بین چندین ماشین را کنترل می کند.
  • مدل برنامه نویسی ACOTES : زبان از دانشگاه پلی تکنیک کاتالونیا بر اساس OpenMP
  • BeepBeep ، یک کتابخانه پردازش جریان ساده و سبک مبتنی بر جاوا از آزمایشگاه رسمی علوم کامپیوتر در Université du Québec à Chicoutimi
  • زبان بروک از استنفورد
  • CAL Actor Language : یک زبان برنامه نویسی سطح بالا برای نوشتن بازیگران (dataflow) ، که اپراتورهای حالت دهنده ای هستند که جریانهای ورودی اشیاء داده (نشانه ها) را به جریانهای خروجی تبدیل می کنند.
  • Cal2 بسیاری از چارچوب تولید کد از دانشگاه Halmstad ، سوئد. از کد CAL به عنوان ورودی استفاده می کند و زبان های مختلف مورد نظر را از جمله C متوالی ، Chisel ، C موازی معماری Epiphany ، معماری ajava & astruct targeting Ambric و غیره ایجاد می کند.
  • زبان DUP از دانشگاه فنی مونیخ و دانشگاه دنور
  • HSTREAM: یک برنامه افزودنی زبان مبتنی بر دستورالعمل برای محاسبه جریان ناهمگن [12]
  • RaftLib - کتابخانه قالب پردازش جریان C ++ منبع باز در اصل از آزمایشگاه ابر رایانه های مبتنی بر جریان در دانشگاه واشنگتن در سنت لوئیس
  • SPar - زبان ویژه حوزه C ++ برای بیان موازی سازی جریان از گروه مدل سازی برنامه (GMAP) در دانشگاه کاتولیک پاپی ریو گراند دو سول
  • کتابخانه Sh از دانشگاه واترلو
  • Shallows ، یک پروژه منبع باز
  • زبان هماهنگی S-Net از دانشگاه هرتفوردشایر ، که جداسازی هماهنگی و برنامه نویسی الگوریتمی را فراهم می کند
  • StreamIt از MIT
  • Siddhi از WSO2
  • WaveScript پردازش جریان عملکردی ، همچنین از MIT.
  • برنامه نویسی واکنشی عملکردی را می توان پردازش جریانی به معنای وسیع در نظر گرفت.

پیاده سازی های تجاری یا عمومیت دارند یا توسط فروشنده به سخت افزار خاصی متصل می شوند. نمونه هایی از زبانهای عمومی شامل موارد زیر است:

زبانهای فروشنده خاص عبارتند از:

پردازش مبتنی بر رویداد

پردازش دسته ای مبتنی بر فایل (تقلید از برخی از پردازش های جریان واقعی ، اما به طور کلی عملکرد بسیار پایین تر [ نیاز به توضیح ] [ نیاز به استناد ] )

پردازش مداوم جریان اپراتور [ نیاز به توضیح ]

خدمات پردازش جریان:

همچنین ببینید

مراجع

  1. ^ مقدمه ای برای پردازش STREAM
  2. ^ FCUDA: فعال کردن کامپایل کارآمد هسته های CUDA بر روی FPGA ها
  3. ^ مجله مدارات حالت جامد IEEE: "A 512 GOPS Stream Processor for Signal، Image، and Video Processing" ، دانشگاه استنفورد و Stream Processors، Inc.
  4. ^ خیلانی ، دالی ، ریکسنر ، کاپاسی ، اوونز و تاولز: "بررسی مقیاس پذیری VLSI پردازنده های جریان" ، دانشگاه استنفورد و رایس.
  5. ^ Gummaraju و Rosenblum ، "پردازش جریان در پردازنده های عمومی" ، دانشگاه استنفورد.
  6. ^ کاپاسی ، دالی ، ریکسنر ، خیلانی ، اوونز ، آن و متسون ، "پردازنده های جریان قابل برنامه ریزی" ، دانشگاههای استانفورد ، رایس ، کالیفرنیا (دیویس) و آزمایشگاههای مخزن.
  7. ^ اریک چان. "پروژه سایه زنی قابل برنامه ریزی در زمان واقعی استانفورد" . تحقیق وب سایت گروه . بازبینی شده در 9 مارس 2017 .
  8. ^ "تصور کنید - پردازنده تصویر و سیگنال" . وب سایت گروه . بازبینی شده در 9 مارس 2017 .
  9. ^ "مریمک - استنفورد جریان ابر رایانه پروژه" . وب سایت گروه . بایگانی شده از نسخه اصلی در 18 دسامبر 2013 . بازبینی شده در 9 مارس 2017 .
  10. ^ تصور کنید
  11. ^ مریماک
  12. ^ ممتی ، سوجب ؛ پلانا ، صبری (اکتبر 2018). HSTREAM: یک برنامه افزودنی زبان مبتنی بر دستورالعمل برای محاسبات جریان ناهمگن . IEEE arXiv : 1809.09387 . doi : 10.1109/CSE.2018.00026 .
  13. ^ PeakStream راه حل برنامه نویسی چند هسته ای و CPU/GPU را رونمایی می کند
  14. ^ TStreams: مدل محاسبه موازی (گزارش فنی).
  15. ^ TStreams: نحوه نوشتن یک برنامه موازی (گزارش فنی).
  16. ^ "GitHub - walmartlabs/Mupd8: Muppet" .

پیوندهای خارجی

  1. ^ چینتاپالی ، سانکت ؛ داگیت ، درک ؛ ایوانز ، بابی ؛ فریور ، رضا؛ گریوز ، توماس ؛ هولدرباغ ، مارک ؛ لیو ، ژو ؛ نسبوم ، کایل ؛ پاتیل ، کیشورکومار ؛ پنگ ، بویانگ جری ؛ پولوسکی ، پل (مه 2016). "مقایسه موتورهای محاسبه جریان: جریان طوفان ، تلنگر و جرقه". 2016 کارگاه های بین المللی سمپوزیوم پردازش موازی و توزیع شده IEEE (IPDPSW) . IEEE صص 1789–1792. doi : 10.1109/IPDPSW.2016.138 . شابک 978-1-5090-3682-0به S2CID  2180634 .