- •1. Назвати основні сфери застосування високопродуктивних систем опрацювання даних і коротко їх охарактеризувати.
- •2. Навести класифікацію обчислювальних систем згідно з м.Флінном.
- •3. Навести основні архітектури високопродуктивних систем опрацювання даних.
- •4.Архітектура мрр
- •5.Архітекттура smp
- •7. Охарактерізуваті архітектуру numa.
- •8. Охарактеризувати кластерні системи.
- •9. Охарактерізуваті архітектуру grid.
- •10.Навести переваги використання багатоядерних процесорних систем у порівнянні з багатопроцесорними системами.
- •11. Навести переваги використання спеціалізованих графічних процесорів (gpu) у порівнянні з центральними процесорами (cpu) комп'ютерних систем для високопродуктивних обчислень.
- •12.Як визначається час виконання паралельного алгоритму?
- •13. Мінімальний можливий час виконання паралельного алгоритму визначається довжиною максимального шляху обчислювальної схеми алгоритму:
- •14. Основною характеристикою алгоритму, визначальною ефективність його виконання на багатопроцесорній системі є його ступінь паралелізму.
- •16.Закон Амдала
- •17.Закон Густавсона – Барсиса
- •20. Навести та охарактеризувати основні типи апаратних комунікаційних інтерфейсів для організації високопродуктивних систем опрацювання даних.
- •22.Охарактеризувати спеціалізований комунікаційний інтерфейс Myrinet
- •23.Охарактеризувати комунікаційний інтерфейс Gigabit Ethernet.
- •25 Охарактеризувати принципи роботи технології виклику віддалених процедур, методів, обєктів
- •26 Дати означення терміну маршалізація даних при виклику віддалених процедур
- •27 Дати означення терміну серіалізація обєктів
- •28. Пояснити причини використання клієнтської та серверної заглушок (stub) при написанні програм виклику віддалених процедур та методів.
- •29. Навести основні проблеми, які виникають при використанні технологій виклику віддалених процедур, методів, об'єктів.
- •30. Охарактеризувати технологію rpc.
- •31.Архітектура rmi.
- •1.Rmi (англ. Remote Method Invocation) - програмний інтерфейс виклику видалених методів в мові Java.
- •34. Охарактерізуваті технологію dcom
- •35. Проаналізувати використання программ з багатьма підпроцесами для організації високопродуктивних систем опрацювання даних.
- •36.Дати означення термінам семафор, м'ютекс, критична секція.
- •37.Навести основні проблеми, які виникають при використанні програм з багатьма підпроцесами, зокрема гонка процесів, вхід/вихід з критичних секцій, синхронізація підпроцесів.
- •38.Проаналізувати використання програм зі з'єднанням на основі сокетів для організації високопродуктивних систем опрацювання даних.
- •39.Дати означення терміну сокет, мережевий сокет, unix-сокет.
- •42. Навести приклад найпростішої програми на мові с з використанням технології mpi, яка виводить прізвище студента
- •43 Описати процес компіляції і виконання програми засобами середовища OpenMpi та компілятора gcc.
- •51Директива parallel
- •57. Охарактеризувати технологію pvm.
- •58 Проаналізувати можливість використання технології OpenMp, mpi та mpi/openmp на архітектурах mpp, smp та кластерній
- •59 Охарактеризувати високодоступні кластери
- •60 Охарактеризувати високопродуктивні кластери
- •61. Які є базові операції rpc?
- •62.Які є етапи виконання rpc.
- •63.Навести основні етапи розробки паралельних алгоритмів.
- •65.Навести і описати паралельні методи множення матриць.
- •66. Навести і описати паралельні методи розв'язку систем лінійних рівнянь.
- •67. Навести і описати паралельні методи сортування.
- •69.Навести і описати паралельні методи розв'язання диференціальних рівнянь у частинних похідних.
- •71. У вихідному коді програми на мові с вставити пропущені виклики процедур підключення мрі, визначення кількості процесів і рангу процесів.
- •72. Програма, яка виводить «Hello Word from process I for n».
- •73. Програма генерації чисел в одному процесі і сумування їх у іншому процесі і надсилення результату в перший процес.
- •88. Написати програму з використанням бібліотеки Posix threads на мові с з метою тестування роботи кластера під керуванням OpenMosix. Тестування провести з замірами часу.
31.Архітектура rmi.
1.Rmi (англ. Remote Method Invocation) - програмний інтерфейс виклику видалених методів в мові Java.
Опис роботи
Розподілена об'єктна модель, що специфікує, яким чином проводиться виклик видалених методів, що працюють на іншій віртуальній машині Java.
При доступі до об'єктів на іншому комп'ютері можливо викликати методи цього об'єкту. Необхідно тільки доставити параметри методу на інший комп'ютер, повідомити об'єкт про необхідність виконання методу, а потім передати значення, що назад повертається. Механізм RMI дає можливість організувати виконання всіх цих операцій.
В термінах RMI об'єкт, який викликає видалений метод, називається клієнтським об'єктом, а видалений об'єкт - серверним об'єктом. Комп'ютери виступають в ролі клієнта і серверу тільки для конкретного виклику. Цілком можливо, що при виконанні наступної операції ці комп'ютери поміняються ролями, тобто сервер попереднього виклику може сам стати клієнтом при зверненні до об'єкту на іншому комп'ютері.
При виклику методу видаленого об'єкту насправді викликається звичайний метод мови Java, інкапсульований в спеціальному об'єкті-заглушці (stub), який є представником серверного об'єкту. Заглушка знаходиться на клієнтському комп'ютері, а не на сервері. Вона упаковує параметри видаленого методу в блок байтів. Кожний параметр кодується за допомогою алгоритму, що забезпечує незалежність від апаратури. Наприклад, числа завжди передаються в порядку, при якому спочатку передається старший байт (big-endian). При цьому об'єкти піддаються сериализации. Процес кодування параметрів називається розгортанням параметрів (parameter marshaling). Основна мета розгортання параметрів - перетворення їх у формат, придатний для передачі параметрів від однієї віртуальної машини до іншої.
Метод, що належить заглушці, створює блок, в який входять наступні елементи:
ідентифікатор видаленого об'єкту;
опис методу, що викликається;
розгорнені параметри.
Потім метод заглушки посилає цю інформацію серверу. Далі об'єкт-одержувач виконує для кожного виклику видаленого методу наступні дії:
згортання параметрів;
пошук викликаного об'єкту;
виклик заданого методу;
витягання і розгортання значення або виключення, що згенерувало даним методом, що повертається;
передача пакету, що складається з розгорнених даних, що повертаються, об'єкту-заглушці на клієнтському комп'ютері.
Клієнтський об'єкт-заглушка згущає значення або виключення, одержане з серверу, що повертається. Результат згортання стає значенням методу заглушки, що повертається. Якщо видалений метод повертає виключення, то об'єкт-заглушка повторить його в середовищі об'єкту-клієнта.
Для виклику видаленого методу використовується той же синтаксис, що і для звернення до локального методу. Наприклад, щоб викликати метод getQuantity() об'єкту-заглушки сеntralWarehouse центрального сховища даних на видаленому комп'ютері, буде потрібно використовувати приведений нижче код.
Звичайно, інтерфейси є абстракціями і містять тільки перелік методів. Змінні типу interface завжди повинні бути пов'язані з фактичним об'єктом. При виклику видалених об'єктів змінна посилається на об'єкт-заглушку. При цьому клієнтська програма нічого не знає про тип заглушки, а самі заглушки і пов'язані з ними об'єкти створюються автоматично.
При передачі об'єкту іншій програмі (він може бути параметром або значенням видаленого методу, що повертається) потрібен файл класу, відповідний цьому об'єкту. Наприклад, метод, який повертає значення типа Product. При компіляції клієнтської програми повинен бути згенерував файл класу Product.class.
При завантаженні фрагментів коду по мережі завжди виникають сумніви з приводу належного забезпечення безпеки. У зв'язку з цим в додатках з використанням RMI застосовується диспетчер захисту. Він захищає заглушки від проникнення в них вірусів.
32. XML-RPC
XML-RPC (сокр. від англ. Extensible Markup Language Remote Procedure Call - XML-виклик видалених процедур) - стандарт/протокол виклику видалених процедур, заснований на XML, є прародителем SOAP, відрізняється винятковою простотою вживання. XML-RPC, як і будь-який інший інтерфейс RPC, визначає набір стандартних типів даних і команд, які програміст може використовувати для доступу до функціональності іншої програми, що знаходиться на іншому комп'ютері в мережі.
Протокол XML-RPC був спочатку розроблений Дейвом Вінером з компанії «UserLand Software» в співпраці з майкрософтом в 1998 році. Проте корпорація майкрософту незабаром визнала цей протокол дуже спрощеним, і почала розширювати його функціональність. Після декількох циклів по розширенню функціональності, з'явилася система, нині відома як SOAP. Пізніше за майкрософт початку широко рекламувати і упроваджувати SOAP, а початковий XML-RPC був знехтуваний. Але, не дивлячись на відкидання майкрософту, стандарт XML-RPC зачарував багато програмістів своєю надзвичайною простотою і, за рахунок цього, існує до цього дня і навіть поступово набирає популярність.
33. CORBA[1] (сокр. від англ. Common Object Request Broker Architecture загальна архітектура брокера об'єктних запитів) - технологічний стандарт написання розподілених додатків, просувний консорціумом (робочою групою) OMG і відповідна йому інформаційна технологія.
Призначення CORBA
Технологія CORBA створена для підтримки розробки і розгортання складних об'єктно-орієнтованих прикладних систем.
CORBA є механізмом в програмному забезпеченні для здійснення інтеграції ізольованих систем, який дає можливість програмам, написаним на різних мовах програмування, що працюють в різних вузлах мережі, взаємодіяти один з одним так само просто, неначебто вони знаходилися в адресному просторі одного процесу.
Специфікація CORBA наказує об'єднання програмного коду в об'єкт, який повинен містити інформацію про функціональність коду і інтерфейси доступу. Готові об'єкти можуть викликатися з інших програм (або об'єктів специфікації CORBA), розташованих в мережі.
Специфікація CORBA використовує мову опису інтерфейсів (OMG IDL) для визначення інтерфейсів взаємодії об'єктів із зовнішнім світом, вона описує правила відображення з IDL в мову, що використовується розробником CORBA-об'єкту.
Стандартізовани відображення для Ada, З, C++, Lisp, Smalltalk, Java, COBOL, Object Pascal, PL/I і Python. Також існують нестандартні відображення на мови Perl, Visual Basic, Ruby і Tcl, реалізовані засобами ORB, написаними для цих мов.
Об'єкти по значенню
Крім видалених об'єктів в CORBA 3.0 визначено поняття об'єкт по значенню. Код методів таких об'єктів за умовчанням виконується локально. Якщо об'єкт по значенню був одержаний з видаленої сторони, то необхідний код повинен або бути наперед відомий обом сторонам, або бути динамічно завантажений. Щоб це було можливо, запис, що визначає такий об'єкт, містить поле Code Base - список URL, звідки може бути завантажений код.
У об'єкту по значенню можуть також бути і видалені методи, поля, які передаються разом з самим об'єктом. Поля, у свою чергу також можуть бути такими об'єктами, формуючи таким чином списки, дерева або довільні графи. Об'єкти по значенню можуть мати ієрархію класів, включаючи абстрактні і множинне спадкоємство.
Компонентна модель CORBA (CCM)
Компонентна модель CORBA (CCM) - недавнє доповнення до сімейства визначень CORBA. CCM була введена починаючи з CORBA 3.0 і описує стандартний каркас додатку для компонент CORBA. CCM побудовано під сильним впливом Enterprise JavaBeans (EJB) і фактично є його незалежним від мови розширенням. CCM надає абстракцію єств, які можуть надавати і одержувати сервіси через чітко певні іменовані інтерфейси, порти.
Модель CCM надає контейнер компонентів, в якому можуть поставлятися програмні компоненти. Контейнер надає набір служб, які може використовувати компонент. Ці служби включають (але не обмежені) службу повідомлення, авторизації, персистентности і управління транзакціями. Це служби, що часто використовуються розподіленим додатком. Переносячи реалізацію цих сервісів від необхідності реалізації самим додатком у функціональність контейнера додатку, можна значно понизити складність реалізації власне компонентів.