PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 19 авг 19 9:47

Часовой пояс: UTC + 4 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
СообщениеДобавлено: 11 июл 07 19:34 
Не в сети

Зарегистрирован: 11 июл 07 19:24
Сообщения: 7
Откуда: РГАТА (Рыбинск, Ярославская обл)
Herb Sutter начал вести колонку по параллельному программированию в журнале Dr.Dobb's. Закончил перевод его первой обзорной и в тоже время достаточно конкретной статьи - здесь.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 12 июл 07 6:47 
Не в сети

Зарегистрирован: 12 янв 06 11:26
Сообщения: 98
Откуда: Хабаровск, ВЦ ДВО РАН
Начало многообещающее. Ждем продолжений.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 23 июл 07 11:57 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Если вы хотите заблудиться в трех столпах, как в тех соснах, то прочитайте эту статью Саттера :).
Начав достаточно многообещающее, он все закончил, как всегда... Как "столпы параллелизма составляют основу общей модели сегодняшних параллельных вычислений и закладывают основу для её развития"? В лучшем случае "столпы" очерчивают область применения концепции параллелизма. Но эта область известна заранее. Она очевидна - всеобемлюща, как сама жизнь. Но когда у вас есть представление о модели, когда вы оперируете конкретной модель, то содержание "столпов" может быть совершенно другим. Т.е. начинаем заход даже не "от печки", а из-за нее, когда надо бы "от порога":)
В не столь давние времена все же были попытки создания такой модели. Одна даже на слуху у многих - сети Петри. Но где она просматривается в "столпах". Есть менее известная, а потому, может, менее понятная (хотя и проще сетей Петри), - это сеть конечных автоматов. Но как можно догадаться, анализируя "столпы", что есть и такая модель? Ну и т.д. и т.п.
Не знаю, как насчет "многообещаний", но по поводу устранения отмеченных же Саттером неоднозначностей, путаницы и т.п. в параллельном програмировании, для помощи создания обще модели параллельных вычислений и т.д. и т.п. данная статья будет скорее вредна, чем полезна.
Так что если и другие статьи Саттера будут столь же "слоноподобны", то мы скорее всего так и не узнаем от него каким же должен быть "общий язык", чтобы можно было обсуждать проблемы параллелизма. Т.е. по-прежнему останемся и/или будем походить на слепцов из притчи... :(

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 30 июл 07 15:55 
Не в сети

Зарегистрирован: 12 янв 06 11:26
Сообщения: 98
Откуда: Хабаровск, ВЦ ДВО РАН
ВЛ!
Мне не понятны ваши агрессивные нападки на попытку структуризовать методы параллельного программирования. Ни о каких моделях (к вопросу куда отнести КА) тут и речи не идет. Чистой воды практика, разобранная по полочкам.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 июл 07 17:01 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
ShapovalovTS писал(а):
ВЛ!
Мне не понятны ваши агрессивные нападки на попытку структуризовать методы параллельного программирования. Ни о каких моделях (к вопросу куда отнести КА) тут и речи не идет. Чистой воды практика, разобранная по полочкам.

Агрессии нет. А есть мысль - что толку наводить порядок в доме, который давно требует ремонта. Серьезного ремонта. А по большому счету - нужен новый дом :)
На проблемы в существующем "доме" - параллельном программировании вообще и во многоядерных архитектурах в частности сейчас буквально вал статей.
Одни названия чего стоят - "Ядра бьют в холостую" (http://www.rbcdaily.ru/2007/07/27/cnews/284856)
"Продажи многоядерных процессоров могут упасть из-за отсутствия поддержки со стороны программистов" (http://hitech.newsru.com/article/27jul2007/multi_cpu) ну и т.д. и т.п.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 31 июл 07 19:42 
Не в сети

Зарегистрирован: 28 май 05 21:12
Сообщения: 217
Откуда: Москва
ВЛ писал(а):
На проблемы в существующем "доме" - параллельном программировании вообще и во многоядерных архитектурах в частности сейчас буквально вал статей.
Одни названия чего стоят - "Ядра бьют в холостую" (http://www.rbcdaily.ru/2007/07/27/cnews/284856)

В параллельном программировании давно уже обозначены проблемы, но вот никак не могу взять в толк - при чем тут многоядерные процессоры (а приводить ссылки на желтую/заказную прессу гхм. не научно что ль)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 31 июл 07 20:46 
Не в сети

Зарегистрирован: 11 июл 07 19:24
Сообщения: 7
Откуда: РГАТА (Рыбинск, Ярославская обл)
Цитата:
В параллельном программировании давно уже обозначены проблемы, но вот никак не могу взять в толк - при чем тут многоядерные процессоры

Вы так уверено говорите об уже обозначенных проблемах... огласите весь список, пожалуйста :). В этом плане мне нравится известный обзор междисциплинарной группы специалистов из Беркли - The Landscape of Parallel Computing Research: A View From Berkeley (pdf | wiki)

Кстати там также делается акцент на многоядерные процессоры. Они тут притом, что:
а) должны (по идее) явиться катализатором прикладного параллельного программирования
б) являются реализацией параллельной системы (ширпотребной)

