سیستم های محاسباتی ناهمگن با بهره گیری از پردازنده مرکزی و کارت گرافیک

[hamedof 5,183]

سیستم های محاسباتی ناهمگن با بهره گیری از پردازنده مرکزی و کارت گرافیک

 

قسمت اول

 

 

 

 

 

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

 

سلام خدمت تمامی دوستان ...

 

در ابتدا باید عذرخواهی کنم به خاطر تاپیک هایی که نتونستم تمام کنم ... .

 

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

 

 

 

سیستم های محاسباتی ناهمگن

محاسبات علمی نیازمند توان بالای پردازشی می باشد. این نیاز باعث شده است تا سخت افزارها پیوسته توسعه یابند. به مدت بیش از دو دهه صنایع کامپیوتری برنامه ریزی خود را بر اساس قانون مور بنا نهادند. این قانون بیان می کرد که تقریبا هر 18 ماه تعداد ترانزیستورهای واقع بر یک مدار یکپارچه چگال دو برابر می شود در حالیکه هر نسل جدید توان مصرفی قبلی خود ثابت نگه می داشت. پس از سال 2000 ترانزیستور ها به شدت کوچک شدند و تنها با اعمال قوانین فیزیک ابزارهای کوچک طراحی نسل های جدید پردازنده ممکن بود، با این وجود یک مشکل جدی در راه طراحی پردازنده ها وجود داشت. بدون افزایش چشم گیر توان مصرفی و چگالی توان امکان بهبود فرکانس و تعداد ترانزیستور ها ممکن نبود. این موضوع در شکل 1-1 قابل مشاهده است.

 

 

شکل 1-1. تعداد ترانزیستور های هر پردازنده با توجه به تاریخ تولید را نشان میدهد. توجه کنید که مقیاس بندی عمودی به صورت لگاریتمی می باشد.

 

با این وجود برای برآورده ساختن نیاز به افزایش کارایی سیستم های پردازشی دو تغییر مهم صورت گرفت:

1.  
2. افزایش تعداد هسته های موجود در هر برد به جای افزایش فرکانس پردازنده. این تغییر در ساختار پردازنده ها باعث توسعه سیستم های نرم افزاری جدید برای به کارگیری حداکثری ساختار چندهسته ای جدید پردازنده ها نیز شد. این امر باعث تولد پردازش و برنامه نویسی موازی شد.
3.  
4. توان مصرفی و حرارت ایجاد شده دو فاکتور بسیار مهم در طراحی ساختارهای چند هسته ای جدید آینده شد.
5.  

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

در این بازار رقابت جدید شرکت های مختلف تلاش می کنند سخت افزار خود را به وسیله نرم افزارهای عمومی و اختصاصی خود و دیگران تا جایی که ممکن است بهینه کنند. یکی از مهمترین فعالان این عرصه را می توان Khronos Group دانست.

    

 

 یکی از مهمترین محصولات این کنسرسیوم OpenCL است. در واقع این محصول که با زبان C99 نوشته شده است به شما این قابلیت را میدهد تا برای برنامه خود کدی را بنویسید که بتواند روی زیرسیستم های مختلف اعم از پردازنده های مرکزی، کارت های گرافیکی، پردازنده های سیگنال دیجیتال DSP ، FPGAها و ...  اجرا شود و به وسیله رابط های برنامه نویسی نرم افزار (API) خود امکان کنترل و اجرای برنامه ها را برای شما در زیرسیستم ها فراهم می کند. با این حال شاید این محصول بهترین گزینه نباشد، زیرا این محصول برای همه کاربردها بهینه نشده است و بدون بهینه سازی های ثانویه احتمال اجرا نشدن برنامه شما نیز وجود دارد. البته فراموش نکنیم که این محصول توسط شرکت هایی نظیر اپل ، AMD-ATI ، Nvidia و برخی دیگر شرکت ها حمایت می شود و می تواند گزینه بسیار خوبی برای قدم نهادن به دنیای سیستم های ناهمگن باشد.

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

 

 

پردازش موازی مبتنی بر کارت گرافیک، از پردازش داده های رنگ تا پردازش عمومی

با ظهور سیستم عامل هایی نظیر ماکروسافت ویندوز در اواخر دهه 80 و اوایل دهه 90 میلادی بازاری برای گونه ای جدید از سخت افزار ها ایجاد شد و کاربران سیستم های کامپیوتری علاقه خود را به خرید سخت افزارهای گرافیکی دو بعدی برای انجام عملیات های تصویر نگاری نشان دادند. در این میان شرکت سیلیکون گرافیک شروع به توسعه پلتفرمی جدید برای پردازش سه بعدی تصویر برای استفاده های گوناگون دولتی ، صنایع نظامی ، محاسبات علمی و فنی نمود و در این راه کتابخانه OpenGL را توسعه داد. با گذشت زمان و در اواسط دهه 90 میلادی با معرفی بازی های سه بعدی (مانند Doom, Duke Nukem و ...) تقاضای کاربران عادی برای پردازنده های قدرتمند گرافیکی رو به افزایش گذاشت و باعث شد تا شرکت هایی نظیر NIVDIA، ATI technologies و 3dfx interactive به رقابت برای فروش کارت های گرافیکی با قیمت مناسب کنند.

معرفی کارت گرافیکی NVIDIA Geforce 256 گامی بلند در عرصه کارت های گرافیکی بود. برای اولین بار محاسبات انتقال و نورپردازی بر روی کارت گرافیکی با استفاده از OpenGL امکان پذیر شده بود. در قدم بعدی در سال 2001 شرکت انویدیا سری جدیدی از کارت های گرافیکی خود را با نام تجاری Geforce 3 series  به بازار عرضه کرد. این سری از تراشه های گرافیکی مطابق با استاندارد DirectX 8 شرکت ماکروسافت ساخته شده بود تا همزمان قابلیت برنامه نویسی مراحل ورتکس و پیسکل شیدینگ را داشته باشند و برای اولین بار برنامه نویسان کنترل مستقیمی بر روی برخی پردازش های کارت گرافیک را دارا بودند.

بنابراین برخی از محققان به دنبال انجام محاسبات بر روی کرات های گرافیکی رفتند اما یک مشکل عمده در راه آن ها قرار داشت. تنها راه ارتباط با کارت گرافیک برنامه DirectX شرکت ماکروسافت و یا کتابخانه OpenGL بود که هر دو برای انجام رندرینگ تصویر طراحی شده بودند. در آن زمان پردازنده های گرافیکی با انجام محاسبات منطقی برای هر پیکسل تصویر با مختصات (x,y) یک رنگ را تولید می کردند. تولید این رنگ وابسته به اطلاعات اولیه و محاسباتی بود که کاربر برای رندرینگ برای کارت گرافیکی تعریف می کرد. پس از مدتی پژوهشگران این عرصه دریافتند که اطلاعات ورودی نه تنها رنگ بلکه می تواند هر نوع داده ای باشد. بنابراین پیکسل شیدرها می توانستند توسط کاربران برای انجام محاسبات عددی با نام "رنگ" نیز برنامه نویسی شوند و خروجی "رنگ" آن ها در واقع نتایج محاسبات عددی بود. با این حال که این حقه باعث می شد تا انجام محاسبات بر روی کارت های گرافیکی انجام پذیر باشد دارای پیچیدگی های بسیار زیادی بود که این کار را در عمل غیرممکن می ساخت و در بسیاری موارد حتی نتایج محاسبات اشتباه بود. برخی این محدودیت ها عبارت اند از : نیاز به یادگیری زبان های برنامه نویسی گرافیکی (shading languages) ، مشخص نبودن نحوه انجام محاسبات اعشاری بر روی کارتهای گرافیکی ، نوشتن نتایج در حافظه داخلی رم ، جابجا سازی اطلاعات در حافظه داخلی و ... .

 

اما 5 سال بعد در سال 2006 ساختاری کاملا جدید توسط شرکت Nvidia در کارت گرافیکی Geforce 8800 GTXمعرفی شد. این ساختار جدید که CUDA نام داشت سعی در برطرف کردن محدودیت های پیشین محاسبات بر روی کارت گرافیکی داشت و به گونه ای طراحی شده بود تا برنامه نویسی بر روی کارت های گرافیکی را تسهیل کند. این معماری جدید کارت های گرافیکی به همراه نرم افزار CUDA toolkit که شامل API ها و کامپایلر nvcc بود این قابلیت را ایجاد می کرد که بتوان با استفاده از زبان برنامه نویسی C و C++ به همراه برخی از افزونه ها ، برنامه هایی قابل اجرا بر روی کارت گرافیک نوشت.

 

تفاوت قدرت پردازشی را نیز می توان به وضوح در شکل زیر قابل مشاهده است.

 

ادامه دارد...

 

کاربرد های نظامی این شکل محاسبات:

http://arxiv.org/abs/1505.08067

 

تمامی حقوق این نوشتار متعلق به نویسنده است و هرگونه کپی برداری غیرقانونی است.

 

منابع رو هم بعد از اتمام پایان نامه ارائه خواهم داد بنا به مصلحت های شخصی ... .

[majid363 3,583]

نرم افزار متلب مدت هااست که این قابلیت را داره

[yaabas 3]

سلام مطالب خوب بود

[hightech 1,598]

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

صرفا جهت یادآوری دوستان و اساتید

GPU یا واحد پردازش گرافیک زبان اسمبلی خاص خود را دارد که همان زبان های برنامه نویسی گرافیکی (shading languages) اما سطح پایین این زبان است

ابررایانه چینی Tianhe-1 که یک دوره برترین ابررایانه جهان بود، از 7168 پردازنده گرافیکی NVidia بهره میبرد

[EMP 6,864]

نرم افزار متلب مدت هااست که این قابلیت را داره

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

البته متلب هم مثل غول های دیگر از جمله cedrat و Ansys از تکنولوژی MPI می تواند استفاده بکند که این تکنولوژی فقط برای موازی کردن برنامه شما روی هسته های CPU خوب است نه GPU.

 

هندی ها با استفاده از کارت گرافیکی رادار بدون انتشار پسیو ساخته اند در ایران هم از کارت گرافیکی بیشتر توسط فیزیک دانها و برای محاسبات علمی و پایان نامه های علمی آنها که نیازمند محاسبات بسیار سنگین و ارزان هستند استفاده می شود.در بسیاری از پروژه ها هم (به ویژه دولتی) مدیران پروژه اجازه استفاده از کارتهای گرافیکی محاسباتی را نمی دهند و معمولا اگر کار موازی انجام بشود با استفاده از MPI و OpenMP هست.

مزیت کارت گرافیکی در محاسبات فقط این نیست که بر خلاف CPU محاسبات ممیز شناور آن استاندارد IEEE754 است. بلکه این هست که هسته های گرافیکی 10 برابر پاور کمتری نسبت به هسته های CPU مصرف می کنند و از این دیدگاه در جهانی که 30 درصد کل انرژی آن را کامپیوتر ها می بلعند بسیار بسیار مهم هست.

 

در واقع با استفاده از GPU ما قادریم در خانه ابر رایانه به نسبت ارزان و کم مصرف داشته باشیم که به این ترتیب بسیاری از الگوریتم ها و کاربردها که قبلا کنار گذاشته شده بودند به دلیل حجم محاسبات حالا در دسترس هستند.

البته کار با این کارتها از عهده هر کسی ساخته نیست و بر خلاف MPI برنامه سازی روی آنها نیازمند متخصص کامپیوتر در پردازش موازی هست نه هر کسی که 2 واحد برنامه سازی پاس کرده است.

[smorteza 743]

با تشکر از جناب hamedof به خاطر مطالب ارزنده‌شان

 

البته ناگفته نماند شرکت‌های سازنده CPU نیز بیکار ننشستند

 

شرکت اینتل برای افزایش‌ سرعت محاسبات دست به ساخت کلاسترهای مجتمع با نام xeon phi نمود خانواده night landing در یک کارت دارای ۷۲ واحد پردازشگر است که

توان محاسباتی ۱.۲ ترافلاپس را در مدل ۷۱۲۰ ارائه می‌کند که مبنای طراحی ماشین‌های محاسباتی امروزه است به عنوان مثال تیان هی ۲ دارای ۱۶۰۰ نود محاسباتی

به قدرت ۳۳ پتا فلاپس است در حالی که هر نود از دو سری پروسسورIvy Bridge و ۳ کارت xeon phi استفاده می کند و در مجموع سه میلیون هسته محاسباتی سبب شده تا عنوان بزرگترین

ماشین محاسباتی را به خود اختصاص دهد.

 

شرکت AMD نیز مجموعه fire Stream را عرضه نموده که تابحال با آن کار ننموده ام

 

 

در مقابل Nvidia کارت های محاسبه گر خود را با معماری متفاوت عرضه می‌نماید که توضیح آن را به بعد از اجازه جناب حامداف موکول می‌کنم

کارت پاسکال از خانواده تسلا به تنهایی دارای ۳۵۸۴ هسته پردازش به قدرت پردازش ۱۰ ترافلاپس است

 

البته مقدار غیر قابل باور توان محاسباتی GPU ها یک توان علمی است و در عمل به توانایی انطباق برنامه‌ها بر GPU وابسته است

برنامه نویسی بهینه  بر اساس GPU نیازمند آگاهی کامل و به روز از معماری واحدهای پردازشگر آن است و به کلی با برنامه نویسی های متداول

متفاوت است‌

اما برنامه نویسی بر روی کارت‌های مجتمع اینتل به مراتب راحت‌تر است و تفریبا با برنامه نویسی متداول تفاوتی ندارد برنامه توسط مفسر OPEN MP

به چند بخش شکسته شده و بر روی CPU هسته‌ها اجرا می‌شود

 

نکته مهم اینکه اینگونه سخت افزارها  در محیط لینوکس برای برنامه نویسی کاربر در دسترس هستند و عموما کلاس‌های برنامه نویسی را پشتیبانی نمی کنند

این مساله در GPU جدی تر است

[EMP 6,864]

به چند بخش شکسته شده و بر روی CPU هسته‌ها اجرا می‌شود

 

نکته مهم اینکه اینگونه سخت افزارها  در محیط لینوکس برای برنامه نویسی کاربر در دسترس هستند و عموما کلاس‌های برنامه نویسی را پشتیبانی نمی کنند

این مساله در GPU جدی تر است

درود به دوستان گرامی

با اینکه کارت xeon phi پردازنده های زیادی را در اختیار می گذارد و برنامه سازی روی آن خیلی ساده تر از برنامه سازی روی GPU هست اما من ترجیح می دهم که از OpenMP استفاده نکنم.

OpenMP یک کامپایلر دایرکتیو هست که کامپایلر به کامپایلر تنظیماتش متفاوت است و به ویژه در زمینه مدیریت stack دچار مشکلات وحشتناکی است.

در یک پروژه بزرگ من دوست دارم از Message passing Interfacing (MPI) استفاده بکنم که خیلی ساده نیست اما کنترل همه هسته ها با دقت دست خود برنامه ساز هست و احتمال وقوع خطای کمتری دارد اما در OpenMP اینطور نیست و ما مجبوریم که به کامپایلر اعتماد بکنیم. حتی در زبانهایی که امنیت بیشتری نسبت به C دارند استفاده از OpenMP ساده اما ساخت نرم افزار با پاسخ مطمئن بسیار مشکل است.

اگر از OpenMP روی Windows استفاده می کنید توصیه می کنم که Intel parallel Studio 2016 را روی Visual studio  بگذارید و از امکانات debug آن هم استفاده بکنید تا محل وقوع race را به شما نشان بدهد. در ضمن تا می توانید کار nested نکنید که سر و ته کار را بشود جمع کرد.

 

مزیت کارتهای Xeon phi این است که خیلی سریع می شود روی انها برنامه موازی را با روش های متداول پیاده کرد و ایراد آنها مصرف انرژی بیشتر هست.

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

در این دورانی که اینتل مرتب در حال ضرر دادن است، اینها با زنده کردن پروژه شکست خورده "لارابی" دارند سعی می کنند که برای خود بازاری ایجاد بکنند. وضع AMD که باید از اینتل هم بدتر باشد.

 

برای نوشتن برنامه روی کارت گرافیکی تحت ویندوز هم کافی است که درایور متناسب با کامپیتور خود را با استفاده از فیلتر شکن از سایت NVIDIA دانلود کنید سپس روی visual studio 2012 که در سیستم نصب دارید نصب بکنید و بعد با استفاده از دیباگر nsight برنامه خود را ریز ریز جلو ببرید. البته باید از معماری GPU کاملا اطلاع داشته باشید و از حافظه ها درست استفاده بکنید و حواستان به سینک به موقع و دستورات اتمیک هم باشد در غیر این صورت نتیجه غلط خواهد بود.

یک کار خوب استفاده از توابع کتابخانه ای هست که قبلا برای GPU تهیه شده باشند.

 

البته به نظر من اگر بروید در BIOS گزینه hyperthreading را disable بکنید و برنامه خودتان را برای CPU هدف (مثلا i7 سری skylake) کامپایل بکنید و از کامپایلر بخواهید که از دستورات AVX2 یا بالاتر استفاده بکند و گزینه های debug را حذف بکند و release کامپایل بکنید، شما تا 64 برابر برنامه محاسباتی سریعتری دارید که همین برای اکثر کاربرد ها بیش از کافی است و خیلی بدون دردسر است و کمترین سختی را هم به برنامه ساز تحمیل نمی کند.

با بهینه سازی کد و تکنیکهای آن هم میزان قابل توجهی کد شما سریع می شود که باز نیاز به پردازش موازی را کم می کند. البته بهینه سازی باعث کاهش خوانایی برنامه می شود که شمشیر دولبه هست.

 

تنها در صورتی باید به سراغ پردازش موازی رفت که چاره دیگری نداریم.

خوبی و بدی GPU هم شاید این باشد که هر کسی نمی تواند برای آن برنامه سازی بکند و فقط افراد متخصص کامپیوتر می توانند برنامه سازی درست بکنند.

 

اگر کار شما با GPU و یا کلاستری از GPU ها هم راه نیافتاد تنها راه شما پیاده سازی الگوریتم روی FPGA است و باید کارت شتابدهنده خاص سخت افزاری بسازید.

طبیعی است که در محیط لینوکس همه چیز تا حدودی سریعتر باشد اما کاربردهای تحت لینوکی معمولا صنعتی و نظامی هستند تا تجاری.

 

در یک پروژه نظامی که سفارش ساخت سخت افزار برای یک نرم افزار داشتم، فقط با بهینه سازی خیلی ساده نیاز به از کار انداختن hyperthreading هم نشد چه برسد به استفاده از FPGA.

[smorteza 743]

با تشکر از جناب EMP

 

هیچ وقت فکر نمی‌کردم در این سایت چنین بحثی پیش بیاید اما این بحث نشان از تخصص و دانش کاربران و گردانندان این سایت است

 

اقبال به پردازشگر‌های xeon phi بسیار کم و برای پردازنده‌های مجتمع fire stream ناچیز است به گونه‌ای که خود اعضای شرکت

اینتل نیز دیگر تعصبی بر روی محصول خود نسبت به GPU ندارند ( البته در سطح برنامه نویسی حرفه‌ای)

 

واقعه از آنجا عجیب تر می‌شود که اینتل بخش تحقیقات هود را به شرکت اماراتی- هندی فروخته است

 

در واقع بازار بزرگ بازیهای کامپیوتری و کارت‌های گرافیکی مربوط به آن رشد سخت افزارهای GPU را تا سالها تضمین کرده است

( شاید اگر شرکت اینتل هم شام ما رو دعوت میکرد مثل Nvidia  ازش حمایت می کردم)

 

اگر بنا به دلایلی نتوانم از GPU استفاده کنم. آنگاه و فقط آنگاه

درمورد استفاده از MPI , openMP من ترجیح می‌دهم  نوع مساله و امکانات را ملاک قرار دهم

 

اگر محدودیت به حجم زیاد داده مربوط باشد استفاده از MPI مقرون به صرفه تر است تا ارتباط بین نودها با کامپایل مناسب حفظ شود

اما اگر حجم محاسبات زیاد باشد باید ارتباط بین هسته‌های یک نود اهمیت بیشتری پیدا می‌کند و استفاده از OpenMP به صرفه است

البته این قاعده برای نوهای بیش از ۱۶ هسته به صرفه خواهد بود

در حالت کلی استفاده هیبریدی از هر دو روش کارآیی بهتری دارد اما برای هر مساله پیداکردن شرایط بهینه تعداد نود و هسته برای دست‌یابی

به پرفورمنس بهینه است

 

در مورد کامپایل openMP , رسیدن به نتیجه درست باید در داخل برنامه به توالی یا sequence management توجه داشت در غیر این

صورت نتیجه فاجعه بار خواهد بود

 

جناب EMP  در مورد استفاده از اپلیکیشن‌ها در ویندوز مطالب ارزنده‌ای بیان فرمودند اما برنامه نویسی با کارآمدی بالاHigh Performance programing(HPC)

بر اساس نیازهای جدی و چالش برانگیزی ایجاد شده که حتی نیازمند ارتباط تنگاتنگ برنامه و سخت افزار است به همین جهت دسترسی

بدون محدودیت به سخت افزار ملاک است. انتخاب محیط ویندوز بدترین انتخاب در این مسیر است چراکه حتی بر طول آرایه‌ها نیز

اعمال نظر شدید میکند چه برسد به سخت افزار!

 

شاید این مثال بی راه نباشد که برای حمل بار سنگینی مسیر خوب و همواری را طراحی کنید ولی بار  را بامحدود کننده‌ای مانند سواری حمل کنید

یا با ماشین باری. لینوکس هم به همان نسبت برای دسترسی و اعمال مدیریت بر سیستم کاراتر و اصطلاحا (حمال‌تر) است تا جایی

که xeon phi فقط بر سیستم لینوکس قابل اجرا است. این محدودیت در GPU  هم به همان نسبت وجود دارد

 

از آن بدتر استفاده‌ از نرم افزاری مانند متلب برای برنامه نویسی موازی است که تصور آن را هم نمی‌توانم کنم

 

کارت  xeon phi

 

 

 

 

نمونه‌ای از چیدمان در یک نود

 

 

 

کارت GPU Nvidia tesla

 

 

 

3584 هسته در یک کارت!!!!!!!!!!

 

نمونه‌ای از چیدمان در یک نود

 

 

ناقابل ۸* ۳۵۸۴=۲۸۶۷۲ هسته

 

 

 

 

[EMP 6,864]

اگر بنا به دلایلی نتوانم از GPU استفاده کنم. آنگاه و فقط آنگاه

درمورد استفاده از MPI , openMP من ترجیح می‌دهم  نوع مساله و امکانات را ملاک قرار دهم

 

جناب EMP  در مورد استفاده از اپلیکیشن‌ها در ویندوز مطالب ارزنده‌ای بیان فرمودند اما برنامه نویسی با کارآمدی بالاHigh Performance programing(HPC)

بر اساس نیازهای جدی و چالش برانگیزی ایجاد شده که حتی نیازمند ارتباط تنگاتنگ برنامه و سخت افزار است به همین جهت دسترسی

بدون محدودیت به سخت افزار ملاک است. انتخاب محیط ویندوز بدترین انتخاب در این مسیر است چراکه حتی بر طول آرایه‌ها نیز

اعمال نظر شدید میکند چه برسد به سخت افزار!"""

 

 

درود به دوست گرامی

متن شما بسیار روان و آموزنده بود.

بر خلاف شما من همه مسائل نیازمند به پردازش زیاد را در ابتدا با GPU حل نمیکنم.

در بهترین حالت با یک GPU شاید به 300 برابر افزایش کارایی برسیم آن هم توسط یک متخصصی مثل شما نه هر کس.

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

 

من ترجیح می دهم که ابتدا ظرفیت معماری dataflow اینتل را با استفاده از کامپایلر های خود اینتل یا PGI پر بکنم و ILP یا Instruction level parallelism انجام بدهم. اگر به کارایی کافی نرسیدم سعی می کنم با Data level parallelism (DLP) و استفاده از دستورالعمل های SIMD مانند AVX2 بدون اینکه برنامه را تغییری بدهم و فقط با گزینه های مربوطه کامپایلر کارایی بدست بیاورم.

اگر باز هم نشد اگر برنامه را کس دیگری نوشته باشد سعی می کنم که با استفاده از روشهای بهینه سازی به ویژه از حافظه بهتر استفاده بکنم تا بیشتر برنامه در cache اجرا بشود نه در RAM و .... و صدها برابر کارایی بدست بیاورم. کما اینکه در همان پروژه ای که قبلا گفتم. برنامه یک فوق لیسانس مخابرات را 2700 بار فقط با بهینه سازی تسریع کردم که نشان دهنده این بود که برنامه سازان چقدر بد برنامه می سازند معمولا. این بهینه سازی رابا تبدیل به FPGA هم نمی توانستم که بدست بیاورم. یک برنامه تجاری تحت ویندوز را هم با بهینه سازی 600 برابر تسریع کردم که باز نشان از بد بودن برنامه ساز آنها داشت.

 

اگر موارد بالا افاقه نکرد آنگاه به سراغ MPI می روم و سعی می کنم که برنامه را روی کلاستر به کارایی مناسب برسانم و در صورتی که محدودیت انرژی داشته باشم به سراغ کارت گرافیکی محاسباتی می روم زیرا اینها روی RAM چک های ECC دارند و محاسبات آنها امنتر اما با فرکانس کمتر نسبت به کارتهای گرافیکی معمولی است.

به عبارت دیگر Thread level parallelism را در انتها استفاده می کنم.

به این صورت بیشترین افراد ممکن با محصول ارتباط برقرار کرده توسعه های بعدی آن کمتر منحصر به من یا افراد مشابه می شود.

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

معمولا یک برنامه سریال قدیمی بسیار اسپاگتی و بزرگ وجود دارد که از شما می خواهند آن را با موازی سازی تسریع بکنید در حالیکه برنامه سریال اینها حتی تست های اولیه را هم پاس نکرده و باگهایی مثل out of bound , uninitialized pointer و .... دارد.

 

برای مثال در یک پروژه هواشناسی که استاد من در گیر بود، ایشان باید Fortran می نوشت آن هم زیر لینوکس زیرا پروفسور اینها فقط Fortran بلد بود و لینوکس و به دلیل یک باگ در کد سریال که بعد از سالها بیرون زده بود، استفانو بیچاره پیش بینی کرده بود که در ماداگاسکار برف می بارد!!!! در یک پروژه نفتی که من درگیر بودم پروفسور ما فقط Fortran بلد بود و ویندوز در نتیجه ما فقط حق داشتیم از MPI و OpenMP استفاده بکنیم و ویندوز و کاربر نهایی محصول هم که شرکت نفتی بود امر به ویندوز کرده بود. می بینید که خیلی وقتها انتخاب زبان هم به دست شما نیست چه برسد به اینکه بخواهید از GPU استفاده بکنید.

52% همه برنامه های موازی امروزه به زبان Fortran هست. یک دلیلش قدیمی بودن اساتید بزرگ و chief scientist ها هست و یک دلیلش هم robust بودن بیشتر Fortran نسبت به C هست. زیرا C زبانی با مشکل ذاتی در Language هست و type safe هم نیست و هزار تا مشکل ایمنی دارد که منجر به این می شود که تست یک برنامه موازی بسیار زمان بر بشود.

امروزه بسیاری از کارهای پردازش موازی به روی Python و حتی Java رفته که بسیاری از امکانات پردازنده را نمی توانند استفاده بکنند و زبانهای کندی هستند و دست ما را هم در بهینه سازی می بندند در ذات اما فقط به دلیل robustness بیشتر به این سمت رفته اند کارفرماها.

 

طبیعتا بهترین و سریعترین زبان برای کارایی Fortran هست. Aliasing ندارد، مشکل language ندارد، باگ ایندکس ندارد , فراخوانی توابع بی مورد و تغییر بی مورد در رجیستر های سگمنت ندارد و ... و همیشه آخرین تکنولوژی روی آن می آید و چند سال بعد روی C هم ظاهر می شود. مثل OpenAccelerator که ابتدا روی Fortran در کامپایلرهای PGI ظاهر شد و 2 سال بعد روی C آمد که با این تکنولوژی شما می توانید مثل OpenMP از یک دایرکتو کامپایلر خود برای تولید کد PTX که قابل اجرا روی کارت گرافیکی NVIDIA باشد استفاده بکنید بدون اینکه خود را به زحمت نوشتن برنامه برای کارت گرافیکی بیاندازید اما بنده ترجیح می دهم که باز خودم برنامه CUDA بسازم و از چنین امکانی قبل از اینکه به بلوغ کامل نرسد استفاده نکنم.

حتی برخی آمده اند و از OpenCL که 10 برابر از CUDA کارایی کمتری بدست می دهد استفاده می کنند و مزایایی برای آن دارند از جمله این که خروجی OpenCl روی همه کارتهای گرافیکی و سرورهای دارای آرایه ای از FPGA محاسباتی نیز قابل اجرا است و زحمت تبدیل کد به سخت افزار را کم می کند اما باز من ترجیح می دهم فعلا از چنین امکاناتی استفاده نکنم و مستقیم برنامه CUDA بسازم تا هر کار دیگر روی کارت گرافیکی.

علاوه بر این هیچ کارت گرافیکی برای محاسبات به پای NVIDIA نمی رسد و این مزیت اجرا شدن روی همه محیط ها چندان مزیت بهینه ای نیست.

 

بدیهی است ک یک سیستم عاملی مثل ویندوز که هسته ای با سایز وحشتناک بزرگ دارد و شما اگر 300 ساعت روشن بگذاریدش خودش ممکن است crash بکند بدون اینکه چیزی روی آن در حال اجرا باشد قابل مقایسه با یک سیستم عامل با هسته 2.5 مگابایت که در robust بودن آن تردیدی نیست، نمی باشد. لینوکس نسخه ای دارد به نام yellow dog که مخصوص پردازش موازی بهینه و کامپایل شده است و شما معادل آن را در HPC pack برای Windows server 2008 می بینید که باز از لینوکس حداقل از نظر مصرف خیلی عقب تر است اما

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

 

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

البته اگر برنامه روی Workstation ها یا server هایی اجرا بشود که دارای ECC باشند و از سخت افزار محاسباتی امن برخوردار باشند احتمال crash پایینتر نیز می آید.

[smorteza 743]

مطالب بسیار ارزنده‌ای مطرح نمودید

به شخصه از آن استفاده زیادی بردم و مطمئنا بارها آن را مطالعه خواهم کرد

 

 

در مورد محدودیت‌های کارفرما (و استاد) من هم مانند شما این محدودیت را درک کرده‌ام بسیاری از برنامه‌نویسان مجبورند هم به زبان فرترن و هم به زبان C و ++C  برنامه نویسی کنند

 

خوشحال می‌شوم اگر مختصری در مورد زمینه فعالیت خود توضیح دهید تا بتوانیم موضوعات را به صورت مصداقی بررسی کنیم  فرآیند بهینه‌ سازی که شما مورد استفاده

قرار می‌دهید هوشمندانه و کارا است و به شکلی اصولی بهینه سازی را بر روی نرم افزار اجرا می‌نمایید من در حوزه سیالات ، داده‌های بزرگ  وساخت نرم افزارهای

شبیه سازی در حوزه علوم فعال هستم

 

در مورد باگ‌های موجود در نرم‌اقزار و حتی سخت‌افزارها این یک امر روتین است به گونه‌ای که در سخت افزارهای مانندGPU باگهای بسیار بیشماری وجود دارد بالاخص در عملیات

بر روی Floating Point دو الگوریتم ساده ممکن است پاسخ‌های متفاوتی بدهد

 

 

 

در یک مورد که یکی از اساتید الگوریتمی را برای پیاده سازی از ما خواسته‌ بود با یک جستجو ساده متوجه شدم که دو سال پیش این الگوریتم به عنوان باگ GPU معرفی شده‌بود

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

او هم با لبخندی به من گفت که عمر باگ‌های سخت افزاری در GPU پس از کشف ۶ ماه است و این مقاله ۲ سال پیش ارائه شده است

و اینگونه فک ما کش آمد

 

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

یکی پرسید یعنی با کارت گرافیک بازی هم می‌شود این کارها را کرد بعد به پروژه خودم که مربوز به نانو کامپوزیت‌ها بود ودر ارتباط با  زره‌های مایع بود را تشریح کردم

این بار از من پرسیدند فرق مخلوط و ترکیب چیست؟

از تعجب خشکم زد فکر نمیکردم سوال علوم سوم دبستان از من بپرسند فکر کردم مرا مسخره می‌کنند قدرت سخن گفتن از من سلب شده بود متحیر ماندم

از مجموع ۲۳ دکتری ۵۶ فوق لیسانس حدود هزار لیسانس و ... هیچ کس دانش یا تخصصی نداشت که به درد وزارت دفاع بخورد تنها تعدادی از شاغلین

وزارتخانه که  معرفی واحد مربوطه  برای تبدیل وضعیت داشتند از این فیلتر عبور کردند

 

خود من و بسیاری از افرادی که دکتری یا مدارک دیگر خود را در بهترین دانشگاهها اخذ کرده‌اند حاضرند با حقوق کارگری برای هر مرکز تحقیقاتی داخل کشور کار

کنند به شرط آنکه امکان اجرای تحقیقات را به آنها بدهند

 

یکی از دوستانم از بچه‌های ورودی دکتری پیوسته بود اکنون و پس از اخذ یک دکتری از فرانسه و یکی هم از ایران وچون میخواهد در ایران بماند

چاره‌ای جز کار بر روی انیمیشن پیدا نکرده است

دیگری با هزار امید پس از اخذ دکتری از اتریش به ایران آمده در دوره سربازی ..............

دیگری از هلند آمده اکنون .............................

همه ما دغدغه کار برای کشور خود داریم اما سرخوردگی تنها دستاورد این دغدغه است

 

 

نتیجه آنکه هکرهای دست و پاچلفتی عربستان سایت‌های وزارت خارجه را هک می‌کنند مگر ما در کشور متخصص کم داریم؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟

 

یا از همه با مزه تر ساخت این به اصلاح سوپر کامپیوتر‌های ملی است همیشه ۲۰ درصد اعتبار مجموعه‌های محاسباتی (ماشین‌های محاسباتی)

با رتبه بالای ۱۰ به سخت افزارها مربوط است و ۸۰ درصد آن به مجموعه برنامه نویسان و افرادی است که در کنار آن‌ به بهینه‌سازی الگوریتم‌های

مختلف می‌پردازند نکته‌ای که در سوپر کامپیوتر!! شیخ بهایی (دانشگاه صنعتی اصفهان) و گرید ملی (دانشگاه امیر کبیر ) اصلا دیده نشد و تنها یک مجموعه

سخت افزاری خریداری شد تا باز کاری شعاری انجام شده باشد

نتیجه آن شد که اکنون پس از چند سال این مجموعه‌ها از پس هزینه برق خود هم بر نمی‌آیند چه رسد به ارتقای سخت افزار!!!!!!!!!

 یک نمونه نرم افزار توسط این مجموعه‌ها طراحی نشده‌است یا حتی  یک نمونه گزارش performance  این ماشینها و یا اندازه گیری optimized core Number

برای یک الگوریتم!!!!!!

نتیجه دفن شدن این ماشینها با مدیرانشان در طول زمان و البته هدر رفت هزینه‌ای برگشت ناپذیر

 

 

جالب اینکه عربستان در این زمینه در حال پیشی گرفتن از ما است

ویرایش شده در خرداد 95 توسط smorteza

[EMP 6,864]

 

خوشحال می‌شوم اگر مختصری در مورد زمینه فعالیت خود توضیح دهید تا بتوانیم موضوعات را به صورت مصداقی بررسی کنیم  فرآیند بهینه‌ سازی که شما مورد استفاده

قرار می‌دهید هوشمندانه و کارا است و به شکلی اصولی بهینه سازی را بر روی نرم افزار اجرا می‌نمایید من در حوزه سیالات ، داده‌های بزرگ  وساخت نرم افزارهای

شبیه سازی در حوزه علوم فعال هستم

 

جالب اینکه عربستان در این زمینه در حال پیشی گرفتن از ما است

درود به دوست گرامی

با این توضیحاتی که شما دادید احساس می کنم که درجه علمی شما خیلی بالا باشد. حداقل خیلی بالاتر از من اما جوان هستید.

تخصص اصلی من طراحی دیجیتال است اما پردازش موازی و بهینه سازی کد سرگرمی من هست. در مهندسی معکوس و تبدیل و تغییر کد باینری ، طراحی الکترونیک برای پاس کردن استاندارد های صنعتی EMC ، Embedded system، PCB تجربه زیاد دارم. چند باری در صنایع داخلی مدرس طراحی FPGA و شبیه سازی PCB بوده ام. در شرکتهای مختلف هم کارم مدتها این بوده که مشاوره بدهم به پروژه های دچار مشکل یا اینکه برای حل مشکل به تیم اضافه بشوم و خودم هم کار بکنم. ناظر پروژه آزمایشگاه ملی تست نرم افزار بودم و الان در یک شرکت مشاور سخت افزار-نرم افزار حساس و ایمن و تستهای ایمنی مطابق استانداردهای مربوطه هستم.20 سال هست که در یکی از دانشگاه ها هم معماری کامپیوتر، بهینه سازی کد و پردازش موازی را به سخت افزاریها و نرم افزاری ها درس می دهم .

 

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

 

در مورد ابر رایانه ملی هیچ نگویید که من بابت آن کلی بد و بیراه شنیدم و متهم به بی سوادی شدم. حرف من این بود که توجیه شما برای پخش یک کلاستر کوچک در چند استان چه بود که به جای آن از یک کلاستر کوچک از GPU ها استفاده نکردید در یک جا که بنده را مورد عنایات خود قرار دادند. بعد چه شد که اسم این کلاستر شد گرید و اسم این گرید شد ایران گرید و ایران گرید را به گرید اروپا وصل کردید که اسرائیل را هم شامل می شود و بعد چه شد که اسم این کلاستر را گذاشتید ابر رایانه ملی!!!!

کجای یک گرید می شود ابر رایانه؟!؟!؟!؟ تمام عمر تقریبا معماری خواندیم و ابر رایانه برای ما معنی دیگری داشت که با کلاستر و گرید بسی متفاوت بود.

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

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

از آقای ز... که از مهندسان اصلی تیم ساخت ابر رایانه بود پرسیدم که شما چطور به نتیجه محاسبات float در یک گرید ناهمگن که هر کدام از پردازنده ها برای خودشان الگوریتم تخمین ته عدد float خودشان را دارند می توانید اعتماد بکنید؟ چه برنامه ای برای تست نرم افزار های scientific دارید. (می دانید که نرم افزار های scientific به دلیل نداشتن یک موتور پیشگو برای پاسخ نسبت به ورودی اعمال شده در اساس قابل تست نیستند) ایشان پاسخ فنی نداشت و بیشتر کارش تحقیر بود.

برخلاف CPU ها که هر خانواده ای روش تخمین جداگانه ای برای اعداد ممیز شناور دارد در GPU این تخمین مطابق  IEEE754 انجام می شود. اگر با کامپایلری مثل PGI بیاییم IEEE754 را هم اموله بکنیم نتیجه کار روی CPU خیلی کند می شود.

باز هم پاسخ فنی در کار نبود.

 

اواخر 2011 یکی از دانشجویان من در یک شرکت نفتی یک سری کمک از من خواست برای یک پروژه نفتی بین المللی. من فقط برای کمک به دانشجوی سابقم رفتم آنجا و آن موقع 10 سالی بود که من دنبال کار پردازش موازی واقعی می گشتم ولی نمی یافتم تا اینکه در این شرکت با یک کاری واقعی مواجه شدم. یک نرم افزار بود که چرخه حیات آن باز میگشت به 1965 و با فرترن روی نوار پانچ نوشته شده بود و مرتب بهبود یافته بود تا اینکه به 2011 رسیده بود!!! و سایزی نیم میلیون خطی داشت. در آن شرکت یک پروفسور آلمانی با من مصاحبه کرد و قرار شد که من برنامه سریال اینها را بهینه کنم و نسخه OpenMP و نسخه جداگانه MPI و نسخه جداگانه OpenMP-MPI ایجاد بکنم. استفاده از GPU و کامپایلر غیر از اینتل ورژن 2010 هم ممنوع بود.

 

همان اول کار متوجه شدم که برنامه سریال تعداد بسیار زیادی باگ دارد که با کامپایلر قابل کشف است!!!! اما اینها بی توجه به این باگها درجه سخت گیری کامپایلر را کاهش داده اند و کار می کنند. پس شروع کردم به رفع صد ها باگ برنامه سریال.اهمیت این نرم افزار برای شرکت نفت حیاتی بود و باعث بهره برداری صیانتی از مخازن می شد و البته بین 2 تا 10% بسته به مخزن به میزان بهره برداری می افزود که چند هزار میلیارد دلاری میشد!!!  با اینکه 300 نرم افزار دیگر با همین موضوع از طرف دانشگاهها و پژوهشگاهها و ... به شرکت نفت انداخته شده بود این اولین نرم افزاری بود که با مشابه خارجی قابل رقابت بود که هیچ مبنای علمی قوی تری هم داشت و می توانست سکوی صدها تز دکترای مخزن باشد و سورس آن هم که در اختیار بود. اما به دلیل قدمت و ساخته شدن توسط مهندسان غیر کامپیوتر دارای ساختار بدی بود. بهینه سازی های من روی این برنامه غول آسا به دلیل اینکه مخزن به مخزن برنامه مدل اجرایش تغییر می کرد و برنامه سریال دارای صدها باگ بود، با مشکل مواجه شد و فقط 25% تسریع گردید که از نظر من یک شکست سخت بود اما از نظر پروفسور آلمانی یک پیشرفت خیره کننده بود زیرا با این وضعیت جدید سرعت اجرای اینها هم از رقیب بزرگ خارجی بیشتر شده بود. رقیب خارجی هم برنامه سریالش را که نسخه ای یک میلیون دلار می فروخت برای مخازن ایران ویژه سازی نمی کرد و این تنها برنامه ای بود که در دسترس شرکت نفت می توانست قرار بگیرد.

خلاصه تلاشهای تیم ایرانی منجر به تولید نسخه موازی در 2013 شد که بعد ما فهمییم با یک شرکت آلمانی طرف نیستیم و صاحب کار دفتر فناوری و چندین مدیر ایرانی است و مدیران فراوان این دفتر آمدند و بیت المال بیت المال کردند و پروفسور آلمانی را بیرون کردند و سپس یک مدیر با لحجه اصفهانی و انگلیسی قسمت موازی پروژه را لاکچری تشخیص دادند!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! و بنده هم حذف شدم. در 2015 دوباره پروفسور بازگشت ولی من فقط 6 ماه فرصت داشتم که برنامه ای که در طی 2 سال دوباره زیر و رو شده را موازی بکنم که به دلیل goto های فراوان از محل کشف واگرایی حل معادلات دیفرانسیل به ابتدای برنامه نسخه MPI با مشکل جدی مواجه شد اما نسخه OpenMP برای بیش از 100 مخزن درست کار کرد اما برای یک مخزن واقعی دیگر که متعلق به یکی از کشورهای آفریقا بود crash کرد و من در این فرصت نتوانستم بفهمم که چرا روی این مخزن crash می کند. ای کاش آن موقع یک فردی مثل شما در دسترس بود. شاید به دلیل درک بهتر از سیالات در این پروژه نفتی کار موثرتری نسبت به من می توانستید ارائه بدهید.

جالب است بدانید که اگر Mccabe این برنامه شبیه ساز مخزن را حساب می کردیم از 1000 عبور می کرد در حالیکه اگر Mccabe شما از 50 عبور کند آزمایشگاه تست نرم افزار را برای تست قبول نمی کند معمولا!!!

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

خلاصه در چنین شرایطی ILP به جک شبیه شد و DLP فقط 25% کارساز شد زیرا اینها حاضر نبودند که از معماری sandybridge استفاده بکنند و اسرار داشتند که تنها از SIMD2 استفاده بشود تا روی همه کامپیوترها قابل اجرا باشد در حالی که این نرم افزار که wordprocessor نبود که روی همه کامپیوتر ها اجرا شدن برای آن مزیت باشد اما حرف به گوش تیم آلمانی نمی رفت که نمی رفت.

 

خلاصه خاطره بسیار بدی برای من به جا ماند

[smorteza 743]

درود به دوست گرامی

با این توضیحاتی که شما دادید احساس می کنم که درجه علمی شما خیلی بالا باشد. حداقل خیلی بالاتر از من اما جوان هستید.

 

 

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

 

در مورد ابر رایانه ملی هیچ نگویید که من بابت آن کلی بد و بیراه شنیدم و متهم به بی سوادی شدم. حرف من این بود که توجیه شما برای پخش یک کلاستر کوچک در چند استان چه بود که به جای آن از یک کلاستر کوچک از GPU ها استفاده نکردید

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

اواخر 2011 یکی از دانشجویان من در یک شرکت نفتی یک سری کمک از من خواست برای یک پروژه نفتی بین المللی. من فقط برای کمک به دانشجوی سابقم رفتم آنجا و آن موقع 10 سالی بود که من دنبال کار پردازش موازی واقعی می گشتم

 

 

خلاصه خاطره بسیار بدی برای من به جا ماند

 

سلام مجدد بر استاد ارجمند

 

بر من مسجل شده که شما استادی زبر دست در این امرهستید و در حسرت این هستم که چرا افتخار شاگردی در حضور شما را نداشته‌ام

 

ایکاش امکان این بود تا ویدئو کلاسهای خود را بر روی سایتهایی چون مکتب‌خانه بگذارید تا من و سایر دوستان هم بتوانیم از آن استفاده کنیم

 

خاطره بسیار جالبی در مورد لغت کلاستر دارم که شنیدن آن خالی از لطف نیست

روزی یک کد نرم افزاری برای تحلیل خواص مکانیکی (مانند ویسکوزیته) سیالات غیر نیوتنی به نگارش در آورده بودم

برای موازی سازی و تجاری سازی آن به دنیال فاند (پوشش مالی) بودم تا هم بتوانم بحث GUI ، موازی سازی و طراحی ماشین نمونه برای

اجرا بر پایه کارت گرافیکی و همینطور بحث آموزش را پیش ببرم

با توجه به نوع کار به سراغ ستاد نانو رفتم. در ستاد نیز  من را به بخش پشتیبانی از همایشها ارجاع دادند به صورت حضوری ملاقاتی با مسئول آن

داشتم و به طور مفصل عملکرد آن را توضیح دادم و گفتم اگر برای گرید ملی در سال ۸۵ چهل میلیارد تومان (۴۰ ملیون دلار) هزینه کردید و ۴۰۰۰

هسته پردازش ایجاد کردید من برنامه ای تحویل میدهم که با ۲۰۰۰ دلار هزینه بر روی یک کلاستر با ۳۵۰۰ هسته اجرا شود و کلاستر راهم به شما می‌دهم

 

پس از حدود ۲ ساعت توضیح، مسئول محترم رو به من کرد و گفت ببخشید این کلاستر که شما می‌فرمایید چه نوع نرم افزاری هست!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

در نهایت به من گفتند نرم افزار به درد ما نمی خورد اگر می توانید یک چیزی درست کنید و روی میز بگذارید ما کمکتان می‌کنیم

پرسیدم یعنی اگر من caso4 به صورت گرد نانو تولید کنم و رو میز بگزارم شما برای ساخت کارخانه حمایت میکنید؟؟

پاسخ مٍثبت بود آنچه من گفتم گچ ساختمانی بود که نانو پودر آن به هیچ دردی نمی‌حورد مانند بسیاری از محصولات دیگر که

وام چند میلیاردی گرفتند و امروز اسم آنها فقط باقی است

 

 

خانم سلطان‌خواه را دیگر نگویید که برای پروژه های زیر ۵۰ میلیارد اصلا وقت گوش دادن  و فکرکردن ندارند

 

 

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

 

امیدوارم فرصت این را داشته‌باشید تا منابعی برای مطالعه من و سایر دوستان معرفی کنید

 

در ضمن شما کامپایلر PGI را ترجیح می‌دهید آیا این کامپایلرها مزیت خاصی بر کامپایلرهای اینتل مانند ICC , Ifort

و همچنین کاوپایلرهای استاندارد gcc و یا ++g دارند؟ با توجه به آنکه این کامپایلرها فقط در default optimization  

و برخی امکانات جانبی با هم فرق دارند؟

[EMP 6,864]

امیدوارم فرصت این را داشته‌باشید تا منابعی برای مطالعه من و سایر دوستان معرفی کنید

 

در ضمن شما کامپایلر PGI را ترجیح می‌دهید آیا این کامپایلرها مزیت خاصی بر کامپایلرهای اینتل مانند ICC , Ifort

و همچنین کاوپایلرهای استاندارد gcc و یا ++g دارند؟ با توجه به آنکه این کامپایلرها فقط در default optimization  

و برخی امکانات جانبی با هم فرق دارند؟

درود به دوست گرامی

در مورد کامپایلر ها باید بگویم که خیلی مهم هستند. در واقع کامپایلر بهترین دوست یک بهینه ساز هست.

ما باید به ساز کامپایلری که داریم برقصیم و قبل از هرگونه برنامه سازی باید اسنادش را کامل بخوانیم تا به آن کمک کنیم که بهترین کد باینری ممکن را برای ما بسازد.

 

کامپایلر اینتل برای زبان C دچار مشکلاتی است که از سال 2007 تا 2011 ادامه داشت و در واقع باگ ایندکس بدی دارد. من سال 2007 برای اینتل یک نامه نوشتم و خطا را گزارش دادم که اینها از من یک testcase خواستند و من هم نوشتم و برایشان فرستادم که در این Testcase، فقط کامپایلر میکروسافت درست کار می کرد و اینتل و VectorC درست کار نمی کردند. بعد از مدتی Andrew E. Dakowsky که در واقع Head developer کامپایلر اینتل بود به من خبر داد که مشکل حل شده اما بعد از چند سال بعد که من کامپایلر جدید گیر آوردم، دیدم مشکل سر جایش هست هنوز.

 

کامپایلر اینتل در کنار Intel Parallel Studio یک ابزار بسیار قدرتمند در اختیار شما قرار می دهد که برای معماری های مختلف اینتل می توانید کد ویژه کامپایل بکنید که این یعنی شما از جدید ترین دستورالعمل های موجود در این سخت افزار ها (مثلا Skylake i7 ) می توانید استفاده بکنید و برنامه شما دارای کمترین Conditional jump و بهترین کارایی ممکن می شود.(دستورات پرش شزطی پدر معماری pipeline را در می آورند)

کامپایلر های دیگر هیچ کدام چنین امکانی را به شما نمی دهند.

و اما PGI این شرکت در زمینه HPC پیشرو هست و همیشه آخرین تکنولوژی ها نظیر OpenAccelerator ابتدا روی آن می آید و سپس به دیگران سرایت می کند. علاوه بر این PGI پردازنده های AMD را هم خوب می شناسد و این امکان را به شما می دهد که مثلا برای پردازنده بولدوزر خود مطابق با ویژگی های خاص معماری آن کامپایل بکنید که این یعنی پولی که برای سخت افزار داده اید به صورت بهینه استفاده خواهد شد.

PGI گزینه IEEE754 را هم برای اعداد ممیز شناور دارد که در تشخیص خطای محاسباتی خیلی می تواند کمک بکند. با این ابزار می توانیم مطمئن بشویم که تکرار نشدن پاسخ محاسبات با ورودی ثابت در کلاستر ناشی از خطای محاسباتی بوده یا اینکه ناشی از این بوده که ترتیب اجرای Thread ها در نتیجه کار موثر بوده که به معنی data decomposition بد یا برنامه سازی بد است.

خلاصه ابزار خوبی است اگر همیشه نسخه جدید آن را در اختیار داشته باشید

یک قانونی ما داریم که می گوید: we never trust to any compiler به ویژه در کامپایلرهای سخت افزار.

همه کامپایلرها مشکلاتی دارند که با استفاده از طی کردن مسیر معکوس از خروجی به سورس کد امکان تحقیق در مورد صحت کار کامپایلر را داریم که اگر چه برای سخت افزار این کار شدنی است اما برای نرم افزار با اینکه نرم افزار هایی مثل Boomrang و IDA l موجودند اما به هیچ وجه مناسب نیستند به ویژه برای برنامه های OOP.

بنابراین ما مجبوریم که از کامپایلرهایی استفاده بکنیم که دارای استاندارد باشند و بالاترین کیفیت را داشته باشند. تا جایی که من می دانم نه اینتل و نه PGI و نه GCC استاندارد ایمنی ندارند اما حداقل کار بیشتری روی اینتل و PGI با بودجه خیلی بیشتر انجام می شود.

 

در مورد GCC هم باید بگویم که خوب است اما نباید با یک کامپایلری که پشتیبانی مالی خیلی قوی دارد مقایسه بشود. با کامپایلرهای خوب که دارای استاندارد ایمنی هستند بیشترین باگ را می توان از کد بیرون کشید و بعد از آن دیگر باید به امید تست های استاتیک و داینامیک و ابزارهایی مثل stackanalyser و ... بود برای جا نگذاشتن خطا. آخرش هم در ازای هر 1000 خط برنامه 8 خطا جا می ماند!!!

[smorteza 743]

درود به دوست گرامی

در مورد کامپایلر ها باید بگویم که خیلی مهم هستند. در واقع کامپایلر بهترین دوست یک بهینه ساز هست.

در مورد GCC هم باید بگویم که خوب است اما نباید با یک کامپایلری که پشتیبانی مالی خیلی قوی دارد مقایسه بشود. با کامپایلرهای خوب که دارای استاندارد ایمنی هستند بیشترین باگ را می توان از کد بیرون کشید و بعد از آن دیگر باید به امید تست های استاتیک و داینامیک و ابزارهایی مثل stackanalyser و ... بود برای جا نگذاشتن خطا. آخرش هم در ازای هر 1000 خط برنامه 8 خطا جا می ماند!!!

 

سلام بر استاد گرامی

 

ممنون می‌شوم تعریفی از خطا داشته باشید آیا منظور شما فقط خطا در floating point است یا حتی مواردی چون crash برنامه را نیز شامل می‌شود؟

متاسفانه در برنامه نویسی علمی بسیاری از این ظرایف مورد تووجه قرار نمی‌گیرد نمونه آن نیز استفاده‌از goto در این نرم افزارها است شاید

بسیاری از این موارد هم به مسایل مالی مربوط باشد در بسیاری موارد طراح، نویسنده و آزمایشگر نرم افزار یک نفر است و باید مانند آچار

فرانسه عمل کند.

 

به نظر شما decompilerها برای نرم افزارهای تجاری تاچه حد موفق عمل می‌کنند

 

اگر مقدور باشد چند نمونه از باگ‌های کامپایلرها را در حد مقدورات زمانیتان تشریح کنید ممنون می‌شوم

تا جایی که من دیده‌ام همه جا فقط باگ معروف به پاتریوت ( رخ داده در زمان جنگ طوفان صحرا) را به عنوان

باگ ارائه میکنند اما گویا مشکلات فراتر از این موارد است ممنون می‌شوم مثالهای بیشتری معرفی نمایید

 

 

ممنون

[AliMH 362]

برای علاقه مندان به این مبحث :

 

http://www.amazon.com/gp/product/0321446119