There may be several processes allocated to a particular node. Processes can exchange data through streams. A stream represents a queue of messages, managed by the kernel, connecting a source process to a destination process. A process may send and receive messages through streams via an API provided by the kernel. The kernel is responsible for ensuring that messages enqueued into a stream reach the appropriate destination process. Many times, the destination process will reside on a different node than the source process.
Это оно? Т.е., фактически речь о data flow?
По каким словам лучше искать?
Здравствуйте, rising_edge, Вы писали:
_>VHDL — тоже с натяжкой. Это не совсем язык программирования. "Программирование" на VHDL — это тонкая грань между программированием и схемотехникой. На VHDL описываются цифровые схемы, которые потом лягут в железо (FPGA или ASIC).
Спасибо, я в курсе
Незнакомые аббревиатуры и слова стараюсь не употреблять, если же употребляю — всегда явно оговариваю. Имхо, это просто правило хорошего тона.
_> Поэтому надо представлять, во что в железе выльется та или иная констукция языка, насколько она оптимально ляжет в архитектуру, скажем, FPGA. Т. е. надо иметь хотя бы элементарное понятие о цифровых устройствах (логические элементы, шифраторы, триггеры, счетчики и т. п.). Без этого смысла изучения VHDL нет. Если готовятся программисты, то VHDL им не нужен.
Нужен-не нужен... Право слово, какой вы скучный. У нас очень смешная кафедра, они сами не знают, кого готовят Мне было интересно изучать VHDL (схемотехника перед этим, естественно, тоже была, куда же без неё).
_>Это все должен быть отдельный курс, а не часть курса "Параллельное программирование". И не для программистов.
Я просто перечислял подходы, обеспечивающие параллельность. Включать всё это в курс не надо, конечно. Но представление можно дать.
Здравствуйте, SergH, Вы писали:
SH>Это оно? Т.е., фактически речь о data flow?
Как я понял, да. Аппаратная реализация data flow (как противоположность control flow и как часть message-oriented).
Предположение зиждеться во-первых, на статье из wiki (см. также про Cell), во-вторых на Вашей цитате.
Здравствуйте, Gaperton, Вы писали:
G>Пока — предложения:
G>1) Выкинуть Язык Ада к чертям — уже видно, что она совершенно лишняя.
Может быть, может быть. Однако, во-первых, Ada язык параллельного программирования, высокоуровневый язык параллельного программирования, во-вторых в нем взаимодействие процессов(в терминах Ada это задачи) реализовано на базе рандеву, что делает семантику взаимодействий прозрачной и интуитивно понятной. В-третьих есть такая нотация Бара для описания параллельно взаимодействующих процессов при проектировании параллельных программ. Т.е. ada обеспечивает цельную методологию. Думаю, все же это полезный базис для инженера.
Я рассматриваю вопрос о том, применять ли Ada на лабораторных или нет. Но на лекциях про неё обязательно говорить нужно, поскольку методология (а это в Ada скорее интуитивный подход, нежили формализмы) обязательна для инженера. Это конечно не сети Петри и не Параллельные асинхронные блоксхемы.
G>2) Переформулировать пункты, добиться согласованности. Наполнить их, кстати, конкретикой. Те пункты, которые не съезжают на частности, наоборот — настолько общи, что подходят под все, что угодно.
Тут не поспоришь
G>3) Подумать о GPGPU, kernel-stream и потоковых можелях, транзакционной памяти, локфри-структурах.
Пока, что из этого всего реально (с поддержкой в лабораторных) можно в наших условиях давать только локфри-структуры. Для GPGPU нужна минимальная поддержка шейдеров (т.е. хотя бы ps\vs 2.0), может быть она будет, может не будет.
Для транзакицонной памяти и streaming-a нужны эмуляторы, либо моделирование (поскольку Cell'ов нету), а транзакиционная память, как я понимаю, существует на уровне прототипов. Понимаю, что нужно крутиться и искать варианты. Пока что по третьему пункту вижу выход только в моделировании (вот тут-то как раз PtolemyII и пригодиться)\поиске эмуляторов на ПК.
Но покрайней мере, можно давать streaming\GPGPU только в теории, что будет конечно не так полезно.
Здравствуйте, Didro, Вы писали:
D>Спасибо, нет слов D>Буду рефакторить курс. D>С частностями иногда был не согласен, но в целом думаю прочувствовал верно.
Я так понял, вас заинтересовала картинка светлого будущего (я ее набросал по данным исследования рынка High-Performance Computing, которое делал год назад). Так вот, я в ней кое-что пропустил. Попробую более системно изложить.
Раньше параллельные вычисления применялись либо для суперкомпьютерных нужд (научные вычисления, моделирование), либо были всякие другие применения (обработка сигналов, изображений, рендеринг), которые были массовыми и решались аппаратно (ПЛИС, специализированные сигнальные процессоры, графические ускорители, мэйнфреймы) и особо "программиста обыкновенного" не волновали.
Общая список тенденций сейчас такой.
1) "Суперкомпьютерные задачи", под которые собирают специальное железо.
— Дешевые линух-кластеры из гражданских компов объединенные скоростным Ethernet — применяются для научных вычислений, моделирования, и рассчета 3D-графики. Программится это добро традиционно на MPI, практически так же, как взрослые суперкомпьютеры, соединенные вместо Ethernet низколатентными сетями типа Merynet или Infiniband. Это не есть гражданская задача гражданского программера, об этом достаточно "иметь представление". Технология зрелая — мэйнстрим.
— Растущая популярность GRID и технологий peer-to-peer для традиционно суперкомпьютерных задач. Folding@Home, SETI@home. Технология в пред-зрелом состоянии — то есть приложения уже есть, однако их создание не поставлено на поток пока. Тоже не гражданская задача, достаточно нишевая, достаточно "иметь представление".
— Применение разнообразных аппаратных плат-ускорителей, построенных на основе ПЛИС или векторных чипов, таких как CellBE и ClearSpeed. Это — нишевые применения, для всякой биологии. Их достаточно просто упомянуть, даже не иметь представления. Стандарта на эти штуки нет, спрос небольшой, см. "потоковые вычисления" ниже.
2) "Обычные задачи" , с которыми человек столкнется на десктопе.
— Векторные расширения. Раньше было в суперкомпьютерах, теперь давно и везде есть. SSE3 для x86 и AltiVec/VMX для PowerPC. Длина векторов 128 бит, оперирут векторами чисел разных форматов, применяется для ускорения мультимедийной и сигнальной обработки. SSE3 умеет работать и с числами double precision, можно и в научных рассчетах применять. Алгоритмы надо уметь "векторизовывать" — компиляторы это тоже умеют делать, конечно, но плохо. Технология зрелая, мэйнстрим (в 80-е применялось тока для научных суперкомпьютерных рассчетов), вполне можно и "уметь".
— SMP и мультитредные архитектуры. Сейчас — это почти мйнстрим. Аппаратная многопоточность применяется для борбы с латентностью памяти. Надо однозначно уметь и иметь опыт. Здесь ожидается упрощение технологий разаботки за счет применения более высокоуровневых моделей параллелизма.
— Потоковые вычисления. Это то, чего лет 10-15 назад никто не ожидал. Речь идет об ассиметричных архитектурах — GPGPU, и Cell BE. Состояние — предмйнстрим, примеры приложений есть, однако средства разработки пока плохие или отсутствуют, и технологии не устоялись. Более того, в индустрии сейчас нет единства на тему, насколько это приживется для задач общего назначения. Чтобы это прижилось в мэйнстриме, надо иметь простую, понятную и общепринятую модель программирования, которая пока еще не оформилась. Один из рабочих вариантов — kernel-stream. Посему — достаточно "иметь представление", тренингов тут проводить нельзя, черт его знает как повернется. Есть стартап — RapidMind, который утверждает, что их софтина решает эти проблемы — типа, написал один раз, и это компилиться куда угодно, хоть под Cell, хоть под GPU, или просто под SMP. Вот, пока такие тулзы не войдут в обиход, это не станет мэйнстримом. Есть нефиговые предпосылки, что в течении пары лет все устаканится.
3) Серверные приложения.
— Традиционные кластеры. Web-кластеры, кластерные application-сервера (в основном — Java). Надо знать и уметь и иметь представление, тем более, что там будет и многоядерный SMP, и инфраструктура довольно специфическая. Паттерны архитектурные тут есть. Знать надо, ИМХО. Кондовый мйнстрим, на Жабе такие штуки делают на потоке на счет раз-два-три. Жаба вообще неплохо приспособлена к светлому будущему, надо сказать. Начиная с высокоуровневого wait-notify, заканчивая готовыми application-серверами и развитой инфраструктурой для построения серерных решений.
— Веб-сервисы и service-oriented модель, противопоставляемая клиент-серверной модели. Некоторая философия и набор технологий, о которых можно иметь представление.
— Технологии peer-to-peer. Чрезвычайно интересная штука вообще — примеры это не только файл-обменные сети, но и платный сервис XBOX-Live. Надо иметь хорошее представление. Я, кстати, представления не имею — только слышал мнение экспертов, дружно говорят, что появления p2p — это очень неожиданная и значимая штука.
— Распределенка с целью отказоустойчивости. Пересекается с кластерами. Тоже — есть зарактерные приемы и архитектурные паттерны.
Короче говоря, теперь вроде ничего не пропустил. Дополняйте, расшыряйте, режте, выкидывайте. Теперь вам нужно выбрать фокусы для вашего курса. Хорошо дать в начале курса общий обзор в области параллельных вычислений, четко сказать, на чем вы делаете фокус, и на что сознательно забиваете болт.
Здравствуйте, Didro, Вы писали:
D>Здравствуйте, Gaperton, Вы писали:
G>>Пока — предложения:
G>>1) Выкинуть Язык Ада к чертям — уже видно, что она совершенно лишняя. D>Может быть, может быть. Однако, во-первых, Ada язык параллельного программирования, высокоуровневый язык параллельного программирования, во-вторых в нем взаимодействие процессов(в терминах Ada это задачи) реализовано на базе рандеву, что делает семантику взаимодействий прозрачной и интуитивно понятной. В-третьих есть такая нотация Бара для описания параллельно взаимодействующих процессов при проектировании параллельных программ. Т.е. ada обеспечивает цельную методологию. Думаю, все же это полезный базис для инженера. D>Я рассматриваю вопрос о том, применять ли Ada на лабораторных или нет. Но на лекциях про неё обязательно говорить нужно, поскольку методология (а это в Ada скорее интуитивный подход, нежили формализмы) обязательна для инженера. Это конечно не сети Петри и не Параллельные асинхронные блоксхемы.
Да, конечно. Я имел в виду — выкинуть из практического опыта.
G>>3) Подумать о GPGPU, kernel-stream и потоковых можелях, транзакционной памяти, локфри-структурах. D>Пока, что из этого всего реально (с поддержкой в лабораторных) можно в наших условиях давать только локфри-структуры. Для GPGPU нужна минимальная поддержка шейдеров (т.е. хотя бы ps\vs 2.0), может быть она будет, может не будет. D>Для транзакицонной памяти и streaming-a нужны эмуляторы, либо моделирование (поскольку Cell'ов нету), а транзакиционная память, как я понимаю, существует на уровне прототипов. Понимаю, что нужно крутиться и искать варианты. Пока что по третьему пункту вижу выход только в моделировании (вот тут-то как раз PtolemyII и пригодиться)\поиске эмуляторов на ПК. D>Но покрайней мере, можно давать streaming\GPGPU только в теории, что будет конечно не так полезно.
Все эти технологии пока в зачаточном и нестабильном состоянии — нет устоявшейся методологии, принятой индустрией, и нет обкатанных средств раработки. Вряд ли разумно требовать для них "иметь опыт" — лучше ограничиться "иметь представление" или в определенной степени "знать и уметь". Лучше наверно будет нечто среднее — "понимать" .
Здравствуйте, Didro, Вы писали:
D>Спасибо, нет слов D>Буду рефакторить курс. D>С частностями иногда был не согласен, но в целом думаю прочувствовал верно.
А вообще — я хотел на самом деле важность системного подхода показать, а не картины будущего. Хотел проиллюстрировать примером, как достигается "трассировка требований" — чтобы вы сами понимали, что вы курс включаете а что нет, почему и зачем. Картинку будущего лучше будет если вы сами составите. Я ведь ошибиться могу...
Здравствуйте, Didro, Вы писали:
D>Здравствуйте, SergH, Вы писали:
SH>>Это оно? Т.е., фактически речь о data flow? D>Как я понял, да. Аппаратная реализация data flow (как противоположность control flow и как часть message-oriented). D>Предположение зиждеться во-первых, на статье из wiki (см. также про Cell), во-вторых на Вашей цитате.
По-моему, я осторожничаю с оценкой зрелости GPGPU. Еще осенью было ясно, что наш прогноз по GPGPU сбывается вдвое более быстрыми темпами, чем мы ожидали. Вот ссылки:
Общая страница про стим-компьтинг. http://ati.amd.com/technology/streamcomputing/index.html
Бедновато у них с SDK, мне кажется. nVidia, например, уже как пару лет переманила ведущего учоново из Стенфорда, который теперь эту тему у них ведет. Так что все наладится.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Didro, Вы писали:
D>>Здравствуйте, SergH, Вы писали:
SH>>>Это оно? Т.е., фактически речь о data flow? D>>Как я понял, да. Аппаратная реализация data flow (как противоположность control flow и как часть message-oriented). D>>Предположение зиждеться во-первых, на статье из wiki (см. также про Cell), во-вторых на Вашей цитате.
G>По-моему, я осторожничаю с оценкой зрелости GPGPU. Еще осенью было ясно, что наш прогноз по GPGPU сбывается вдвое более быстрыми темпами, чем мы ожидали. Вот ссылки:
Короче, вполне практикум уже можно проводить, если это автор сочтет нужным, конечно.
Здравствуйте, Gaperton, Вы писали:
G>А вообще — я хотел на самом деле важность системного подхода показать, а не картины будущего. Хотел проиллюстрировать примером, как достигается "трассировка требований" — чтобы вы сами понимали, что вы курс включаете а что нет, почему и зачем. Картинку будущего лучше будет если вы сами составите. Я ведь ошибиться могу...
Как бы там оно потом не было, вы мне уже сейчас помогли . Спасибо.
p.s.
Кстати, вот по Cell нашел несколько ссылок (в том числе на учебные курсы) 1, 2. (Эмулятор и материалы курса по Cell в MIT.)
Брать все это добро или не брать — вопрос пока в процессе решения
однако. во-первых, вы не разделяете параллельное и конкурентное программирование. первое — это методики исподльзования мощности многих прцессоров для ускорения решения задач, второе — разюбиение потока выполнения программы на несколько одновнременно выполняющихся ветвей для упрощения самого процесса программирования
второе — ада сейчас реликт, тупиковая ветвь развития. изучать имхо стоит императивную модель (c# или java) и функциональную (erlang/haskell). начинать — с csp, который хорошо ложится на функциональную модель, а затем переходить к c# — т.е. идти от высокоуровневого, теоретического материала к низкоуровневому и более практическому. это всё относится к изучению concurrency, т.е. того, как вообще можно организовать многозадачность и взаимоде1ствие между задачами
имея в своём распоряжении этот инструмент, дальше можно переходить к параллелизму — т.е. преобразованию обычных задач в многопоточные. и тут уже вводить mapreduce, пулы потоков и тому подобные вещи
т.е. результатом курса должна стать способность будущего программиста использовать многпоточность для упрощения реализации программ и увеличения их производительности с использованием современных и перспективных средств программирования, а также наличие теоретической базы для освоения любых подходов, которые появятся в будущем
к этому базовому курсу ещё неплохо добавить другие теретчисекие подходы к распараллеливанию (data flow и т.д.), и STM-память как новую парадигму для приклыдного программиста (в отличие от lock-free структур, использование которых не отличается от обычных)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>однако. во-первых, вы не разделяете параллельное и конкурентное программирование. первое — это методики исподльзования мощности многих прцессоров для ускорения решения задач, второе — разюбиение потока выполнения программы на несколько одновнременно выполняющихся ветвей для упрощения самого процесса программирования
отчего же, напротив как раз этому посвящен первый пост
. Потом, ну это как-то не серъезно — нет такого термина "конкурентное программирование" — это просто, как вы понимаете, калька с английского. С сутью я абсолютно согласен.
BZ>второе — ада сейчас реликт, тупиковая ветвь развития. изучать имхо стоит императивную модель (c# или java) и функциональную (erlang/haskell). начинать — с csp, который хорошо ложится на функциональную модель, а затем переходить к c# — т.е. идти от высокоуровневого, теоретического материала к низкоуровневому и более практическому. это всё относится к изучению concurrency, т.е. того, как вообще можно организовать многозадачность и взаимоде1ствие между задачами
Ада как язык действительно крайне редко используется, но как инструмент реализации параллелизма очень даже неплох:
совмещает модульность и параллелизм (близко к активным объектам)
является отличным примером, почему параллельное программирование должно быть реализовано в языке, а не в библиотеке
так что "Ada's задачи" это одна из удобных концепций параллельного программирования.
BZ>т.е. результатом курса должна стать способность будущего программиста использовать многпоточность для упрощения реализации программ и увеличения их производительности с использованием современных и перспективных средств программирования, а также наличие теоретической базы для освоения любых подходов, которые появятся в будущем
Согласен, вполне себе неплохой результат для курса параллельного программирования. (кстати если Вы загляните в документацию к курсу, в его нынешнем виде
Вот о чем жалею, дак это о том, что не успеваю ввести паралелльное программирование в функциональных языках. В качестве примера для себя нашел MIT-овский курс, но времени видимо не хватит.