Можно посмотреть также на блоги специалистов Intel - возможно станет очевиднее связь между параллельным программированием и многоядерными процессорами. (нпр. 1, 2).

На мой взгляд актуально также такое, впрочем очевидное, разделение области параллельного программирования по полочкам:
    Встроенные системы
    Многоядерные системы
    Распределенные системы
    Гетерогенные системы (GPGPU, как характерный пример)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 1 авг 07 17:30 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Петров Александр писал(а):

...
Кстати там также делается акцент на многоядерные процессоры. Они тут притом, что:
а) должны (по идее) явиться катализатором прикладного параллельного программирования

С этим можно согласится.
Петров Александр писал(а):

б) являются реализацией параллельной системы (ширпотребной)

Если "ширпотреб", как синоним того, чего лучше бы не было, того, с чем бы лучше не иметь дело, то тогда и с этим можно согласится :)

Петров Александр писал(а):

... актуально также такое, впрочем очевидное, разделение области параллельного программирования по полочкам:
    Встроенные системы
    Многоядерные системы
    Распределенные системы
    Гетерогенные системы (GPGPU, как характерный пример)

Такая класасификация имеет к параллельному программированию такое же отношение, как и к последовательному. Или эти "полочки" не будут задействованы пока не появится нормальное параллельное програмирование? Конечно нет. Худо-бедно, но все это решается и на текущем уровне. Но самое главное, что многоядерные системы мало что тут изменят. Ведь программирование по сути остается тем же, что и было.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 1 авг 07 19:22 
Не в сети

Зарегистрирован: 11 июл 07 19:24
Сообщения: 7
Откуда: РГАТА (Рыбинск, Ярославская обл)
Не являясь специалистом не по одной из полочек, попробую с Вами не согласиться. Конкретно вопросы вызывает эта фраза:
Цитата:
Такая классификация имеет к параллельному программированию такое же отношение, как и к последовательному.


И встроенные системы, и многоядерные системы, и распределенные системы и системы этих системы - всё это параллельные системы, поэтому программировать их в последовательном стиле, мягко говоря, не разумно. Точнее говоря, мы, конечно, можем предоставить программисту некоторые инструменты автоматического распараллеливания. Но поскольку все эти системы - параллельные системы, то на определенном уровне мы столкнемся с параллельным их программированием. Разве нет?

Пример -
встроенные системы: ярчайшим примером являются ПЛИС(FPGA) - разработка их спецификаций (в том числе синтезируемых спецификаций, которые используются не для моделирования, а для создания реальной системы) осуществляется на таких языках как VHDL\Verilog - оба языка являются языками параллельного программирования. Вы можете сказать, что ПЛИС - это крайний случай, хорошо, даже если мы возьмем обычный микроконтроллер (нпр AVR), то поскольку микроконтроллер в большинстве случаев взаимодействует с окружающей средой (которая параллельна по сути), например, на основе системы прерываний, то никак не получится программировать его чисто в последовательном стиле.

Вы пишите,
Цитата:
Если "ширпотреб", как синоним того, чего лучше бы не было, того, с чем бы лучше не иметь дело, то тогда и с этим можно согласиться

