PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 23 окт 18 14:30

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




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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
Serg_Zhum писал(а):
remark писал(а):
Лично я не имею опыта в HPC. Поэтому обратился сюда.


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


+1


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
remark писал(а):
Интересные алгоритмы структур данных и примитивов синхронизации.
Очень подробно не смотрел, но на вскидку, там алгоритмы не менее 15 летней давности. А развитие не стоит на месте.
Если бы они это 15 лет назад выпустили, тогда другое дело. Правда, тогда бы она точно никому не была нужна :)))


Что например ;) ?
Цитата:

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

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


Мысль такая. Вам видимо надо решить некую прикладную задачу
по обработке изображений (кстати весьма растяжимое понятие)
на многоядерной системе. Для этого вы решили написать собственный
фреймворк на C++. Не имея опыта написания параллельных HPC приложений Вы соответственно обратились сюда за советом "а правильно ли я это делаю". Так ?

Что я могу посоветовать в данном случае:

1) Изучить как _вообще_ решаются задачи в параллельной парадигме. Кроме широко популяризируемых на данном сайте русскоязычных изданий (которые в Вашем случае видимо будут несколько в стороне от интересующей вас темы) я бы посоветовал Вам начать с общих вопросов.
Например начать с книги:

Designing and Building Parallel Programs: Concepts and Tools for Parallel Software Engineering

Ian Foster, Argonne National Laboratory
ISBN: 0-201-57594-9
Publisher: Addison-Wesley
Copyright: 1995
Format: Cloth; 430 pp
Published: 01/31/1995

Несмотря на свой более чем 10 летний возраст книга вполне актуальна в общих вопросах (ImHO)

Возможно коллеги что то добавят от себя

2) Изучить аналогичные программы обработки изображений. Я не вполне представляю что понимается под данным термином. Если это к примеру рейтрейсинг то можно посмотреть как устроена программа PovRay (исходники её доступны), кроме того последняя версия этой программы 3.7 поддерживает многопоточность и есть более ранние варианты на MPI и PVM интерфейсах (MPIPOV и PVMPOV).

3) Изучить существующие интерфейсы для решения параллельных задач. Насколько я понял MPI вам не годится. Видимо остаются OpenMP, TBB.

PS: На самом деле очень важно что понимается под п.2 потому как для решения данной задачи уже могут быть готовые написанные параллельные библиотеки для данной конкретной предметной области.


Собственно вот такие вот мысли.


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

Зарегистрирован: 15 фев 06 17:28
Сообщения: 38
Откуда: GDT Software Group
Цитата:
Так что по поводу моего интерфейса? Есть какие-нибудь мысли?


remark, интерфейс как интерфейс, ничего особенного. их уже и без того много придумано. Как целиком допишете -- показывайте :)

Цитата:
2) Изучить аналогичные программы обработки изображений. Я не вполне представляю что понимается под данным термином.

Serge A. Suchkov, цифровая обработка изображений -- это огромная область, начиная с какой-нибудь медианной фильтрации или гамма-коррекции уровней а-ля фотошоп, заканчивая распознаванием образов во всех возможных аспектах :)

Цитата:
3) Изучить существующие интерфейсы для решения параллельных задач. Насколько я понял MPI вам не годится. Видимо остаются OpenMP, TBB.

remark, я бы тоже порекомендовал поизучать сперва уже имеющиеся интерфейсы. Если много читать не хочется, то вот вам моё краткое ИМХО насчёт что посмотреть обязательно: 1) OpenMP как одна из простейших пардигм для SMP-систем; 2) MPI как весьма развитая парадигма на обменах сообщениями; 3) Т-система как вариант более универсальный и развитый, чем OpenMP; 4) концепцию граф-схемного описания задач с потоковым параллелизмом профессора В.П.Кутепова, ну и его же концепцию функционального программирования... ну это только русскоязычные источники и самые простые для восприятия, чтобы не лезть в дебри. Попытайтесь запрограммировать пару простеньких задач на каждой из схем -- думаю, этого будет достаточно, чтобы прояснились и ваши идеи насчёт вашего собственного интерфейса.

