PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 24 ноя 17 8:55

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




Начать новую тему Ответить на тему  [ Сообщений: 50 ]  На страницу 1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: 17 авг 07 12:42 
Не в сети

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Здравствуйте!

Я размышляю над интерфейсом библиотеки для параллельного программирования. Хотелось бы услышать мнение знающих людей по поводу того, что у меня получается. Примерный список вопросов, на которые хотелось бы получить ответы:
- является ли интерфейс "функционально полным"?
- является ли интерфейс удобным для "общих случаев"?
- как его можно улучшить, что-то добавить/убрать/изменить?

Первый интерфейс, это интерфейс "parallel do". Он достаточно схож с "#pragma omp parallel for" из OpenMP. Но опыта работы с OpenMP у меня нет.

Библиотека пишется на С++ и сам интерфейс тоже, соотв. на С++.
Вот сам интерфейс:

Код:
/** Интерфейс pardo алгоритма
 */
class pardo_algo
{
public:
   /**   Выполняется в одном потоке
    *   перед началом параллельной части
    *   @param thread_count общее число потоков,
    *      которые будут выполнять параллельную часть
    */
   void pardo_before(int thread_count) {/*...*/}

   /**   Выполняется в одном потоке
    *   после завершения параллельной части
    *   @param thread_count общее число потоков
    */
   void pardo_after(int thread_count) {/*...*/}

   /**   Параллельная часть
    *   Выполняется одновременно рядом потоков
    *   @param thread_count общее число потоков
    *   @param thread_n номер текущего потока
    */
   void pardo(int thread_count, int thread_n) {/*...*/}
};

Т.е. что бы написать какой-либо pardo алгоритм пользователю надо реализовать класс с таким интерфейсом.
Вот пример реализации алгоритма суммирования массива чисел:

Код:
class my_pardo_algo
{
public:
   my_pardo_algo(std::vector<int>& data)
      : data(data)
   {}

   void pardo_before(int thread_count)
   {
      results.resize(thread_count);
   }

   void pardo(int thread_count, int thread_n)
   {
      int local_result = 0;
      int pos = data.size() * thread_n / thread_count;
      int const end = data.size() * (thread_n + 1) / thread_count;
      for (; pos != end; ++pos)
         local_result += data[pos];
      results[thread_n] = local_result;
   }

   void pardo_after(int thread_count)
   {
      int total_result = 0;
      for (int i = 0; i != thread_count; ++i)
         total_result += results[i];
      // каким-либо образом нотифицируем вызывающего
      // и передаём ему total_result как результат
   }

private:
   std::vector<int>& data;
   std::vector<int>& results;
};

Алгоритм "для каждого элемента массива", я думаю, не сложно представить. Там функции pardo_before() и pardo_after() не будут нужны вообще, только pardo().

Поясню: функции pardo()/pardo_before()/pardo_after() являются функциями обратного вызова. Т.е. пользователю надо реализовать такой класс с алгоритмом, и далее как-то запустить его на выполнение. Далее вызовы pardo()/pardo_before()/pardo_after() будет делать сама библиотека из соотв. потоков на соотв. ядрах процессоров.
Запуск алгоритма на выполнение может выглядеть примерно так:
Код:
std::vector<int> data;
my_pardo_algo algo (data);
start_pardo_algo(algo);



Собственно по поводу этого интерфейса и хотелось услышать мысли сообщества. Заранее спасибо за ответы.

Дмитрий Вьюков.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: fork/join
СообщениеДобавлено: 17 авг 07 12:53 
Не в сети

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Второй интерфейс, который я хочу вынести на обсуждение, если к этому вопросу будет интерес, это интерфейс "fork/join" - параллельная версия алгоритма "divide/conquer".

Дмитрий Вьюков.


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
Я бы порекомендовал сначала изучит аналогичный "велосипед"
от Intel a.k.a Threading Building Blocks http://osstbb.intel.com/


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
Я бы порекомендовал сначала изучит аналогичный "велосипед"
от Intel a.k.a Threading Building Blocks http://osstbb.intel.com/


Да, это я смотрел. Реализация там, кстати, не особо :)
Тут две проблемы.
Во-первых, я не знаю от каких предпосылок они исходили при проектировании и чего хотели добиться.
Во-вторых, хотелось бы услышать первоисточник - т.е. мысли людей из HPC. Благо я пока ничего не скован - никаким интерфейсами и т.д. Есть простор для полёта мысли.

з.ы. к Intel последнее время отношение у меня особо - только пыль в глаза умеют пускать... Ну это так - личное...