А чем собственно Вас так не устраивают многоядерные процессоры? Возможно, Вас не устраивает многопоточная "модель" программирования? Если последнее то я с Вами, безусловно, согласен. Но это вовсе не означает, что мы не можем, основываясь на потоках создать детерминированную модель параллельного программирования. Просто нужно рассматривать потоки - как ассемблер - аспект реализации той или иной модели параллельного программирования для данной архитектуры. Точно также в последовательном программировании много моделей, далеких от императивной модели ассемблеров. Так, например, модели программирования с однократным присваиванием или dataflow-переменными далеки от x86-ассемблера, тем не менее, они прекрасно реализуются и работают на данной архитектуре.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 2 авг 07 1:14 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Петров Александр писал(а):
Не являясь специалистом не по одной из полочек, попробую с Вами не согласиться.

Интересный подход. Чем-то сродни - "не читал, но осуждаю". Тем не менее, давайте попробуем... :)
Петров Александр писал(а):
Конкретно вопросы вызывает эта фраза:
Цитата:
Такая классификация имеет к параллельному программированию такое же отношение, как и к последовательному.


И встроенные системы, и многоядерные системы, и распределенные системы и системы этих системы - всё это параллельные системы, поэтому программировать их в последовательном стиле, мягко говоря, не разумно.

А как их сейчас программируют? Отвечаю - последовательно. Не разумно, но ... а что делать, если разумного не предлагают.
Петров Александр писал(а):
Точнее говоря, мы, конечно, можем предоставить программисту некоторые инструменты автоматического распараллеливания.

Думаю, что лучше не надо. Предложенную мной простейшую задачку уже два года здесь пытаются автоматически распараллелить специалисты по автоматическуму распараллеливанию, но ... Поэтому - лучше не надо...
Петров Александр писал(а):
Но поскольку все эти системы - параллельные системы, то на определенном уровне мы столкнемся с параллельным их программированием. Разве нет?

Безусловно. Сталкиваются. Используют MPI, OpenMP, какие-то модели, семафоры и т.д и т.п. Т.е. все, что представлено в "столпах"... Мучений - море...
Петров Александр писал(а):
Пример -
встроенные системы: ярчайшим примером являются ПЛИС(FPGA) - разработка их спецификаций (в том числе синтезируемых спецификаций, которые используются не для моделирования, а для создания реальной системы) осуществляется на таких языках как VHDL\Verilog - оба языка являются языками параллельного программирования.

Я бы с определенной оговоркой считал эти языки параллельными... Но это уже должен быть детальный разговор.
Петров Александр писал(а):
Вы можете сказать, что ПЛИС - это крайний случай,

Нет - не скажу :)
Петров Александр писал(а):
хорошо, даже если мы возьмем обычный микроконтроллер (нпр AVR), то поскольку микроконтроллер в большинстве случаев взаимодействует с окружающей средой (которая параллельна по сути), например, на основе системы прерываний, то никак не получится программировать его чисто в последовательном стиле.

Но ведь программируют! :) И попробуйте их заставить параллельно програмировать!
Петров Александр писал(а):
Вы пишите,
Цитата:
Если "ширпотреб", как синоним того, чего лучше бы не было, того, с чем бы лучше не иметь дело, то тогда и с этим можно согласиться

А чем собственно Вас так не устраивают многоядерные процессоры? Возможно, Вас не устраивает многопоточная "модель" программирования?

В корне. Это не вчерашний - позавчерашний день. А его выдают за что-то выдающееся.
Петров Александр писал(а):
Если последнее то я с Вами, безусловно, согласен.

Ну, вот, хоть один единомышленник есть на этом форуме :)
Петров Александр писал(а):
Но это вовсе не означает, что мы не можем, основываясь на потоках создать детерминированную модель параллельного программирования.

Можем. Но только что из этого получится? Какую модель? Вы знаете ответ на этот вопрос? Может его знает Саттер, Ли и другие?
Петров Александр писал(а):
Просто нужно рассматривать потоки - как ассемблер - аспект реализации той или иной модели параллельного программирования для данной архитектуры. Точно также в последовательном программировании много моделей, далеких от императивной модели ассемблеров. Так, например, модели программирования с однократным присваиванием или dataflow-переменными далеки от x86-ассемблера, тем не менее, они прекрасно реализуются и работают на данной архитектуре.