А вообще, задачи распараллеливания тех же алгоритмов обработки изображений успешно решаются, и давно, при этом даже с минимумом средств -- просто примитивы синхронизации, скажем, плюс те же базовые операции над основными структурами данных, как в TBB, или просто с распараллеленными библиотечными модулями -- собственно, нельзя сказать, что этого мало. Да, есть свои проблемы, но всё же -- достаточно. А необходимость придумывать что-то новое ещё надо обосновать, как понимаете, своевременно вспоминая о бритве Оккама :)

_________________
Alexey


Последний раз редактировалось avm 20 авг 07 16:28, всего редактировалось 1 раз.

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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
remark писал(а):
Я не сказал, что не имею опыта в отлавливании "плавающих" ошибок ;)


Ну, тогда вопрос в том, что же Вам нужно - "шашечки или ехать"...

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

например?


Интересные алгоритмы структур данных и примитивов синхронизации.

Так Вам надо "что-то поинтереснее" или "чтоб задачу решить"? Примитивов там весьма немало. Для УНИВЕРСАЛЬНОЙ библиотеки. А для специализированных случаев есть специализированные средства.

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

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


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


Вроде я чётко написал: для решения обозначенной задачи. Выше были отсылки к "некоему фреймворку для серверных приложений". Для большинства серверных приложений (и той же обработки изображения на 4-х процессорах) parallel arrays хватит вполне. Хочется бОльшего? Тогда ставьте задачу более чётко.

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


Интерфейс, описанный в первом посте не тянет ни на универсальное решение, ни на использование "интересных алгоритмов структур данных и примитивов синхронизации". Определитесь с тем ЧТО Вы хотите сделать, для решения каких именно задач и на каких архитектурах - с общей памятью или сетевых...


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
avm писал(а):
Serge A. Suchkov, цифровая обработка изображений -- это огромная область, начиная с какой-нибудь медианной фильтрации или гамма-коррекции уровней а-ля фотошоп, заканчивая распознаванием образов во всех возможных аспектах :)


Это я как раз представляю. Я не представляю что _имел_ввиду_ автор конкретно под данным термином ;)

PS: GDT Software Group, тоже CFD-шник ? :D


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

Зарегистрирован: 15 фев 06 17:28
Сообщения: 38
Откуда: GDT Software Group
Serge A. Suchkov писал(а):
Это я как раз представляю. Я не представляю что _имел_ввиду_ автор конкретно под данным термином ;)

вероятно, что-то самое простое, судя по контексту...

_________________
Alexey


Последний раз редактировалось avm 20 авг 07 18:29, всего редактировалось 1 раз.

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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
remark писал(а):
Serge A. Suchkov писал(а):
На мой взгляд OpenMP не хватает гибкости. Его парадигма предполагает некую абстрактную систему с общей памятью (SMP) коих
в современном HPC в чистом виде в общем то уже не то чтобы немного но акценты смещены в сторону систем с неоднородным доступом (NUMA и MPP) опять же Imho. То есть место OpenMP это малопроцессорные/малоядерные системы. И даже на таких системах к OpenMP есть серьёзные вопросы по масштабируемости. И дело тут не в реализации а именно в парадигме.


Хорошо. Это уже интереснее :)
Я в основном нацеливаю библиотеку как раз на малопроцессорные/малоядерные системы. Сейчас это 4-ёх ядерные. Через год это 8-ми ядерные. А там кто знает. Интел собирается через пять дет выпустить 80-ми ядерный. Там правда не понятно по поводу доступа к памяти. Скорее всего это будет не чисто SMP/UMA система.
Хотя библиотека внутреннее основана на асинхронной передаче сообщений. И я подразумеваю некоторую поддержку для распределенности, пока правда только через TCP, и не в виде кластера, а в виде нескольких приложений, явно соединённых через TCP.
А можно поподробнее по поводу проблем в парадигме OpenMP. Эти проблемы относятся именно к NUMA системам (многопроцессорным), или и к 4-ёх ядерным тоже?

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


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

Зарегистрирован: 18 июн 07 13:13
Сообщения: 47
Откуда: Москва
remark писал(а):
А можно поподробнее по поводу проблем в парадигме OpenMP. Эти проблемы относятся именно к NUMA системам (многопроцессорным), или и к 4-ёх ядерным тоже?


Вобщем к любым - к NUMA в особенности.

В OpenMP например нельзя (нетривиальным образом) породить/завершить поток по событию.

В OpenMP нельзя привязать конкретный поток к конкретному процессору или группе процессоров (средстваими OpenMP) - это важно для NUMA-систем.

Средства управления OpenMP памятью опираются на парадигму что любое изменение общей области памяти становится мгновенно доступно всем потокам исполнения.

1) Это не совсем так (поэтому для доступа к такой области памяти необходимы средства сериализации в явном или неявном виде)
2) Это не всегда удобно (в данном плане MPI к примеру даёт большую гибкость)
3) Локальными областями видимости нельзя _гибко_ управлять (например нетривиально сделать доступными другому потоку кроме как через предварительное объявление переменных shared например) ...

Нельзя задать barrier синхронизацию для группы (не всех) потоков.

Ну и много еще всяких ограничений ...

Тут высказали хорошую мысль запрограммирововать простенькую задачку на OpenMP и Вам станут очевидны если не все то большинство плюсов и минусов данного API


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
Не понял про какой из интерфейсов идёт речь ;)


Про интерфейс класса для описания параллельного алгоритма, который я привёл в первом посте.


Serge A. Suchkov писал(а):
Действительно Вам нужно определится с местом приложения Ваших усилий.

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

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

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

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


Ну что ж, вопрос вполне ризонный.
Во-первых, что отличает от всех. Это гибкая и прозрачная интеграция с остальной частью фреймворка. На практике это имеет определённое значение.
Во-вторых, данный фреймворк на данном этапе задумывается скорее не как средство для HPC, а как средство для утилизации многоядерных процессоров. С появлением 8-ми ядерных процессоров этот вопрос встанет достаточно остро. Поэтому тут я не конкурирую с такими системами как MPI. Тут наверное ближе всего TBB.


1) Реализации OpenMP
Основной функционал, предлагаемый OpenMP я скорее всего буду поддерживать. Но в "С++ виде". Плюс другие типы алгоритмов, например fork/join, насколько я понимаю в OpenMP он не реализуется.

2) TBB
Вообще достаточно схоже. Надо поглядеть на него более подробно. Я там ещё не до конца понял про их task и scheduler. Надо будет разобраться.
Основное отличие - интеграция с остальной частью фреймворка. И в реализации будут серьёзные отличия.

3) С++ биндингов MPI2 (MPI::*)
От этого, наверное, я дальше всего. Хотя основа фреймворка - асинхронные сообщения.
MPI - это всё-таки для больших/распределённых систем. Плюс это низкоуровневое АПИ, как bsd sockets не пригодное для прикладного применения.


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


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serg_Zhum писал(а):
remark писал(а):
Я не сказал, что не имею опыта в отлавливании "плавающих" ошибок ;)


Ну, тогда вопрос в том, что же Вам нужно - "шашечки или ехать"...


Мне нужно то, что я сформулировал в первом посте.
У меня нет опыта в HPC, но есть опыт в создании многопоточных приложений и примитивов синхронизации. Я не вижу здесь никакой несостыковки.



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

например?


Интересные алгоритмы структур данных и примитивов синхронизации.

Так Вам надо "что-то поинтереснее" или "чтоб задачу решить"? Примитивов там весьма немало. Для УНИВЕРСАЛЬНОЙ библиотеки. А для специализированных случаев есть специализированные средства.



Никакой конкретной задачи пока нет, т.ч. наверное первое.
То, что там немало примитивов, ещё не говорит о том, что они там хорошие, либо интересные. Примитивы можно сделать по-разному. Просто факт их наличествования... ни о чём не говорит.



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

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


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


Вроде я чётко написал: для решения обозначенной задачи. Выше были отсылки к "некоему фреймворку для серверных приложений". Для большинства серверных приложений (и той же обработки изображения на 4-х процессорах) parallel arrays хватит вполне. Хочется бОльшего? Тогда ставьте задачу более чётко.



Если под parallel arrays подразумевается это:
http://en.wikipedia.org/wiki/Parallel_array
то я не понимаю, как это может мне помочь...



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


Интерфейс, описанный в первом посте не тянет ни на универсальное решение, ни на использование "интересных алгоритмов структур данных и примитивов синхронизации". Определитесь с тем ЧТО Вы хотите сделать, для решения каких именно задач и на каких архитектурах - с общей памятью или сетевых...



Именно поэтому я сюда и обратился. Что бы умные люди, обитающие в этом форуме, посоветовали как этот интерфейс улучшить. Не надо отталкиваться от него, как от данного и ругать его. Смотрите на него как на исходный набросок.
Интересные алгоритмы структур данных и примитивов синхронизации будут. За это не беспокойтесь :)
Часть этих алгоритмов основывается на самых передовых технологиях (вплоть до 2007 года публикации), часть - уникальные разработки.
Основной вопрос теперь как их применить и для чего.
Теперь по вопросам.
Что я хочу сделать - фреймворк общего назначения для написания серверных и клиентских приложений.
Для решения каких задач - любых. Фреймворк имеет готовые решения для общих задач, но в тоже время не ограничивает пользователя при решении не специфических задач.
На каких архитектурах - с общей памятью.


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


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
remark писал(а):
Интересные алгоритмы структур данных и примитивов синхронизации.
Очень подробно не смотрел, но на вскидку, там алгоритмы не менее 15 летней давности. А развитие не стоит на месте.
Если бы они это 15 лет назад выпустили, тогда другое дело. Правда, тогда бы она точно никому не была нужна :)))


Что например ;) ?


Да, всё вроде.
Если взять контейнеры, то они хорошо распартицированы. Это да. Конкуренция уменьшена. Но чего ж тут нового.


Serge A. Suchkov писал(а):
remark писал(а):
Цитата:

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

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


Мысль такая. Вам видимо надо решить некую прикладную задачу
по обработке изображений (кстати весьма растяжимое понятие)
на многоядерной системе. Для этого вы решили написать собственный
фреймворк на C++. Не имея опыта написания параллельных HPC приложений Вы соответственно обратились сюда за советом "а правильно ли я это делаю". Так ?


Нет. Всё не так :)


Serge A. Suchkov писал(а):
Что я могу посоветовать в данном случае:


Так скажем определённый опыт в создании многопоточных приложений и создании примитивов синхронизации я имею.
Я понимаю, что без собственного опыта наврядли получится сделать хороший интерфейс сразу. Но хочется, так сказать, взять хороший старт.
Вот например, тут... а собственно Вы же :) сказали, что в OpenMP нет возможности делать барьерную синхронизацию для групп потоков. И при этом надо полагать, это требуется в жизни (вопрос, кстати как часто?). Это уже пища для размышления.


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


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

Зарегистрирован: 17 авг 07 1:31
Сообщения: 26
Serge A. Suchkov писал(а):
В OpenMP например нельзя (нетривиальным образом) породить/завершить поток по событию.


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


Serge A. Suchkov писал(а):
В OpenMP нельзя привязать конкретный поток к конкретному процессору или группе процессоров (средстваими OpenMP) - это важно для NUMA-систем.


Если я буду делать поддержку NUMA, то тут предполагается некоторый контроль со стороны пользователя. Правда не прямой, а опосредованный. С помощью некоторых хинтов. Например "эти данные и этот код должны выполняться рядом".


Serge A. Suchkov писал(а):
Средства управления OpenMP памятью опираются на парадигму что любое изменение общей области памяти становится мгновенно доступно всем потокам исполнения.

1) Это не совсем так (поэтому для доступа к такой области памяти необходимы средства сериализации в явном или неявном виде)
2) Это не всегда удобно (в данном плане MPI к примеру даёт большую гибкость)


Фреймворк будет предоставлять "любителям" библиотеку барьеров памяти. Просто потому что она всё равно понадобится мне.
Ну и набор контейнеров данных.


Serge A. Suchkov писал(а):
3) Локальными областями видимости нельзя _гибко_ управлять (например нетривиально сделать доступными другому потоку кроме как через предварительное объявление переменных shared например)


А как бы это можно записываться в коде?
Мой подход подразумевает использование любых средств С++. Т.е. если переменная должна быть доступа нескольким потокам, то её можно определить как член класса алгоритма. Если переменная должна быть private, то её можно просто разместить на стеке функции.

Как Вы себе видите _гибкое_ управление видимость переменных?



Serge A. Suchkov писал(а):
Нельзя задать barrier синхронизацию для группы (не всех) потоков.


Вот это интересно.
А как может происходить разделение на группы?
Например, группа (1, 2), (3, 4), (4, 5) и т.д.?
Или (0 - N/2) и (N/2+1 - N), где N - общее число потоков.
Ведь этот алгоритм придётся запрограммировать в каждом потоке, т.е. каждый поток должен быдет выдать множество потоков, с которыми он хочет провести барьерную синхронизацию. В каком-то смысле алгоритм должен быть статическим, т.е. поток должен выдать некоторое множество, которое должны выдать и все остальные потоки, входящие в это множество. Что-то я сам запутался :)


Serge A. Suchkov писал(а):
Тут высказали хорошую мысль запрограммирововать простенькую задачку на OpenMP и Вам станут очевидны если не все то большинство плюсов и минусов данного API


Тут небольшая проблема. Простейшие алгоритмы типа parallel_foreach или parallel_find_max слишком простые, что бы можно было делать какие-либо выводы. Никакие "засады" на них не проявляются.
А сложные алгоритмы. Во-первых, я не знаю, какие алгоритмы выбрать в качестве "показательных", на которых выявится наибольшее число "засад" и паттернов использования. Во-вторых, я не знаю, как их "хорошо" запрограммировать. Т.е. я могу их криво запрограммировать и начать делать выводы, какие средства нужны, а какие не нужны...

Варианты "показательных" алгоритмов принимаются, просьба высказываться :)


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


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

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


(На правах шутки) Сделайте реализацию задачи "о птичках": http://hp.parallel.ru/parBB/viewtopic.php?t=1187


Последний раз редактировалось ShapovalovTS 21 авг 07 15:37, всего редактировалось 1 раз.

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

Зарегистрирован: 15 фев 06 17:28
Сообщения: 38
Откуда: GDT Software Group
Цитата:
Serge A. Suchkov писал(а):
Тут высказали хорошую мысль запрограммирововать простенькую задачку на OpenMP и Вам станут очевидны если не все то большинство плюсов и минусов данного API


Тут небольшая проблема. Простейшие алгоритмы типа parallel_foreach или parallel_find_max слишком простые, что бы можно было делать какие-либо выводы. Никакие "засады" на них не проявляются.
А сложные алгоритмы. Во-первых, я не знаю, какие алгоритмы выбрать в качестве "показательных", на которых выявится наибольшее число "засад" и паттернов использования. Во-вторых, я не знаю, как их "хорошо" запрограммировать. Т.е. я могу их криво запрограммировать и начать делать выводы, какие средства нужны, а какие не нужны...

Варианты "показательных" алгоритмов принимаются, просьба высказываться :)

А вы в какой прикладной сфере разбираетесь? Вот оттуда и надо алгоритмы брать.

Про наибольшее число "засад" -- а этого никто не знает, если бы всегда заранее было известно, где грабли, как говорится... И вообще, почему обязательно должны быть засады? :)

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

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

_________________
Alexey


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

Зарегистрирован: 11 дек 02 19:37
Сообщения: 872
Откуда: НИВЦ МГУ
remark писал(а):
Мне нужно то, что я сформулировал в первом посте.
У меня нет опыта в HPC, но есть опыт в создании многопоточных приложений и примитивов синхронизации. Я не вижу здесь никакой несостыковки.

Тогда смотрим:
Первый интерфейс, это интерфейс "parallel do". Он достаточно схож с "#pragma omp parallel for" из OpenMP.
...
Второй интерфейс, который я хочу вынести на обсуждение, если к этому вопросу будет интерес, это интерфейс "fork/join" - параллельная версия алгоритма "divide/conquer".


И то и другое довольно несложно реализуется как на OpenMP, так и на MPI и на TBB и на массе всего другого без "интересных алгоритмов синхронизации" и прочих наворотов. Раз предполагается ориентация на SMP/NUMA, то OpenMP представляется лучшим выбором. Хотя, те же TBB должны работать неплохо.
Цитата:
Если под parallel arrays подразумевается это:
http://en.wikipedia.org/wiki/Parallel_array
то я не понимаю, как это может мне помочь...

Сорри, очепятался. Я имел в виду Global Arrays... Для fork/join они врядли эффективны (хотя и годятся в простом виде), а для pardo - вполне.


remark писал(а):
Именно поэтому я сюда и обратился. Что бы умные люди, обитающие в этом форуме, посоветовали как этот интерфейс улучшить. Не надо отталкиваться от него, как от данного и ругать его. Смотрите на него как на исходный набросок.


"- Вы не подскажете, куда мне надо идти?
- Всё зависит от того, куда ты хочешь попасть..."
(С) Льюис Кэррол.

Пока Вы не поймёте ЧТО именно Вам надо, никаких реально полезных советов не получите. Кругозор расширить можно, да. Идей почерпнуть... Но пока будете делать очередной велосипед "чтоб всё распараллелить легко и быстро, да ещё везде работало" - ничего путного не выйдет. Уже сколько умных людей по этим граблям прошлись.
Так что советую не задавать вопросы на тему "чего бы тут ещё этакого навернуть", а трезво продумать зачем и кому будет нужен новый "фреймворк" и составить чёткий список требований. А уж потом продумывать как его реализовать и т.п.

Цитата:
Интересные алгоритмы структур данных и примитивов синхронизации будут. За это не беспокойтесь :)
Часть этих алгоритмов основывается на самых передовых технологиях (вплоть до 2007 года публикации), часть - уникальные разработки.
Основной вопрос теперь как их применить и для чего.

Эх... Вот это и пугает :) Последняя фраза.

Цитата:
Теперь по вопросам.
Что я хочу сделать - фреймворк общего назначения для написания серверных и клиентских приложений.
Для решения каких задач - любых.

"Не советую, молодой человек, не советую. Съедят" (С) А. и Б. Стругацкие "Понедельник начинается в субботу".
Вот те же TBB сделаны как набор примитивов "для всего". Но они хотя бы "вылизаны"... Там нет массы "нужного" для многих приложений и за это их ругают - Вы в первую очередь :) Хотите стать на их место? При этом я не уверен, что получится переплюнуть их по производительности/универсальности.
Что-то экстравагантное сделать - весьма возможно. А вот найти потом тех, кому это нужно - сомневаюсь. Конкретные прикладники с большим скепсисом относятся к таким "панацеям" и не зря...


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

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


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

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


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

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