Дмитрий Вьюков


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
remark писал(а):
Serge A. Suchkov писал(а):
Я бы порекомендовал сначала изучит аналогичный "велосипед"
от Intel a.k.a Threading Building Blocks http://osstbb.intel.com/


Да, это я смотрел. Реализация там, кстати, не особо :)


В смысле ?


Цитата:
Тут две проблемы.
Во-первых, я не знаю от каких предпосылок они исходили при проектировании и чего хотели добиться.


Ну насколько я понял хотели сделать удобный параллельный фреймворк для C++ на MT модели и насколько я понял у вас задача такая же.

Цитата:
Во-вторых, хотелось бы услышать первоисточник - т.е. мысли людей из HPC. Благо я пока ничего не скован - никаким интерфейсами и т.д. Есть простор для полёта мысли.


Ну если так то в HPC (ImHO) гораздо интереснее посмотреть что будет если такую библиотеку обернуть вокруг той или иной реализации MPI а не вокруг MT.

Цитата:
з.ы. к Intel последнее время отношение у меня особо - только пыль в глаза умеют пускать... Ну это так - личное...


Ну я бы так не сказал (глядя на прогресс их компиляторов к примеру)

PS: Я лет 7 назад пытался реализовать OpenMP API на уровне C++ библиотеки через pthreads. Дальше примера параллельного вычисления числа пи дело не двинулось. Ну и потом с появлением поддержки OpenMP во многих современных компиляторах (Intel C++, MS VS, gcc (gomp), PGI, PathScale, SunStudio) это стало как бы малоактуально. TBB опоздала с выходом лет этак на 10 (ImHO)
Единственно интересная позиция такой библиотеки это нечто более тонкое чем OpenMP и более высокоуровневое чем программирование на уровне pthreads. Но боюсь что такая библиотека в HPC будет маловостребована по ряду причин.


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
Я бы порекомендовал сначала изучит аналогичный "велосипед"
от Intel a.k.a Threading Building Blocks http://osstbb.intel.com/


Да, в этой области безусловно уже есть некоторые библиотеки.
Но хотелось услышать ответы типа "Intel TBB обладает замечательным интерфейсом - можешь срисовывать с неё" или "Intel TBB обладает хорошим интерфейсом, но было бы хорошо добавить то-то и изменить то-то".
Так же были бы интересны комментарии по поводу интерфейса OpenMP. Может стоит срисовывать с него один в один. Хотя скорее всего в библиотеке, являющейся промышленным стандартом (читай - закостенелой), не может быть интерфейса... отражающего современнейшие взгляды...

Дмитрий Вьюков.


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
В смысле ?


В прямом. Представлялось, что в библиотеке, поставляемой такой компанией, должно быть что-то интересное/особенное...


Цитата:
Ну насколько я понял хотели сделать удобный параллельный фреймворк для C++ на MT модели и насколько я понял у вас задача такая же.


Они там вроде в основном концентрируются на примитивах синхронизации и контейнерах. А по поводу HPC не ясно.


Цитата:
Ну если так то в HPC (ImHO) гораздо интереснее посмотреть что будет если такую библиотеку обернуть вокруг той или иной реализации MPI а не вокруг MT.


Это, к сожалению, не обсуждается. Данный интерфейс - есть лишь одна из вершин айсберга.


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

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


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

И кстате TBB уже не коммерческий продукт - выложен недавно под GPLv2.


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
ShapovalovTS писал(а):
remark писал(а):
Я размышляю над интерфейсом библиотеки для параллельного программирования.


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


Цель следующая.
Создаётся некий фреймворк на основе асинхронной передачи сообщений. В основном фреймворк предназначен для написания серверных приложений, но в принципе и любых других.
Поверх этого фреймворка достаточно легко накладывается уровень HPC. По-крайней мере тот, интерфейс, который я привёл в первом посте.
Лично я не имею опыта в HPC. Поэтому обратился сюда.
Точнее даже не именно HPC, а например такая задача - параллельно обработать изображение на 4-ёх ядерной машине.
Почему использование этого интерфейса будет выгодно для пользователя, а не, например, OpenMP. Из-за прозрачной и очень удобной интеграции с остальной частью фреймворка.


Дмитрий Вьюков


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 869
Откуда: НИВЦ МГУ
remark писал(а):
Лично я не имею опыта в HPC. Поэтому обратился сюда.


В таком случае заведомо посоветую не писать свой "параллельный интерфейс", а всерьёз подумать о возможностях существующих библиотек/средств. Они хотя бы отлажены и проверены. Написать интерфейс несложно, сложно потом отлавливать плавающие ошибки.

По поводу ITBB:
remark писал(а):
Представлялось, что в библиотеке, поставляемой такой компанией, должно быть что-то интересное/особенное...

например? Приведённый в начале интерфейс наипростейший. Неужели TBB его не потянет? ;) Эта библиотека хотя бы отлажена неплохо.

Ну, и не TBB единым... Например, parallel arrays должно вполне хватить для решения обозначенной задачи, я полагаю.


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serg_Zhum писал(а):
remark писал(а):
Лично я не имею опыта в HPC. Поэтому обратился сюда.


В таком случае заведомо посоветую не писать свой "параллельный интерфейс", а всерьёз подумать о возможностях существующих библиотек/средств. Они хотя бы отлажены и проверены. Написать интерфейс несложно, сложно потом отлавливать плавающие ошибки.


Я не сказал, что не имею опыта в отлавливании "плавающих" ошибок ;)



Цитата:
По поводу ITBB:
remark писал(а):
Представлялось, что в библиотеке, поставляемой такой компанией, должно быть что-то интересное/особенное...

например?


Интересные алгоритмы структур данных и примитивов синхронизации.
Очень подробно не смотрел, но на вскидку, там алгоритмы не менее 15 летней давности. А развитие не стоит на месте.
Если бы они это 15 лет назад выпустили, тогда другое дело. Правда, тогда бы она точно никому не была нужна :)))


Цитата:
Приведённый в начале интерфейс наипростейший. Неужели TBB его не потянет? ;) Эта библиотека хотя бы отлажена неплохо.

Ну, и не TBB единым... Например, parallel arrays должно вполне хватить для решения обозначенной задачи, я полагаю.


В смысле? parallel arrays должно хватить для решения всех задач HPC? И вообще при чём здесь parallel arrays?


Так что по поводу моего интерфейса? Есть какие-нибудь мысли?


Дмитрий Вьюков


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
remark писал(а):
Хотелось бы услышать мнение знающих людей по поводу того, что у меня получается


Здесь есть люди, которые хоть раз использовали OpenMP?


Дмитрий Вьюков


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
remark писал(а):
Serge A. Suchkov писал(а):
Я бы порекомендовал сначала изучит аналогичный "велосипед"
от Intel a.k.a Threading Building Blocks http://osstbb.intel.com/


Так же были бы интересны комментарии по поводу интерфейса OpenMP. Может стоит срисовывать с него один в один. Хотя скорее всего в библиотеке, являющейся промышленным стандартом (читай - закостенелой), не может быть интерфейса... отражающего современнейшие взгляды...

Дмитрий Вьюков.


Ну я бы особо закостенелым его не назвал. Проблема в другом.
Как _стандарт_ он в распространённости сильно уступает тому же MPI (ImHO).

На мой взгляд OpenMP не хватает гибкости. Его парадигма предполагает некую абстрактную систему с общей памятью (SMP) коих
в современном HPC в чистом виде в общем то уже не то чтобы немного но акценты смещены в сторону систем с неоднородным доступом (NUMA и MPP) опять же Imho. То есть место OpenMP это малопроцессорные/малоядерные системы. И даже на таких системах к OpenMP есть серьёзные вопросы по масштабируемости. И дело тут не в реализации а именно в парадигме.


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
remark писал(а):
remark писал(а):
Хотелось бы услышать мнение знающих людей по поводу того, что у меня получается


Здесь есть люди, которые хоть раз использовали OpenMP?


Дмитрий Вьюков


Есть, и не раз ;)


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
Цитата:
Цитата:
Ну если так то в HPC (ImHO) гораздо интереснее посмотреть что будет если такую библиотеку обернуть вокруг той или иной реализации MPI а не вокруг MT.


Это, к сожалению, не обсуждается. Данный интерфейс - есть лишь одна из вершин айсберга.


Не понял про какой из интерфейсов идёт речь ;)

Действительно Вам нужно определится с местом приложения Ваших усилий.

Скажем, ответьте для себя на вопрос:

"Чем данная C++ библиотека будет лучьше/отличаться от:
1) Реализации OpenMP ?
2) TBB ?
3) С++ биндингов MPI2 (MPI::*) ?"

Чтобы на него ответить нужно попробовать все эти 3 варианта.
Иначе не попробовав Вы вряд ли сможете дать корректный ответ на этот вопрос.

Применительно к C++ в HPC сейчас оптимален вариант N3 (ImHO) ... хотя я всегда предпочитал PVM :(


Последний раз редактировалось Serge A. Suchkov 20 авг 07 15:08, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 50 ]  На страницу 1, 2, 3, 4  След.

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


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

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


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

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