Все это виртуальные машины. Лучше-хуже, но, видимо, ... хуже, т.к. если бы было "лучше", то мы имели бы реальную такую машину, например, с ... однократным присваиванием и т.п. Но пока имеем то, что имеем, т.е. ... потоки. Они, видимо, хоть их и ругают, лучшее из всего хорошего. Но такое "хорошее" худшее из всего, что можно было бы придумать. Потому от ближайшего будущего ничего хорошего ждать не придется. И это точно. Я об этом и говорил и писал задолго до Саттера и других... Наверное, я из чего исходил? Тем более, что потоки известны были задолго до "эры многоядерности", которую многие ждут как чуда! "Не дождетесь!" Правда, сказано это по другому поводу, но вполне подходит, чтобы охарактеризовать рассматриваемую нами проблему :)
Я говорю резко, но без ... агрессии. Хотя... сказанное может вполне воспринимать и как она. Просто надоело смотреть как народ наступает уже столько лет на одни и те же грабли. Может, "серое вещество" атрофировалось?... Ждем пока нам не подскажут Саттер, Ли?.. И полное впечатление, что именно так...
В России две основные проблемы - "дороги и дураки". Сейчас, смотрю, взялись за дороги. Но начинать надо с дураков, тогда и "дороги" решатся. А так все впустую, поскольку дураки испоганят самые хорошие и надежные дороги. Для этого достаточно одного дурака и ... гусеничный трактор. Но при наличии умных голов этот дурак на своем тракторе будет ездить только там, где ему положено, т.е., если говорить в тему, параллельно основной трассе :)

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 2 авг 07 14:54 
Не в сети

Зарегистрирован: 11 июл 07 19:24
Сообщения: 7
Откуда: РГАТА (Рыбинск, Ярославская обл)
ВЛ писал(а):
Можем. Но только что из этого получится? Какую модель? Вы знаете ответ на этот вопрос? Может его знает Саттер, Ли и другие?

Из этого получится реализация модели параллельного программирования для самой распространенной в мире архитектуры вычислителя. На вопрос какую именно модель ответ ниже.
ВЛ писал(а):
Петров Александр писал(а):
Просто нужно рассматривать потоки - как ассемблер - аспект реализации той или иной модели параллельного программирования для данной архитектуры.

Все это виртуальные машины. Лучше-хуже, но, видимо, ... хуже, т.к. если бы было "лучше", то мы имели бы реальную такую машину, например, с ... однократным присваиванием и т.п. Но пока имеем то, что имеем, т.е. ... потоки. Они, видимо, хоть их и ругают, лучшее из всего хорошего. Но такое "хорошее" худшее из всего, что можно было бы придумать.

Нет, тут не все так просто. Есть Форт-процессоры и Форт-микроконтроллеры (язык Forth), есть LISP-процессоры, просто напросто эти вычислители распространены примерно в такой же пропорции как и языки. Скажем asm\c значительно распространены - большинство МК программируются на них. Я ещё раз говорю, что для решения реальных практических проблем, многоядреность - это большой плюс, только нужно реализовать на потоках детерминированную модель параллельного программирования. Вы спрашиваете какую? На данный момент мой ответ будет таким - модель параллельного программирования формализованную в Join-Calculus (которое можно рассматривать как продолжение идей CCS Милнера). Эта модель реализована в таких языках программирования как JoCalm (на базе OCalm), MC# (на базе C#), в языке Nemerle с помощью макросов, в библиотке MS CCR. Нужно исходить из фактического положения дел. Не нравяться эти модели - критикуйте, но критика должна быть конструктивной и такой аргумент как - я реализовал свою модель на самой распространненой в мире архитектуре и она неплохо работает является плюсом. А заявления - вы работаете не на тех процессорах, потому что на них нельзя полноценно реализовать мою модель - минусом. Разумеется можно попробовать реализовать вашу модель на ПЛИС - вот Вам максимальна гибкая реализация и не на базе виртуальной машины. Только кому она будет нужно на ПЛИС? Это другой вопрос.
ВЛ писал(а):
Потому от ближайшего будущего ничего хорошего ждать не придется.
И это точно.

