میزبانی cpanel رایگان در ابر هاست

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

امکانات هاست رایگان ابر هاست :

ثبت نام رایگان و فوری : http://www.abarhost.ir

ارائه 10000 مگابايت فضای رایگان
اهداي 100000 مگابايت ترافیک
( www.yourdomain.1qq.ir ) اختصاص ادرس وب سایت
نصب آنلاین سیستم های مدیریت محتوا
( Parked Domains ) اختصاص پنج عدد
( Addon Domains ) اختصاص پنج عدد
( SQL Databases ) اختصاص پنج عدد
( Email Accounts ) اختصاص پنج عدد
( FTP Accounts ) اختصاص پنج عدد
( Mailing Lists ) اختصاص پنج عدد
( Subdomains ) اختصاصی پنج عدد


ثبت نام رایگان و فوری : http://www.abarhost.ir

آزمايشگاه پردازش موازی پژوهشگاه هوافضا

 آزمايشگاه پردازش موازی پژوهشگاه هوافضا در سال 1382 با ساخت يک دستگاه رايانه موازی شامل يک سرور و 12 پردازنده شروع به کار کرده‎است. اين آزمايشگاه به تدريج توسعه يافته و  در حال حاضر يک مرکز محاسباتی برای ارائه خدمات محاسباتی به پژوهشگران پژوهشگاه هوافضا و ساير دانشگاه‎ها و مراکز تحقيقاتی محسوب می‎شود.

اهداف:

 به دليل پيچيدگی و حجم بالای محاسبات مورد نياز مسائل محاسباتی مهندسی هوافضا که عمدتاً مسائل واقعی هستند، انجام محاسبات و تحليل نتايج آنها روی رايانه‎های معمولی در عمل غيرممکن است. بنابراين توسعه سامانه‎های پردازش موازی يکی از راه‎کارهای متداول برای غلبه بر اين محدوديت پيشنهاد شده‎است. بر همين اساس پژوهشگاه هوافضا آزمايشگاه پردازش موازی را راه‎اندازی کرده‎است. اهداف اصلی اين آزمايشگاه عبارتند از:

-           ارائه خدمات محاسباتی در زمينه اجرای نرم‎افزارهای محاسبات مهندسی در زمينه‎های ديناميک سيالات محاسباتی، محاسبات اجزاء محدود سازه‎ای، محاسبات نانوتکنولوژی و ديناميک ملکولی

-           ارائه خدمات مشاوره‎ای برای نصب، راه‎اندازی سيستم‎های پردازش موازی

-           ارائه خدمات در زمينه ايجاد مراکز محاسباتی فوق سريع

-           حضور در طرح ابررايانش ملّی

تجهيزات موجود در آزمايشگاه:

 -             6 دستگاه سرور VX50   که در مجموع دارای 192 پردازنده هستند

-           تجهيزات شبکه infiniband   شامل سوئيچ و 6 عدد کارت

-           يک دستگاه رک و ملحقات

-           يک عدد سوئيچ kvm  

-           يک دستگاه نمايشگر قابل نصب در رک

-           بيش از 15 مورد نرم‎افزار تخصصی در زمينه‎های مختلف

سرفصل فعاليت‎ها:

-           نصب نرم‎افزارهای مورد نياز و انجام تنظيمات لازم برای پردازش موازی

-           ارائه خدمات آموزشی

-           توسعه کد‎ها وکتابخانه‎های محاسباتی موازی

زمينه‎های تحقيقاتی در آزمايشگاه:

-           معماری رايانه‎های موازی

-           موازی سازی و افزايش کارايي برنامه‎های موازی

-           انجام مطالعات آيروديناميک، سازه، کنترل و بهينه‎سازی

-           انجام مطالعات ديناميک‎ مولکولی و نانوتکنولوژی

دستاوردها:

-           همکاری در طراحی راکت کاوش

-           ارائه خدمات برای انجام يک مورد رساله دکترای تخصصی و سه مورد رساله کارشناسی ارشد

-           ارائه خدمات در راستای تهيه 5 مقاله برای مجلات و کنفرانس علمی

-           تهيه 4 گزارش فنّی

-           حضور در طرح ابررايانش ملّی

-           تهيه کتابخانه پردازش موازی ARI_MPI

خدمات‎دهی به خارج دانشگاه:

-           ارائه خدمات به دانشجويان دکترا و کارشناسی ارشد دانشگاه صنعتی اميرکبير

-           به‎روزرسانی سيستم پردازش موازی يکی از پژوهشکده‎های وزارت دفاع

راه‎اندازی سيستم پردازش موازی در دانشکده رياضی دانشگاه فردوسی مشهد

 

نشانی : تهران-  شهرك قدس (غرب)، خ ايران زمين، خ مهستان، بالاتر از كلانتري، خ پژوهشگاه هوافضا

صندوق پستي: 834-14668       

نشانی پایگاه اینترنتی: www.ari.ac.ir         

تلفكس: 88366030-021   

آشنایی با پردازش موازی و پردازش در GPU ها

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

        اگر به چند سال پیش برگردیم هیچ بحثی مربوط به پردازش موازی در رابطه با کامپیوترهای شخصی نبود. در صورتی که ابر رایانه ها به صورت عادی از این تکنولوژی بهره میبردند. در واقع با پیشرفت سریع پردازنده ها  هیچ نیازی برای اینکار احساس نمیشد. سرعت پردازنده ها آنقدر رو به افزایش بود که هیچ کس نمیتوانست تصور کند که به همان سرعتی که این پیشرفت صورت میگرفت به همان سرعت هم روزی متوقف خواهد شد و تنها دلیل آن هم یک چیز بود : حرارت. حرارتی باعث ظهور  فن هایی که شما روی CPU تون دارین شدند!* پس شرکت ها مجبور شدند روی به راه حل های دیگری بیاورند و دلیل اصلی آن هم یک چیز بود : رقابت! پس درواقع پردازش موازی یک توفیق اجباری در دنیای کامپیوترهای شخصی به حساب می آید. اما این حرکت که فقط از روی نا امیدی انجام شد به سرعت جایگاه خودش رو پیدا کرد. ایده ی ساده ای بود. برنامتون رو به دو یا چهار یا ... قسمت تقسیم کنید و سرعتتون چند برابر میشه! اما آیا واقعا این پردازش به معنای واقعی موازی است؟! CPU ها ساخته شده اند که عملیات بسیار پیچیده را در زمانی بسیار کم انجام دهند. عملیات پیچیده! آیا یک عملیات پیچیده رو همیشه میشه به دو قسمت یا بیشتر تقسیم کرد؟ زمانی میتوانید از این نوع پردازش استفاده کنید که بخواهید چند پردازش پیچیده یا یک پردازش پیچیده را چند بار به طور مستقل انجام بدید. این مسئله آنقدر آزار دهنده است که هنوز هم پس از سالها بسیاری از برنامه ها نمیتوانند از این نوع پردازش استفاده کنند! پس همچنان هم این نوع پردازش موازی یک نوع اقدام از روی نا امیدی به حساب می آید اما باز هم این اقدام راه جدیدی رو باز کرد این دید که پردازش موازی فقط مال کامپیوترهای غول آسا نیست!

        پردازش موازی به معنای واقعی یعنی اینکه شما بتونید تعداد زیادی از محاسبات رو همزمان انجام بدید. دقیقا همونطور که ابر رایانه ها برای سالیان دراز انجام می دادند. این رویه برای پردازش های موازی در رایانه های شخصی ،در کارت گرافیکی صورت می گیرد. اما چرا کارت گرافیکی به چنین چیزی احتیاج دارد؟ خب در واقع جواب این سوال در صفحه ی نمایشگر شما نهفته است! اگر کمی از نزدیکتر به صفحه ی نمایشگر خودتون نگاه کنید اون تصویر واضحی که از دور برای شما نمایان بود از بین خواهد رفت و یک تصویر نقطه نقطه ظاهر خواهد شد.(این رو روی iPhone 4 به بالا امتحان نکنید!) خب همونطور که حتما میدونید به این نقاط میگن : pixel . این پیکسل ها از چند پیکسل کوچکتر به نام sub pixel تشکیل شده اند که هر کدام از این پیکسل های کوچک قابلیت نمایش یک رنگ را دارند. وظیفه ی کارت گرافیکی شما محاسبه ی شدت رنگ تک تک این ریز پیکسل هاست. میبینید که ما با پردازش های بسیار ساده اما بسیار زیاد سر و کار داریم. اگر بخواهیم این عملیات را با CPU انجام دهیم باید به ترتیب از یک نقطه شروع کنیم و تمام نقاط را پردازش کنیم. مشابه این حالت رو میتونید زمانی که درایور کارت گرافیک خود را نصب نکرده اید مشاهده کنید. صفحه ی نمایشگر شما برای نشان دادن تصاویر ثابت هیچگونه لرزشی نخواهد داشت اما حتی اگر بخواهید یک پنجره ی ساده را جابه جا کنید CPU ی شما از پس این کار ساده  بر نخواهد آمد! پس اینجاست که بحث پردازنده ای مطرح می شود که بتواند تعداد زیادی از داده ها ی بسیار ساده را پردازش کند که خب ما رو میرسونه به GPU ها.

        GPU ها از تعداد نسبتا زیادی پردازنده ی بسیار ساده و کوچک که به اصطلاح به اونا thread میگیم ساخته میشوند. هر کدام از این thread ها میتونن یک ریز پیکسل رو در یک پالس ساعت پردازش کنند. اما آیا GPU ها از لحاظ سخت افزاری طراحی شده اند تا فقط رنگ ها را محاسبه کنند؟! مسلما نه! یک GPU از تعداد زیادی پردازنده ساخته شده که فقط جمع و تفریق بلدند! اما اینکه برای سالها پتانسیل نهفته ی این نوع پردازنده ها شناخته نشده بود تماما به دلیل مشکلات نرم افزاری بود. قبل از معرفی CUDA ، تعداد کمی از محققین به این پتانسیل روی آوردند اما به دلیل مشکلات بسیار زیاد راه به جایی نبردند. مهمترین مشکل پیش روی این افراد این بود که تنها راه برقراری ارتباط با کارت گرافیک از طریق نرم افزارهای خاصی مثل DirectX و OpenGL بود و این واسطه ها فقط و فقط مخصوص پیکسل ها ساخته شده بودند. پس شما اگر میخواستید دو عدد را با هم جمع کنید باید ابتدا اون هارو به دو رنگ تبدیل میکردید. سپس نتیجه ی تلاقی این دو رنگ را بدست می آوردید و اون رو دوباره به عدد برمیگردوندید. اما با معرفی CUDA اکثر مشکلات برطرف شد. CUDA یا Compute Unified Device Architecture یک تکنولوژی بسیار جدید است که در سال 2006 توسط شرکت nvidia به بازار عرضه شد. هدف اصلی این تکنولوژی این بود که تمامی مشکلات پیش روی برنامه نویسان را بردارد که تا حد بسیار زیادی باعث پیشرفت این عرصه شده است.

برای اطلاعات بیشتر رجوع کنید به :

en.wikipedia.org/wiki/GPU_computing

* در واقع این حرارت ناشی از نوع ساخت CPU ها و یا هر پردازنده ی دیگری می باشد برای اطلاعات بیشتر رجوع شود به en.wikipedia.org/wiki/Computer_cooling

ساخت ابرکامپيوترترين ابرکامپيوتر دنيا

ابرکامپيوتر K computer که به‌صورت مشترک توسط کمپاني فوجيتسو و موسسه تحقيقاتي RIKEN ساخته شده، موفق به کسب عنوان قدرتمندترين ابرکامپيوتر دنيا در ليست TOP500 شد.

به گزارش ايسنا، در ليست TOP500، رتبه‌ها و جزئيات 500 ابرکامپيوتر برتر دنيا اعلام مي شود. اين پروژه از سال 1993 آغاز شده است و اين ليست دو بار در سال (ژوئن و نوامبر) به روز و منتشر مي‌شود.

K computer هنوز در مرحله نيم ساخته قرار دارد و پيکربندي آن به طور مشترک توسط اين دو کمپاني در حال توسعه است. اين ابرکامپيوتر از 672 قفسه (computer rack) تشکيل شده است.

در پروژه TOP500 براي مقايسه عملکرد ابرکامپيوترها از برنامه تست LINPACK استفاده مي‌شود که سرعت پردازنده‌ها را بر اساس واحد petaflops اندازه مي‌گيرد و اين ابررايانه با کسب عملکرد 8162 پتافلاپس موفق شده است تا در صدر اين ليست جاي بگيرد.

علاوه بر اين، اين سيستم با درصد بازده محاسباتي 93درصد، از اين نظر نيز استاندارد بالايي را نشان داده است. از ماه ژوئن 2004 که يک ابرکامپيوتر ژاپني به نام "Earth Simulator” توانست رتبه اول را در ليست TOP500 کسب کند، اين اولين بار است که مجددا يک ابرکاپيوتر ژاپني ديگر موفق به کسب چنين افتخاري شده است.

گفتني است RIKEN، شريک سازنده اين ابرکامپيوتر با فوجيتسو درواقع يک موسسه تحقيقاتي ژاپني در زمينه علوم طبيعي است که در سال 1917 پايه گذاري شده است. بودجه سالانه اين موسسه 800 بيليون ين است که تماما توسط دولت ژاپن تامين مي‌شود و در حال حاضر 3000 دانشمند در آن مشغول به کارو در 7 کمپ در ژاپن مستقرند.

کمپاني فوجيتسو شرکتي پيشرو در ارايه راه حل‌هاي پيشرفته و حرفه‌يي به تجارت‌ها و کمپاني‌هايي است که بر پايه ICT در بازارهاي جهاني کار مي‌کنند. اين شرکت در حال حاضر در بيش از 70 کشور دنيا در حال فعاليت و داراي بيش از 170 هزار نيروي کار جهت حمايت و ارايه خدمات به مشتريان است.

فوجيتسو هم‌چنين جهت طراحي و توليد محصولات خود ترکيبي از متخصصان سيستم‌ها و خدمات IT و محصولات ارتباطي و محاسباتي را به وجود آورده است که اين ترکيب باعث مي شود کمپاني بتواند ارزش افزوده‌اي را از طريق محصولات با کيفيت به مشتريان خود ارايه کند.

منبع : http://www.tabnak.ir

پروژه ابررایانه، برگ زرینی در تقویم فناوری

مرکز پردازشهای فوق سریع دانشگاه صنعتی امیرکبیر به بهره برداری رسید و با توجه به اینکه 500 ابررایانه اول دنیا معرفی شده‌اند این ابررایانه کشورمان در رتبه 108 قویترین ابررایانه‌های دنیا قرار می‌گیرد. به این ترتیب نام ایران در زمره چند کشور قوی سازنده کامپیوترهای سریع ثبت شد.

به گزارش خبرنگار مهر، ابررایانه امیرکبیر با بیش از 20 سال تجربه در طراحی سیستم‌های کامپیوتری سریع و ابررایانه‌ها صبح امروز چهارشنبه افتتاح می‌شود. این پروژه با سرمایه گذاری معاونت علمی و فناوری ریاست جمهوری و دانشگاه صنعتی امیرکبیر از اوایل سال 88 آغاز شد. این سیستم با مشارکت دانشکده‌های برق و کامپیوتر این دانشگاه با مدیریت دکتر سیداحمد معتمدی و دکتر محمدکاظم اکبری طراحی و ساخته شده است.

این ابررایانه دارای ریزپردازنده‌ای با 288 عدد گره پردازشی با طراحی همگن و دارای بیش از 4 هزار و 600 هسته پردازشی است.

جمع قدرت محاسباتی این ابررایانه 89 میلیارد عملیات در ثانیه است که شامل 5 /42 ترافلاپس پردازنده‌های اصلی و 5 /46 ترافلاپس پرازنده‌های کمکی است.

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

شبکه ارتباطی این ابررایانه با سرعت 40 مگابیت در ثانیه عمل می‌کند و حجم حافظه اصلی آن به بیش از 9 ترابایت می‌رسد. ظرفیت ذخیره سازی فعلی آن نیز 160 ترابایت (هزار میلیارد بایت) است.

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

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

این ابررایانه همچنین قادر است مسائل عملی و مهندسی را که نیاز به محاسبات قوی و پیچیده دارد حل کند به همین دلیل از آغاز طراحی این سیستم یک تیم متخصص بر روی پیاده سازی نرم افزارهای مورد نیاز مراکز عملی و دانشگاهی و همچنین بخش صنعت فعالیت می‌کنند به طوری که تا کنون بیش از 60 نرم افزار کاربردی مانند نرم افزارهای مهندسی، نرم افزارهای دینامیک مولکولی، نرم افزارهای ERPو CRN، نرم افزارهای RENDERINGو نرم افزارهای پایگاه داده‌ها بر روی این سیستم نصب شده است.

تفاوت ابررایانش دانشگاه صنعتی امیرکبیر و صنعتی اصفهان

* قدرت محاسباتی ابررایانه دانشگاه امیرکبیر 25 درصد قوی‌تراز دانشگاه صنعتی اصفهان است به گونه‌ای که قدرت پردازش در ابررایانه امیرکبیر 5/42 ترافلاپس و در ابررایانه دانشگاه صنعتی اصفهان 34 ترافلاپس است.

* تعداد گره‌های ابررایانه دانشگاه امیرکبیر 288 عدد را طراحی همگن ولی ابررایانه صنعتی اصفهان طراحی ناهمگن با تعریف کلاستر ناسازگار و باعث کاهش کارایی می‌شود.

* حجم حافظه اصلی ابررایانه امیرکبیر 216/9 ترابایت و در دانشگاه اصفهان 5/7 ترابایت است که سیستم امیرکبیر 22 درصد بیشتر از اصفهان است.

* ظرفیت ذخیره سازی فعلی سیستم امیرکبیر بیش از 160 ترابایت و در سیستم دانشگاه صنعتی اصفهان 30 ترابایت است.

* قدرت محاسباتی در سیستم دانشگاه صنعتی امیرکبیر با احتساب پردازشگر کمکی (GPU) برابر 163 ترافلاپس دقت ساده و 5/46 ترافلاپس دقت مضاعف است که این میزان در سیستم دانشگاه صنعتی اصفهان برابر 32 ترافلاپس دقت مضاعف یا ساده نامعلوم است. سیستم امیرکبیر در پردازشگر کمکی بیش از 45 درصد بیشتر از دانشگاه صنعتی اصفهان است.

* مجموع قدرت محاسباتی سیستم امیرکبیر 89 ترافلاپس و رتبه 108 جهانی و قدرت محاسباتی دانشگاه صنعتی اصفهان 66 ترافلاپس و در صورت همگون بودن رتبه 160 جهانی را کسب می‌کند. به عبارت دیگر قدرت پردازش سیستم امیرکبیر بیش از 34 درصد بیشتر از دانشگاه صنعتی اصفهان است.

* مدیریت سیستم امیرکبیر به صورت ابرمختلط (HIBRID CLUB) و از طریق پرتال تحت وب طراحی شده است.

* بهینه سازی منابع سیستم با استفاده از تکنولوژی مجازی سازی انجام می‌شود.

* سیستم دانشگاه امیرکبیر قابلیت اتصال به شبکه ابررایانش ملی را دارد.

* ابررایانه دانشگاه امیرکبیر امکان نظارت یکپارچه بر اجزای سخت افزاری و نرم افزاری را دارد. ضمن آنکه بیش از 60 نرم افزار کاربردی بر روی آن نصب شده است.

منبع : http://www.tabnak.ir

نخستين ابررايانه قابل انطباق جهان

نخستين ابررايانه قابل انطباق جهان

سريع‌ترين و قدرتمندترين ابررايانه جهان با نام Novo-G در دانشگاه فلوريداي ايالات متحده امريکا راه‌اندازي شد.

به گزارش «اعتماد»، قسمت اول نام اين ابررايانه از واژه‌اي لاتين به مفهوم «ايجاد تغيير» برگرفته شده و قسمت دوم آن از واژه Genesis به مفهوم قابل انطباق و به منظور شرح توانايي رايانه‌اي با توانايي بازسازماندهي مدارهاي داخلي براي انطباق با دستور ارائه شده انتخاب شده است.

«آلن جرج» پروفسور مرکز بنياد علوم ملي محاسبات رايانه‌اي قابل انطباق با عملکرد بالا در دانشگاه کاليفرنيا (NSF) معتقد است اين ابررايانه مي‌تواند با محدوده اطلاعات دريافت شده از ماهواره‌هاي فضايي تا ديگر ابررايانه‌ها در ارتباط بوده و پردازش آنها را بر عهده داشته باشد. به گفته وي Novo-G فناوري بسيار قدرتمند و در عين حال پيچيده است و به همين دليل نبايد امکان استفاده از چنين سيستمي تنها در انحصار متخصصان قرار گيرد.

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

اما استفاده از رايانه‌هاي قابل انعطاف مي‌تواند بهترين عملکرد و نتيجه را در هر زمينه تحقيقاتي و پردازش اطلاعات به وجود آورد. اين به آن دليل است که اين رايانه‌ها مي‌توانند مدارهاي داخلي خود را مشابه آجرهاي بازي لگو بازسازماندهي کنند تا ساختار داخلي خود را با نياز موجود براي انجام دستور ارائه شده انطباق دهند.

سرعت عملياتي اين رايانه‌ها نسبت به رايانه‌هاي رايج 10 تا 100 بار سريع تر است در حالي که ميزان انرژي مورد استفاده آنها 10 بار کمتر از ديگر رايانه‌ها است. به گزارش مهر با وجود اينکه ابررايانه Novo-G عملکرد خود را به اثبات رسانده است رايانه‌هاي قابل انطباق در مرحله تحقيقاتي باقي مانده‌اند و استفاده از آنها براي بسياري از کاربران پيچيده و دشوار به شمار مي‌رود. يکي از اصلي ترين اهداف موسسه NSF بهبود دادن فناوري رايانه‌هاي قابل انطباق و افزايش ميزان دسترسي به اين رايانه‌ها براي کاربران مختلف اعلام شده است.

منبع : http://tabnak.ir

 

باز هم تأخير در پيچيده‌ترين پروژه تاريخ بشر

باز هم تأخير در پيچيده‌ترين پروژه تاريخ بشر

سرويس علمي تابناک ـ فعاليت شتاب‌دهنده هادروني بزرگ (ال.اچ.سي.) وابسته به مرکز سازمان اروپايي پژوهش‌هاي هسته‌اي موسوم به «سي.اي.آر.ان.» و يا «سرن»، بار ديگر شش هفته تأخير افتاد.

مرکز سرن اعلام کرد: برابر با برنامه زماني جديد، کار تعمير اين شتاب دهنده و نصب سيستم‌هاي امنيتي و مراقبتي بهتر تا پايان سپتامبر تمام خواهد شد و 20 ميليون يورو هزينه در برخواهد داشت.
آزمايش‌هاي قوي‌ترين شتاب دهنده جهان «ال.اچ.سي.» که عظيم‌ترين آزمايش‌هاي فيزيک و فيزيک ذرات در تاريخ بشر به شمار مي‌رود، دهم سپتامبر سال گذشته (2008) در ژنو آغاز شد، اما چند روز بعد به علت نقص فني اين شتاب‌دهنده، متوقف گرديد.

 

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

هدف آزمايش‌هاي اين شتاب دهنده 27 کيلومتري، پاسخ به سوالات بزرگ فيزيک از طريق اصابت و برخورد پروتون‌ها با يکديگر با سرعتي نزديك به سرعت نور است.

اين شتاب دهنده که در منطقه مرزي فرانسه و سوئيس حدود 100 متر زير زمين قرار دارد، نتيجه کار دسته جمعي و تيمي هزاران پژوهشگر و دانشمند از سراسر جهان است.
طراحي و ساخت قطعات مهم يابنده‌هاي قوي و تحقق هريک از چهار آزمايش اين شتاب دهنده شامل «اطلس»، «آليس»، «سي.ام.اس.» و «ال.اچ.سي.بي.»، به عهده چندين دانشگاه و موسسه علمي بوده است.

شتاب دهنده «ال.اچ.سي.» بيش از 7 هزار تن وزن داشته و به عنوان دوربيني براي تصويربرداري و ثبت ذرات بنيادي به شمار مي‌رود و قوي‌ترين شتاب دهنده ذرات در تاريخ بشر است.
طراحي و ساخت اين شتاب دهنده با يک هزينه 3 ميليارد يورويي، 20 سال طول کشيد و فيزيکدانان معتقدند که پيچيده‌ترين پروژه در تاريخ بشر است.

با اين شتاب دهنده مي‌توان به عمق ميکروهستي و گيتي و ذرات نظر کرد و به جهان سابق و مهبانگ و پيدايش جهان نزديک‌تر شد. بيش از 10 هزار پژوهشگر و دانشمند قرار است در سال‌هاي آينده با اين شتاب دهنده آزمايش‌هاي خود را انجام دهند.

1232 مغناطيس‌هاي (آهن ربا) 15 متري، نگهداري ذرات روي محور شتاب دهنده را به عهده دارند. اين مغناطيس‌ها بايد تا منفي 271 درجه سانتيگراد خنک شوند تا بتوانند فعاليت ذراتي را محقق کنند که با سرعتي نزديك به سرعت نور بر روي محور شتاب دهنده در حرکت هستند.

اين ذرات، ميلياردها پروتون يعني هسته اتم‌هاي هيدروژن هستند و در ابعاد بسته کبريت، بسته بندي شده‌اند. نيمي از اين بسته‌ها در جهت حرکت عقربه ساعت و نيمي نيز در جهت عکس در حرکت هستند و اين ابرهاي پروتوني در برخي از نقاط با تمام قدرت با يکديگر اصابت مي‌کنند.

بر پايه برنامه فيزيکدانان، نخستين آزمايش‌هاي اصابت و برخورد ذرات در اين شتاب دهنده قرار است پايان اکتبر سال جاري انجام گيرد و پس از يک توقف کوتاه براي سرويس آن در پايان سال جاري، اين آزمايش‌ها تا پاييز سال 2010 ميلادي ادامه داشته باشد تا اطلاعات کافي براي اولين تجزيه و تحليل‌ها جمع آوري گردد.

ترجمه: مرتضي جواديان
منبع: سايت مرکز سرن

ابرکامپیوتر 20 پتافلاپي آمد

ابرکامپیوتر 20 پتافلاپي آمد

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

ولی سرانجام شركت آي‌بي‌ام (IBM) در روز 15 بهمن، قوی‌ترین ابرکامپیوتر جهان به نام Sequoia را معرفی کرد. این ابرکامپیوتر 20 برابر قوی‌تر از کامپیوتر رکورددار قبلی است.

Sequoia توانایی انجام 20 کوادریلیون (1015) محاسبه در هر ثانیه (20 پتافلاپ) را خواهد داشت. این مقدار تقریباً معادل قدرت محاسبه بیش از 2 میلیون لپ‌تاپ ساده است.

بیش از 1.6 میلیون قطعه در این کامپیوتر، سرعتی به مراتب بالاتر از ابر کامپیوتر 1.1 پتافلاپی Blue Gene/L را به Sequoia می‌دهد.

این ابر کامپیوتر به سفارش وزارت انرژی آمریکا ساخته شده‌است و انتظار می‌رود که تا سال 2012 در لابراتوار ملی لاورنس لیورمور در کالیفرنیا نصب و راه‌اندازی شود. این لابراتوار بزگترین مرکز تحقیقات انرژی هسته‌ای، حفاظت از محیط زیست و مسائل اقتصادی مرتبط با انرژی است.

Sequioa به همراه کامپیوتر دیگری به نام Dawn در این لابراتوار برای شبیه سازی چرخه تولید انرژی از سوخت هسته‌ای مورد استفاده قرار می‌گیرد.

توانایی ابر کامپیوترها در رسیدن به سرعت‌های بسیار بالا مدیون استفاده از فن‌آوری‌های پیشرفته و ارزان توسط دانشمندان است. سرعت محاسبه یک تریلیون در هر ثانیه در علوم کامپیوتر به ترافلاپ (TeraFlop) معروف است و اولین کامپیوتری که رکورد این سرعت را شکست محصول سال 1996 می‌باشد.

دو سال پیش، کامپیوتر 59 میلیون دلاری ساخت شرکت سان مایکروسیستم به نام Constellation به سرعت 421 تریلیون محاسبه در هر ثانیه رسید.

شركت آي‌بي‌ام همچنین خبر داده‌است که نسل بعدی ابرکامپیوترها به محدوده سرعت اکسافلاپ (Exaflop) یا 1018 محاسبه در هر ثانیه خواهد رسید.

منبع : http://tabnak.ir

 

استاد ايراني دانشگاه واشنگتن ابررايانه‌اي استثنايي طراحي كرد

استاد ايراني دانشگاه واشنگتن ابررايانه‌اي استثنايي طراحي كرد

به گزارش بخش خبر شبكه فن آوري اطلاعات ايران، از ایسنا، اين ابررايانه منحصر به فرد در تحقيقات و برنامه‌هايي محاسبه‌يي كه مستلزم پردازش انبوهي گسترده از داده‌ها و اطلاعات است، استفاده خواهد شد.
دكتر شيرازي، رييس دانشكده مهندسي برق و علوم رايانه‌ دانشگاه واشنگتن در اين باره گفت: اين سيستم همچنين براي محققان در دانشگاه واشنگتن در دسترس خواهد بود و فرصت‌ها را براي همكاري‌هاي علمي و اكتشافي افزايش خواهد داد.
وي خاطر نشان كرد: اين سيستم اساسا يك معماري رايانه‌اي جديد براي حل مشكلات چالشي بزرگ ارائه مي‌كند.
شيرازي تاكيد كرد: ابررايانه XMT شركت جهاني CRAY يك كاتاليزور براي تقويت و گسترش همكاري بين محققان اين شركت، آزمايشگاه ملي نورث وست پاسيفيك و نيز محققان دانشگاه واشنگتن خواهد بود.
اين سيستم قرار است در سال 2008 تا سطح يك سيستم توليدي ارتقاء پيدا كند.
شركت ساخت ابررايانه‌هاي CRAY نيز در اين رابطه اعلام كرد كه XMT داراي يك معماري چند رشته‌يي گسترده و منحصر به فرد و حافظه بزرگ جهاني است و براي كاربردهايي طراحي شده كه مستلزم دسترسي به ترابيت‌هايي از داده‌هاي چيده شده در يك الگوي غيرقابل پيش‌بيني مانند كشف، هوش تجاري و تحليل‌هاي انرژي است.

گفتني است، دكتر شيرازي و همكارانش همچنين از سال گذشته با دريافت اعتباري پژوهشي بالغ بر 6/1 ميليون دلار از سازمان فضايي ناسا، تحقيقات گسترده‌اي را در خصوص طراحي و ساخت حسگرهاي جديد با قابليت بهره‌گيري در نقاطي همچون آتش‌فشان‌ها و همچنين سطح سياره مريخ آغاز كرده‌اند.
به گفته آن‌ها يكي از اهداف مهم اين پروژه طراحي الگوريتمي است تا ميزان مصرف انرژي به حداقل برسد.
از نكات مهم ديگر پروژه اين است كه قرار است تا از اين حسگرهاي ويژه طي يك هماهنگي جهاني با سيستم موقعيت ياب جهاني موسوم به (GPS) جهت دريافت اطلاعات دقيق رفتارهاي غير عادي در محيط‌هاي همچون آتش‌فشانها استفاده شود.

 

منبع : http://mhm20.blogfa.com/post-17.aspx

 

عرضه نخستين تراشه‌هاي شش هسته‌ای اينتل

عرضه نخستين تراشه‌هاي شش هسته‌ای اينتل

اينتل با به نمايش گذاشتن ريزپردازنده‌هاي چندهسته‌يي كه ضمن بالا بردن قدرت رايانش استفاده از برق را كاهش مي‌دهند، نخستين تراشه هاي شش هسته‌يي خود را عرضه كرد.

به گزارش ايسنا، اينتل و Advanced Micro Devices، شركت رقيب آن تراشه هاي دو و چهار هسته‌يي در بازار داشته‌اند.

طبق اظهار معاون گروه اينترپرايز اينتل، تراشه‌ي شش هسته‌يي 50 درصد كارآمدي بيش‌تر نسبت به مدل‌هاي چهار هسته‌يي داشته و در عين حال 10 درصد كمتر برق مصرف مي‌كنند؛ هزينه‌هاي برق و خنك‌سازي تقريبا نيمي از هزينه‌هاي اداره‌ي سرورهاي رايانه‌يي شركت‌ها محسوب مي‌شوند.

تراشه‌هاي چندهسته‌يي معروف به مولتي كور براي گرايش‌هاي رايانشي از جمله مشاهده‌ي ويديوي كيفيت بالاي آنلاين، سرويس‌هاي كاربردي كه شركت‌ها در اينترنت عرضه مي‌كنند و سرورهايي كه دستگاه‌هاي مجازي زيادي برروي آن‌ها كار مي‌كنند، بسيار مفيد هستند.

تراشه‌هاي چندهسته‌يي به رايانه‌ها امكان مي‌دهند همزمان به پردازش وظايف متعددي بپردازند؛ تراشه‌ي Xeon 7400 جديد در سرورهاي ويژه‌ي شبكه‌هاي سازماني شركت‌هاي دل، هيولت پاكارد، آي بي ام، يوني سيس و فوجيتسو به كار خواهد رفت.

منبع : http://www.tabnak.ir

 

مراحل ایجاد یک برنامه client/server در دلفی

مراحل ایجاد یک برنامه client/server در دلفی

بسمه تعالی
مراحل ایجاد یک برنامه clint/server
توضیح : خیلی از عزیزان برای شبکه کردن indy را توصیه می کنند . درست است INDY برای ارسال پیام در شبکه و ایمیل و ... مناسب است ولی برای بانکهای اطلاعاتی درد سر بسیار دارد . در این ثال از datasnap استفاده شده که کار را بسیار راحت می کند .

الف : برنامه سرور
1-یک پروژه جدید باز کنید و با عنوان سرور ذخیره نمایید
2- به قسمت file / new / other/multitier رفته و بر روی remote data server کلیک نمایید
3- حال یک پنجره با عنوان remote data module wizard ایجاد می شود که در قسمت CoClass Name یک نام برای سرور انتخاب نمایید . و به قسمتهای دیگر کاری نداشته باشید و ok را بزنید .
4- بلافاصله یک datamodule جدید با نام سرور (نامی که در قسمت class name انتخاب نمودید ) ایجاد می شود .
5- حال با استفاده از ado یا bde یا ... به با نک اطلاعاتی وصل شوید . مثلا با adoquery به یک جدول از یک بانک اطلاعاتی sql server وصل شده . حال adoqueryr را فعال سازید تا ارتباط برقرار شود . در پنجره مشخصات adoquery خاصیت active را true نمایید .
6- در قسمت dataacess یک DataSetProvider1 را بر روی datamoule که ایجاد کرده ایم قرار می دهیم و روی dataset در پنجره مشخصات کلیک نموده تا نام ارتباط بانک اطلاعاتی نمایان شود ( adoquer در مثال بالا)
7- پس از اطمینال از اتصال صحیح با نک اطلاعاتی پروژه را ذخیره و یک بار اجرا نمایید تا سرور در شبکه ثبت شود .
8- توجه داشته باشید که برنامه سرور فقط محل نگهداری بانک اطلاعاتی و کنترل اتصالات و کاربران است . پس کار دیگری را انجام نمی دهیم و حال فایل اجرایی برنامه سرور را اجرا می کنم.

ب نوشتن برنامه کلاینت
1- یک پروژه جدید با عنوان کلاینت ایجاد نموده و ذخیره نمایید .
2- در روی فرم از قسمت datasnap یک SocketConnection1 را روی فرم قرار داه . در قسمت adress نام ip کامپیوتر سرور را وارد نمایید.(مثلا ip سرور در برنامه محل کار من 10.20.1.93 است ) . اگر ای پی سرور را نمی دانید می توانید نام کامپیوتر سرور را وارد کنید .حال در قسمت servername نام سروری را که در برنامه سرور ثبت کرده اید را انتخاب نمایید . اگه پیام خطا داده احتمالا در تنظیمات شبکه یا خود شبکه ایراد است . وقتی نام سرور را نتخاب کردید گزینه conecct از مشخصات SocketConnection1 vh را true کنید . اگر true شد یعنی ارتنباط با سرور بر قرا است .
3- حال در قسمت datascess یک ClientDataSet1 بر روی فرم قرار داده و تنظیمات زیر را انجام دهید
A: در قسمت remote server کلیک نمایید تا نام socketConnection1 ظاهر شود .
b: در قسمت provider name کلیک کنید تا نام DataSetProvider1 ظاهر شود
c:حال خاصیت active را true کنید .
4- حال از قسمت dataascess یک datasource1 بر روی فرم قرار دهید و خاصیت datadet آن را با نام clientdataset1ظاهر شود .
5- حال از قسمت data control یک datagrid روی فرم قرار داده و خاصیت datasource آن رو datasource 1 انتخاب کنید . می بینید که اطلاعات سرور نمایش داده می شود .

توضیحات . چون ما از SocketConnection2 استفاده می کنیدم که بر اساس tcp/ip عمل می کنید (پشتیبانی سوکت ها ) باید برنامه فعال سوکت ها فعال شود . برای این کار مرحل زیر را انجام دهید
1- در قسمت run ویندوز دستور cmd را تایپ نمایید .
2- پس از ورود به محیط cmd دستور مقابل را تایپ نمایید scktsrvr - install .

توضیح 2 : فرض بر این است که کلیه خوانندگان عزیز با بانک اطلاعتی و ارتباط با ان آشنایی دارند . اگر می خواهید به نتیجه برسید نامگذاری اشیاعی که بر روی فرم ها و ... می گذارید عین مثال باشد .
امیدوارم مورد استفاده قرار گرفته باشد .

منبع : http://delphi-7.blogfa.com

 

 

ساخت سریع ترین رایانه جهان در آمریکا

ساخت سریع ترین رایانه جهان در آمریکا

دانشمندان آمریکایی در آزمایشگاه دولتی اسلحه «لوس آلاموس»، موفق به ساخت پر شتاب ترین کامپیوتر جهان موسوم به «رودرانر» شده‌اند.

به گزارش سرویس علم و فن آوری آفتاب، این رایانه توانایی انجام 1000 تریلیون عملیات در ثانیه را داراست.

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

«سمیوئل بادمن» سخنگوی دانشکده انرژی در این باره اظهار داشت: « این کامپیوتر موسوم به رودرانر ( roadrunner )همچنین قرار است برای یافتن پاسخ برای مشکلات انرژی جهانی و گشودن درهای تازه به سوی دانش در پژوهش های بنیادی به کار گرفته شود.

منبع : http://www.aftabnews.ir/vdcdk50ytx095.html

 

Using DRMAA with Unicluster Express

Using DRMAA with Unicluster Express

Distributed Resource Management Application API (DRMAA) is a high-level API that allows Grid applications to submit, monitor and control jobs to one or more DRM systems. Grid Engine comes with support for C/C++ and java, and one can also download bindings for ruby and python. There is also a nice collection of HowTos that should provide a great start for anyone looking to start writing DRMAA applications. The latest version of Unicluster Express (UCE) bundles Grid Engine 6.1u3, which is installed under $GLOBUS_LOCATION/sge. The $GLOBUS_LOCATION refers to the UCE installation directory (/usr/local/unicluster by default), and all of the DRMAA libraries and java files are located in the $GLOBUS_LOCATION/sge/lib directory. In order to run DRMAA applications, one has to set $LD_LIBRARY_PATH to point to the appropriate (architecture dependent) directory. For my development (64-bit linux) cluster with default UCE installation I used the following setup:

$ source /usr/local/unicluster/unicluster-user-env.sh
$ export LD_LIBRARY_PATH=/usr/local/unicluster/sge/lib/lx24-amd64
$ export JAVA_HOME=/opt/jdk
$ export PATH=$JAVA_HOME/bin:$PATH

A very simple example of a java DRMAA application that submits a job to Grid Engine is shown below:

$ cat SimpleJob.java 
import org.ggf.drmaa.DrmaaException;
import org.ggf.drmaa.JobTemplate;
import org.ggf.drmaa.Session;
import org.ggf.drmaa.SessionFactory;
public class SimpleJob {
  public static void main(String[] args) {
    SessionFactory factory = SessionFactory.getFactory();
    Session session = factory.getSession();
    try {
      session.init("");
      JobTemplate jt = session.createJobTemplate();
      jt.setRemoteCommand("/home/veseli/simple_job.sh");
      String id = session.runJob(jt);
      System.out.println("Your job has been submitted with id " + id);
    } 
    catch (DrmaaException e) {
      System.out.println("Error: " + e.getMessage());
    }
  }
}

One can compile and run the above example using something like the following:

$ javac -classpath /usr/local/unicluster/sge/lib/drmaa.jar SimpleJob.java 
$ java -classpath .:/usr/local/unicluster/sge/lib/drmaa.jar SimpleJob
Your job has been submitted with id 14
$ qstat -f 
queuename                      qtype used/tot. load_avg arch          states
----------------------------------------------------------------------------
[e-mail]   BP    1/1       0.36     lx24-amd64  
14 0.55500 simple_job veseli       r     06/20/2008 12:24:59     	1          
----------------------------------------------------------------------------
[e-mail]     BP    0/1       0.39     lx24-amd64    
----------------------------------------------------------------------------
[e-mail]    BP    0/1       0.45     lx24-amd64    
----------------------------------------------------------------------------
[e-mail] IP    0/1       0.15     lx24-amd64    
----------------------------------------------------------------------------
[e-mail].c BIP   0/1       0.36     lx24-amd64    

I should point out that DRMAA is designed to be independent of any particular DRM. Those users that need job submission features or flags specific to Grid Engine can either use the “native specification” attribute, or they can use the “job category” attribute together with “qtask” files. In order to set native specification attribute in java one would use setNativeSpecification() method of the JobTemplate class (before the job submission line in the code):

jt.setNativeSpecification("-q special.q");

This method, however, makes your application dependent on the specific DRM you are working with at the moment. The above line will be interpreted correctly by Grid Engine, but may not be understood by other DRMs. In most cases a better solution is to use the job category attribute instead, and specify the DRM-dependent flags in the qtask file. For example, in order to submit your job to a particular Grid Engine queue in the java code one would have something like

jt.setJobCategory("special");

and use the qtask file to translate the “special” job category into appropriate Grid Engine flags:

$ cat ~/.qtask
special -q special.q

The cluster global qtask file (defines cluster wide defaults) in UCE resides at $GLOBUS_LOCATION/sge/default/common/qtask. As shown above, user-specific qtask files that override and enhance cluster-wide definitions are found at ~/.qtask.

منبع : http://gridgurus.typepad.com

 

Aromatic Clouds

Aromatic Clouds?

If you weren’t at OSGC you missed a number of interesting presentations. From my perspective, one of the most intriguing technologies was EUCALYPTUS: Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems.

Before I go on, I would like you to notice that anybody who is able to make an acronym out of eucalyptus has some time on their hands. Fortunately, they used this time to implement an open-source infrastructure for Elastic Computing. In particular, the goal of the project is to, "foster community research and development of Elastic/Utility/Cloud service implementation technologies, resource allocation strategies, service level agreement (SLA) mechanisms and policies, and usage models."

In my opinion, the most interesting facets of this project are:

• It is compatible with the Amazon EC2 tools out of the box yet it is agnostic and thus is capable of supporting any number of client interfaces;
• Any team can assemble a development environment for tools that they wish to deploy to the EC2 Cloud;
• A group could create their own Cloud system which could use EC2 for Utility computing resources;
• It is the first step towards creating an open-standard for Cloud computing.

My hope is that this project will not only get us all thinking about what we really need from a Cloud but also what we could improve... I plan to start working with this software as soon as it is available later this month.

منبع : http://gridgurus.typepad.com

 

ابر رايانه به تشخيص پوکي استخوان کمک مي کند

ابر رايانه به تشخيص پوکي استخوان کمک مي کند   تهران-خبرگزاری جمهوری اسلامی (ایرنا): دانشمندان سوييسي از دستاورد جديدي در شبيه سازي ابر رايانه اي خبر دادند که مي تواند تا اندازه زيادي به تشخيص و درمان پوکي استخوان کمک کند.

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

 

About Grid Engine Advanced Reservations

About Grid Engine Advanced Reservations

Advanced reservation (AR) capability is one of the most important new features of the upcoming Grid Engine 6.2 release. New command line utilities allow users and administrators to submit resource reservations (qrsub), view granted reservations (qrstat), or delete reservations (qrdel). Also, some of the existing commands are getting new switches. For example, the “-ar “ option for qsub indicates that the submitted job is a part of an existing advanced reservation. Given that AR is a new functionality, I thought that it might be useful to describe how it works on a simple example (using 6.2 Beta software). Advanced resource reservations can be submitted to Grid Engine by queue operators and managers, and also by a designated set of privileged users. Those users are defined in ACL “arusers”, which by default looks as follows:

$ qconf -sul
arusers
deadlineusers
defaultdepartment

$ qconf -su arusers
name    arusers
type    ACL
fshare  0
oticket 0
entries NONE

The “arusers” ACL can be modified via the “qconf -mu” command:

$ qconf -mu arusers
[e-mail] modified "arusers" in userset list

$ qconf -su arusers
name    arusers
type    ACL
fshare  0
oticket 0
entries veseli

Once designated as a member of this list, the user is allowed to submit ARs to Grid Engine:

[veseli@tolkien]$ qrsub -e 0805141450.33 -pe mpi 2
Your advance reservation 3 has been granted

[veseli@tolkien]$ qrstat
ar-id   name       owner        state start at             end at               duration
-----------------------------------------------------------------------------------------
      3            veseli       r     05/14/2008 14:33:08  05/14/2008 14:50:33  00:17:25

[veseli@tolkien]$ qstat -f 
queuename                      qtype resv/used/tot. load_avg arch          states
---------------------------------------------------------------------------------
[e-mail]       BIP   2/0/4          0.04     lx24-x86      

For the sake of simplicity, in the above example we have a single queue (all.q) that has 4 job slots and a parallel environment (PE) mpi assigned to it. After reserving 2 slots for the mpi PE, there are only 2 slots left for running regular jobs until the above shown AR expires. Note that the "–e" switch for qrsub designates requested reservation end time in the format YYMMDDhhmm.ss. It is also worth pointing out that the qstat output changed slightly with respect to previous software releases in order to accommodate display of existing reservations. If we now submit several regular jobs, only 2 of them will be able to run:

[veseli@tolkien]$ qsub regular_job.sh 
Your job 15 ("regular_job.sh") has been submitted
...
[veseli@tolkien]$ qsub regular_job.sh 
Your job 19 ("regular_job.sh") has been submitted

[veseli@tolkien]$ qstat -f
queuename                      qtype resv/used/tot. load_avg arch          states
---------------------------------------------------------------------------------
[e-mail]       BIP   2/2/4          0.03     lx24-x86      
     15 0.55500 regular_jo veseli       r     05/14/2008 14:34:32     1        
     16 0.55500 regular_jo veseli       r     05/14/2008 14:34:32     1        

############################################################################
 - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
     17 0.55500 regular_jo veseli       qw    05/14/2008 14:34:22     1        
     18 0.55500 regular_jo veseli       qw    05/14/2008 14:34:23     1        
     19 0.55500 regular_jo veseli       qw    05/14/2008 14:34:24     1        

However, if we submit jobs that are part of the existing AR, those are allowed to run, while jobs submitted earlier are still pending:

[veseli@tolkien]$ qsub -ar 3 reserved_job.sh 
Your job 20 ("reserved_job.sh") has been submitted
[veseli@tolkien]$ qsub -ar 3 reserved_job.sh 
Your job 21 ("reserved_job.sh") has been submitted

[veseli@tolkien]$ qstat -f
queuename                      qtype resv/used/tot. load_avg arch          states
---------------------------------------------------------------------------------
[e-mail]       BIP   2/4/4          0.02     lx24-x86      
     15 0.55500 regular_jo veseli       r     05/14/2008 14:34:32     1        
     16 0.55500 regular_jo veseli       r     05/14/2008 14:34:32     1        
     20 0.55500 reserved_j veseli       r     05/14/2008 14:35:02     1        
     21 0.55500 reserved_j veseli       r     05/14/2008 14:35:02     1        

############################################################################
 - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS - PENDING JOBS
############################################################################
     17 0.55500 regular_jo veseli       qw    05/14/2008 14:34:22     1        
     18 0.55500 regular_jo veseli       qw    05/14/2008 14:34:23     1        
     19 0.55500 regular_jo veseli       qw    05/14/2008 14:34:24     1        

The above example illustrates how ARs work. As long as particular reservation is valid, only jobs that are designated as part of it can utilize resources that have been reserved. I think that AR will prove to be extremely valuable tool for planning grid resource usage, and I’m very pleased to see it in the new Grid Engine release.

منبع : http://gridgurus.typepad.com

 

Steaming Java

Steaming Java

When Rich asked us to walk through a software development process, I immediately thought back to a conversation that I had with my friend Leif Wickland about building high-performance Java applications. So I immediately emailed him asking him for his best practices. We have both produced code that is as fast, if not faster than C compiled with optimization (for me it was using a 64-bit JRE on a x86_64 architecture with multiple cores).

That is not to say that if you were to spend time optimizing the equivalent C-code that it would not be made to go faster. Rather, the main point is that Java is a viable HPC language. On a related note, Brian Goetz of Sun has a very interesting discussion on IBM's DeveloperWorks, Urban performance legends, revisited on how garbage collection allows faster raw allocation performance.

However I digress… Here is a summary of what we both came up with (in no particular order):

       

1. It is vitally important to "measure, measure, measure," everything you do.  We can offer any set of helpful hints but the likelihood that all of them should be applied is extremely low.        
2. It is equally important to remember to only optimize areas in the program that are bottlenecks. It is a waste of development time for no real gain.        
3. One of the most simple and overlooked things that help your application is to overtly specify method parameters that are read-only using the final modifier. Not only can it help the compiler with optimization but it also is a good way of communicating your intentions to your teammates. Furthermore, i f you can make your method parameters final, this will help even more. One thing to be aware of is that not all things that are declared final behave as expected (see Is that your final answer? for more detail).        
4. If you have states shared between threads, make whatever you can final so that that the VM takes no steps to ensure consistency. This is not something that we would have expected to make a difference, but it seems to help.        
5. An equally ignored practice is using the finally clause. It i s very important to clean up the code in a try block. You could leave open streams, SQL queries, or perhaps other objects lying around taking up space.        
6. Create your data structures and declare your variables early. A core goal is to avoid allocating short-lived variables. While it is true that the garbage collector may reserve memory for variables that are declared often, why make it have to try to guess your intentions. For example, if a loop is called repeatedly, there is no need to say, for (int i = 0; … when you should have declared i earlier. Of course you have to be careful not to reset counters from inside of loops.        
7. Use static for values that are constants. This may seem obvious, but not everybody does.        
8. For loops embedded within other loops:                

                           

   • Replace your outer loop with fixed-pool of threads. In the next release of java, this will be even easier using the fork-join keywords. This has become increasingly important with processors with many cores.                         
   • Make sure that your innermost loop is the longest even if it doesn't necessarily map directly to the business goals. You shouldn't force the program to create a new loop too often as it wastes cycles.        
   • Unroll your inner-loops. This can save an enormous amount of time even if it isn't pretty. The quick test I just ran was 300% faster. If you haven' t unrolled a loop before, it is pretty simple:        
             unrollRemainder = count%LOOP_UNROLL_COUNT;
            
             for( n = 0; n < unrollRemainder; n++ ) {
                 // do some stuff here.
             }
            
             for( n = unrollRemainder; n < count; n+=LOOP_UNROLL_COUNT ) {
                 // do stuff for n here
                 // do stuff for n+1 here
                 // do stuff for n+2 here
                 …
                 // do stuff for n+LOOP_UNROLL_COUNT - 1 here
             }
             Notice that both n and unrollRemainder were declared earlier as recommended previously.
          
9. Preload all of your input data and then operate on it later. There is absolutely no reason that you should be loading data of any kind inside of your main calculation code. If the data doesn't fit or belong on one machine, use a Map-Reduce approach to distribute it across the Grid.        
10. Use the factory pattern to create objects.                

                            

    • Data structures can be created ahead of time and only the necessary pieces are passed to the new object.                         
    • Any preloaded data can also be segmented so that only the necessary parts are passed to the new object.                         
    • You can avoid the allocation of short-lived variables by using constructors with the final keyword on its parameters.                         
    • The factory can perform some heuristic calculations to see if a particular object should even be created for future processing.
           
11. When doing calculations on a large number of floating-point values, use a byte array to store the data and a ByteWrapper to convert it to floats. This should primarily be used for read only (input) data. If you are writing floating-point values you should do this with caution as it may take more time than using a float array. One major advantage that Java has when you use this approach is that you can switch between big and little-endian data rather easily.        
12. Pass fewer parameters to methods. This results in less overhead. If you can pass a static value it will pass one fewer parameter.        
13. Use static methods if possible. For example, a FahrenheitToCelsius(float fahrenheit); method could easily be made static. The main advantage here is that the compiler will likely inline the function.        
14. There is some debate whether you should make particular methods final if they are called often. There is a strong argument to not do this because the enhancement is small or nonexistent (see Urban Performance Legends or once again Is that your final answer?). However my experience is that a small enhancement on a calculation that is run thousands of times can make a significant difference. Both Leif and I have seen measurable differences here. The key is to benchmark your code to be certain.

منبع : http://gridgurus.typepad.com

 

Grid Interoperability and Interoperation

Grid Interoperability and Interoperation

The high expectations raised by grid computing have favored the development and deployment of a growing number of grid infrastructures and middlewares. However, the interaction between these grids is still limited, so reducing the potential large-scale application of grid technology, in spite of efforts made by grid community. In this sense, the Open Grid Forum (OGF) is developing open standards for grid software interoperability, while the OGF's Grid Interoperation Now Community Group (GIN-CG) is coordinating a set of interoperation efforts among production grids. It is therefore clear that, according to OGF (as Laurence Field explains in his article entitled "Getting Grids to work together: interoperation is key to sharing"), there is a big difference between these two terms:

• Interoperability is the native ability of grids and grid technologies to interact directly via common open standards.

• Interoperation is a set of techniques to get production grid infrastructures to work together in the short term.

Since most common open standards to provide grid interoperability are still being defined and only a few have been consolidated, grid interoperation techniques, like adapters and gateways, are needed. An adapter is, according to different dictionaries of computer terms, “a device that allows one system to connect to and work with another”. On the other hand, a gateway is conceptually similar to an adapter, but it is implemented as an independent service, acting as a bridge between two systems. The main drawback of adapters is that grid middleware or tools must be modified to insert the adapters. Gateways can be accessed without changes on grid middleware or tools, but they can become a single point of failure or a scalability bottleneck.

GridWay provides support for some of the few established standards like DRMAA, JSDL or WSRF to achieve interoperability but, in the meanwhile, it also provides components to allow interoperation, like Middleware Access Drivers (MADs) acting as adapters for different grid services, and the GridGateWay, which is a WSRF GRAM service encapsulating an instance of GridWay, thus providing a gateway for resource management services.

GridWay 4.0.2, coinciding with the release of Globus Toolkit 4 and its new WS GRAM service, introduced an architecture for the execution manager module based on a MAD (Middleware Access Driver) to interface several grid execution services, like pre-WS GRAM and WS GRAM, even simultaneously. That architecture was presented in the paper entitled "A modular meta-scheduling architecture for interfacing with pre-WS and WS Grid resource management services" (E. Huedo, R. S. Montero and I. M. Llorente). GridWay 5.0 took advantage of this modular architecture to implement an information manager module with a MAD to interface several grid information services, and a transfer manager module with a MAD to interface several grid data services. Moreover, the scheduling process was decoupled from the dispatch manager through the use of an external and selectable scheduler module.

The resulting architecture, which is shown above, provides direct interoperation between different middleware stacks. In fact, we demonstrated at OGF22 the interoperation of three important grid infrastructures, namely EGEE (gLite-based), TeraGrid and OSG (both Globus-based), being coordinately used through a single GridWay instance by means of the appropriate adapters. To set an example, the application was written using the DRMAA OGF standard. GridWay documentation provides a lot of information on how to integrate GridWay in the main middleware stacks, like gLite, pre-WS and WS Globus, or ARC, and provides information on how to develop new drivers for other middlewares.

Regarding the GridGateWay, it is being used for provisioning resources from several infrastructures. For example, the German Astronomy Community Grid (GACG or AstroGrid-D) uses a GridGateWay as a central resource broker, providing metascheduling functionality to Globus-based submission tools (e.g. for workflow execution) without modification. GridAustralia also uses a GridGateWay as a WSRF interface for its central GridWay Metascheduler instance, allowing reliable, remote job submission.

Picture by AstroGrid-D

More information about the GridGateWay component is provided in its web page, as well as in this blog entry, which shows how to build Utility Computing infrastructures with this Globus-based gateway technology.

Eduardo Huedo

Reprinted from blog.dsa-research.org

منبع : http://gridgurus.typepad.com

Grid Engine 6.2 Beta Release

Grid Engine 6.2 Beta Release

Grid Engine 6.2 will come with some interesting new features. In addition to advance resource reservations and array job interdependencies, this release will also contain a new Service Domain Manager (SDM) module, which will allow distributing computational resources between different services, such as different Grid Engine clusters or application servers. For example, SDM will be able to withdraw unneeded machines from one cluster (or application server) and assign it to a different one or keep it in its “spare resource pool”. It is also worth mentioning that Grid Engine (and SDM) documentation is moving to Sun’s wiki. The 6.2 beta release is available for download here.

منبع : http://gridgurus.typepad.com

 

About Parallel Environments in Grid Engine

About Parallel Environments in Grid Engine

Support for parallel jobs in distributed resource management software is probably one of those features that most people do not use, but those who do appreciate it a lot. Grid Engine supports parallel jobs via parallel environments (PE) that can be associated with cluster queues. New parallel environment is created using the qconf -ap command, and editing the configuration file that pops up. Here is an example of a PE slightly modified from the default configuration:

$ qconf -sp simple_pe
pe_name           simple_pe
slots             4
user_lists        NONE
xuser_lists       NONE
start_proc_args   /bin/true
stop_proc_args    /bin/true
allocation_rule   $round_robin
control_slaves    FALSE
job_is_first_task FALSE
urgency_slots     min

In the above example, “slots” defines number of parallel tasks that can be run concurrently. The “user_lists” (“xuser_lists”) parameter should be a comma-separated list of user names that are allowed (denied) use of the given PE. If “user_lists” is set to NONE, any user that is not explicitly disallowed via the “xuser_lists” parameter. The “start_proc_args” and “stop_proc_args” represent command line of startup and shutdown procedures for the parallel environment. These commands are usually scripts customized for a specific parallel library intended for a given PE. They get executed for each parallel job, and are used, for example, start any necessary daemons that enable parallel job execution. The standard output (error) of these commands are redirected into .po(pe). files in the job’s working directory, which is usually user’s home directory. It is worth noting that the customized PE startup and shutdown scripts can make use of several internal variables, such as $pe_hostfile and $job_id, that are relevant for the parallel job. The $pe_hostfile variable in particular points to a temporary file that contains list of machines and parallel slots allocated for the given job. For example, setting “start_proc_args” to “/bin/cp $pe_hostfile /tmp/machines.$job_id” would copy $pe_hostfile to the /tmp directory. Some of those internal variables are also available to job scripts as environment variables. In particular $PE_HOSTFILE and $JOB_ID environment variables will be set and will correspond to $pe_hostfile and $job_id, respectively. The “allocation_rule” parameter helps scheduler decide how to distribute parallel processes among the available machines. It can take an integer that fixes the number of processes per host, or special rules like $pe_slots (all processes have to be allocated on a single host), $fill_up (start filling up slots on the best suitable host, and continue until all slots are allocated), and $round_robin (allocate slots one by one on each allocated host in a round robin fashion until all slots are filled). The “control_slaves” parameter is slightly confusing. It indicates whether or not the Grid Engine execution daemon creates parallel tasks for a given application. In most cases (e.g., for MPI or PVM) this parameter should be set to FALSE, as custom Grid Engine PE interfaces are required for getting control of parallel tasks to work. Similarly, the “job_is_first_task” parameter is only relevant if control_slaves is set to TRUE. It indicates whether or not the original job script submitted execution is part of the parallel program. The “urgency_slot” parameter is used for jobs that request range of parallel slots. If an integer value is specified, that number is used as prospective slot amount. If “min”, “max”, or “avg” is specified, the prospective slot amount will be determined as the minimum, maximum or average of the slot range, respectively. After a parallel environment is configured and added to the system, it can be associated with any existing queue by setting the “pe_list” parameter in the queue configuration, and at this point users should be able to submit parallel job. On the GE project site one can find a number of nice How-To documents related to integrating various parallel libraries. If you do not have patience to build and configure one of those, but you would still like to see how stuff works, you can try adding a simple PE (like the one shown above) to one of your queues, and use a simple ssh-based master script to spawn and wait on the slave tasks:

#!/bin/sh
#$ -S /bin/sh
slaveCnt=0
while read host slots q procs; do
  slotCnt=0
  while [ $slotCnt -lt $slots ]; do
    slotCnt=`expr $slotCnt + 1`
    slaveCnt=`expr $slaveCnt + 1`
    ssh $host "/bin/hostname; sleep 10" > /tmp/slave.$slaveCnt.out 2>&1  &
  done
done < $PE_HOSTFILE
while [ $slaveCnt -gt 0 ]; do
  wait 
  slaveCnt=`expr $slaveCnt - 1`
done
echo "All done!"

After saving this script as "master.sh" and submitting your job using something like "qsub -pe simple_pe 3 master.sh" (where 3 is the number of parallel slots requested), you should be able to see your "slave" tasks running on the allocated machines. Note, however, that you must have password-less ssh access to the designated parallel compute hosts in order for the above script to work.

منبع : http://gridgurus.typepad.com