Ну вот. :)
ВЛ писал(а):
Я об этом и говорил и писал задолго до Саттера и других... Наверное, я из чего исходил? Тем более, что потоки известны были задолго до "эры многоядерности", которую многие ждут как чуда! "Не дождетесь!" Правда, сказано это по другому поводу, но вполне подходит, чтобы охарактеризовать рассматриваемую нами проблему :)
Я говорю резко, но без ... агрессии. Хотя... сказанное может вполне воспринимать и как она. Просто надоело смотреть как народ наступает уже столько лет на одни и те же грабли. Может, "серое вещество" атрофировалось?... Ждем пока нам не подскажут Саттер, Ли?.. И полное впечатление, что именно так...
В России две основные проблемы - "дороги и дураки". Сейчас, смотрю, взялись за дороги. Но начинать надо с дураков, тогда и "дороги" решатся. А так все впустую, поскольку дураки испоганят самые хорошие и надежные дороги. Для этого достаточно одного дурака и ... гусеничный трактор. Но при наличии умных голов этот дурак на своем тракторе будет ездить только там, где ему положено, т.е., если говорить в тему, параллельно основной трассе :)

Ссылка в тему - здесь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 авг 07 0:32 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Петров Александр писал(а):
...Просто нужно рассматривать потоки - как ассемблер - аспект реализации той или иной модели параллельного программирования для данной архитектуры.

Нельзя. Нельзя, чтобы не путать понятия. Ассемблер - это все же язык программирования на базе той или иной модели вычислений. Потоки - нечто на структурном уровне. Ну, как ассемблер - это некое МНОЖЕСТВО команд. Но понятие МНОЖЕСТВО - это еще не понятие модели вычислений.
Петров Александр писал(а):
...Я ещё раз говорю, что для решения реальных практических проблем, многоядреность - это большой плюс, только нужно реализовать на потоках детерминированную модель параллельного программирования. Вы спрашиваете какую?

Да
Петров Александр писал(а):
На данный момент мой ответ будет таким - модель параллельного программирования формализованную в Join-Calculus (которое можно рассматривать как продолжение идей CCS Милнера).

А можно подробнее.
Петров Александр писал(а):
...Ссылка в тему - здесь.

Опять глядим на "них" - нет бы своей "башкой" посоображать :)
Но ... ближе к делу. Создайте RS -триггер на MC#. Это будет досьтойный ответ:)

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 авг 07 5:08 
Не в сети

Зарегистрирован: 12 янв 06 11:26
Сообщения: 98
Откуда: Хабаровск, ВЦ ДВО РАН
ВЛ писал(а):
Потоки - нечто на структурном уровне. Ну, как ассемблер - это некое МНОЖЕСТВО команд. Но понятие МНОЖЕСТВО - это еще не понятие модели вычислений.

Не перевирайте, мысль была о другом. И хотя сравнение с ассемблером не совсем корректно, но сама мысль, что от потоков отказываться ненужно (да и не получиться) верна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 3 авг 07 15:26 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
ShapovalovTS писал(а):
Не перевирайте

Постарайтесь быть вежливым. И сейчас и впредь.
ShapovalovTS писал(а):
, мысль была о другом. И хотя сравнение с ассемблером не совсем корректно

И я об этом и видно, что Вы это поняли. И это хорошо :) "Любое сравнение хромает", так кажется говорят, но пусть хотя бы на одну ногу :)
ShapovalovTS писал(а):
, но сама мысль, что от потоков отказываться ненужно (да и не получиться) верна.

А тут Вы навязываете свои убеждения другим. Но опасность или беда даже не в навязывании, а в том, что делается по типу того, что уж ... "если тебя начали начиловать, то хотя бы расслабся...".
От потоков рано или поздно откажутся. Это точно. Что-то на них построить можно, но не все. Поэтому уж коли они есть, то использовать их будут. Но первая же удачная "внепоточная" архитектура их "помножит на ноль". А это, уж поверьте, случится. Возможно, что не так уж долго и ждать придется. :)
Неэффективность многопоточного программирования становится очевидной все для большего числа специалистов. Дело за малым - когда их число превысит "критическую массу". Но еще не нужно "бить поклоны" потокам, а создавать универсальную модель параллельных вычислений. Правда, может для этого нужен еще один фон Нейман? :)

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 4 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB