LINUX.ORG.RU

[openmp]помогите составить алгоритм

 


0

1

хочу распараллелить последовательную подпрограмму с помощью openmp. подпрограмма представляет собой обход дефрагментированого разреженного массива F(N1,N2), где N1~500, N2~100000. в служебном массиве V(N1)<N2 хранится значение последнего значимого элемента подмассива F(i,:).

значимые элементы содержат в себе фазовые вектора частиц p=(x,v,i) где x — координата, v — скорость, i — номер узла, причём в F(i,:) хранятся лишь те вектора, чей (x) лежит в заданном интервале (т.е. все вектора локализованы)

в процессе счёта значения x меняются так, что частица может или перескочить в соседний узел или остаться в том же.

сейчас я просто обхожу последовательно все узлы i=0..N1, все вектора j=0..V(i), провожу вычисления, и в случае, если x не соотвествует узлу i, то переношу его значение в соседний узел i2, а на его место записываю нижнее значение из F(i,V(i)) (и делаю V(i)-1, V(i2)+1).

как организовать такой обход массива при параллельном расчёте? пока на ум приходит только завести массив такого же ранга F2, все сложные вычисления проводить параллельно в F, а затем обойти F последовательно, копируя значения в уже в нужные узлы F2, но это явно непотимально. какие есть ещё варианты? с учётом того, что порядок в котором вектора записаны внутри F(i,:) не имеет значения. ссылки на статьи приветствуются.

★★★★★

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

А приходите к нам опять, Вадим расскажет как, он знает;-) Зачем велосипед то изобретать?

AIv ★★★★★
()
Ответ на: комментарий от thunar

Это надо списываться/созваниваться, вопрос сложный. Семестр только начался, расписание пока не устоялось... Контакты наши остались?

AIv ★★★★★
()

Что люди только не выдумывают, чтобы не использовать Erlang...

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

blexey ★★★★★
()
Ответ на: комментарий от blexey

динамический язык для численных расчётов? это форменное издевательство.

qnikst ★★★★★
()

1). можно использовать сишные фортранные либы для разреженных массивов, что сильно увеличит удобство работы, позже могу вспомнить названия и скинуть.

а вобще плохо понял, что тут происходит.. или описано как-то криво, или я дурак.

qnikst ★★★★★
()

Это PIC что ли?Я для этого вместо массивов стал динамические списки делать.

anonymous
()

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

qnikst ★★★★★
()
Ответ на: комментарий от thunar

ваш емэйл и телефон есть.

Ну так стукнитесь, я Вам мыло Вадима дам, с ним и договоритесь. М.б. они по мылу ответить сможет.

AIv ★★★★★
()
Ответ на: комментарий от anonymous

Это PIC что ли?Я для этого вместо массивов стал динамические списки делать.

PIC. Но с т.з. локальности данных - динамические списки это наихудшая идея из всех возможных.

AIv ★★★★★
()
Ответ на: комментарий от AIv

для разряженных массивов существуют вполне адекватные реализации, где данные вполне локальны, ссылки на работы найду, когда знакомый занимавшийся этим online будет..

если я ещё не захелбанен на лоре )

qnikst ★★★★★
()
Ответ на: комментарий от AIv

Сетка какая? У меня на неструктурированной сетке есть массивы из ячеек, граней, узлов (составные типы с кросс-ссылками между собоя для succesive-neighbor searching & ray particle tracing ). Для каждой ячейки есть динамический список частиц. Соответственно при движении частиц я переношу частицы из одной ячейки в другую (точнее вычисляю новые координаты). После окончания движения частицы остаются в старых ячейках, но их координаты соответствуют новым + для каждой частицы я знаю новую ячейку. После этого частицы переносятся в новую ячейку. Что не так в этом подходе?

anonymous
()
Ответ на: комментарий от anonymous

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

AIv ★★★★★
()
Ответ на: комментарий от qnikst

для разряженных массивов существуют вполне адекватные реализации, где данные вполне локальны, ссылки на работы найду, когда знакомый занимавшийся этим online будет..

Давайте, это интересно. Но вообще то тут вариантов не так много, и реализация ручками скорей всего будет оптимальной (если ручки правильные;-))

AIv ★★★★★
()
Ответ на: комментарий от anonymous

Сетка равномерная, но это неважно.

AIv ★★★★★
()
Ответ на: комментарий от AIv

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

Rakot ★★
()

а если организовать цикл по частицам, и для синхронизации доступа к узлам использовать директиву OMP CRITICAL(для Фортрана) ? как я понимаю 1 узел -> N частиц, но 1 частица -> 1 узел ?

marat2345
()
Ответ на: комментарий от AIv

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

blexey ★★★★★
()
Ответ на: комментарий от AIv

а узлу вообще надо знать про частицы ? цикл по частицам: частицы пишут свои данные в характеристики узлов. цикл по узлам. цикл по частицам. вся связь частица-узел храниться на стороне узла. Для задачи ТС выбрал OPENMP тут либо использовать OMP CRITICAL либо эмулировать декомпозицию сетки + синхронизация на общих узлах либо с перехлестом узлов.

marat2345
()
Ответ на: комментарий от Rakot

память высвобождается и выделяется снова

malloc под каждую частицу???

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

Это зависит от железа и размера задачи.

AIv ★★★★★
()
Ответ на: комментарий от blexey

Подождите с распараллеиванием. Если нет никакого распараллеивания (есть один поток), кто быстрее, фортран или эрланг, и во сколько раз?

AIv ★★★★★
()
Ответ на: комментарий от marat2345

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

Хорошая идея. Но работает эффективно, только если все узлы влезают в кэш, да? На Вашем кластере наверняка влезает, а вот у ТС-а...

AIv ★★★★★
()
Ответ на: комментарий от AIv

для того чтобы влезала проводим через N-ое кол-во вычислительных шагов «сортировку по ящикам» частиц и их переупорядочение в памяти. OMP запускаем не по 1 частице а по «ящикам» содержащие частицы. это конечно более слабый алгоритм чем LRnLA но он прост в реализации и для задач ТС вполне пойдет

marat2345
()
Ответ на: комментарий от AIv

успокойся пока с кэшем, вот не первого уровня оптимизация так точно. Сейчас у ТС задача распараллелить, и основная проблема с openmp в том, чтобы данные используемые при пересчётах были не сильно связаны, для этого нужно а). понимать, что используется при пересчете координат, б). что конкретно надо получить, т.к. как я понял сейчас ТС описал задачу включающую особенности текущей реализации, что может привести к заострению внимания на не тех проблемах. Вот будет (или понятно, что будет) omp у ТС распараллеливать задачу на кол-во процессоров, тогда уже можно будет думать о локальности данных и прочих оптимизациях.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

для слабой связаности данных на процессорах надо использовать декомпозицию данных по процессорам (с общими «узлами»/с перехлестом «ячеек»). Это можно сделать в OPENMP так и MPI. по мне так лучше MPI. на многоядерных MPI дает такую же эффективность как OPENMP, но там проблем меньше.

marat2345
()
Ответ на: комментарий от qnikst

а еще лучше к декомпозиции данных по процессорам использовать идеи из LRnLA: переупорядочивание данных для эффективности использования кэша.

marat2345
()
Ответ на: комментарий от marat2345

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

на многоядерных MPI дает такую же эффективность как OPENMP, но там проблем меньше.

если честно, то я удивлён, но заново поднимать MPI и писать интересный и показательный тест у меня нету желания :)

qnikst ★★★★★
()
Ответ на: комментарий от marat2345

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

современные реализации MPI на многоядерных неслабее OPENMP хотите верти хотите нет. OPENMP плох OMP CRITICAL.

marat2345
()
Ответ на: комментарий от qnikst

я думаю идея LRnLA состоит в специальном упорядочение данных которое дает меньший проигрыш по кэшу чем случаный порядок данных. если сетка и числ.схема позволяет прокручивать эти данные несколько шагов по времени то выйгрыш от LRnLA возрастает. даже на 1 шаге по времени будет выйгрыш. вопрос существует алгоритм упорядочения LRnLA для произвольной сетки?

marat2345
()
Ответ на: комментарий от AIv

А в один поток ерланг наскока сольет фортрану?

Трудно сказать, т.к. даже одна последовательность термов BEAM'ом, где это только возможно, пытается выполниться не последовательно.

blexey ★★★★★
()
Ответ на: комментарий от AIv

Если бы Эрланг внезапно оказался строго однопоточным, Фортран наверняка взул бы его в обоих арифметиках. Но тут работают притчи о венике или о мурявьях.

blexey ★★★★★
()
Ответ на: комментарий от blexey

это совсем не та задача, в которой надо использовать эффективный (в противовес ленивому), динамический ФП без мемоизации, который был оптимизирован под конкурентную работу с внешними данными нескольких узлах.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Не спорю. Уверен даже, что в определённых применениях, в плане производительности, последовательный Фотртан разделал бы в пух и прах параллельные ФЯ. Но мне, простачку, почему-то кажется, что если возможно разбить задачу на несколько независимых частей, то их возможно и посчитать параллельно, а значит быстрее. Смотря как сформулировать задачу.

blexey ★★★★★
()
Ответ на: комментарий от blexey

parallelism vs concurrency

ерланг зарулит «классические» скоростные языки на всяких конкурентных задачах, т.к. там из-коробки будет IO-poll основанный на лучшей поддерживаемой данным ядром технологии, будут удобные каналы взаимодействия и искоробочные лёгкие потоки. Естественно во всех классических языках можно сделать тоже самое, но игра не стоит свечь.

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

Скорее всего ФП не скоро приблизятся к уровню классических языков, в приципе у них есть бонусы в параллельном «псевдо-параллельном» вычислении формулы, если у языка есть вывод типов и чистота, то возможно он ещё может упростить граф вычисления (надо будет кстати потестить не получатся ли ошибки округления). Ещё бонусы в использовании древовидных структур и параллельного map-reduce на них, но опять же тут всё пилится, и это совсем не erlang.

qnikst ★★★★★
()
Ответ на: комментарий от marat2345

вопрос существует алгоритм упорядочения LRnLA для произвольной сетки?

Нет. Есть некие наметки для треугольной сетки... и то с фикс. числом соседей. Гипотетически это возможно, но как сделать эффективный код ума не приложу...

AIv ★★★★★
()
Ответ на: комментарий от blexey

Если бы Эрланг внезапно оказался строго однопоточным, Фортран наверняка взул бы его в обоих арифметиках. Но тут работают притчи о венике или о мурявьях.

Тогда ой, если счет не GPU. Скока там ядер, четыре? Что быстрее, эрланг на четрых ядрах или фортран на одном?;-)

AIv ★★★★★
()
Ответ на: комментарий от qnikst

успокойся пока с кэшем, вот не первого уровня оптимизация так точно. Сейчас у ТС задача распараллелить...

Гыыыы.... у Левченко есть подобная задача как любимый пример для студентов с «просто распараллеливанием» - параллелим на 48 ядер и получаем замедление в дцать раз. Так что если в таких задачах с кэшем «ждать», то лучше и не начинать оптимизировать.

AIv ★★★★★
()
Ответ на: комментарий от AIv

сильно зависит от задачи от связности данных и т.д.

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

Согласен. Иногда само распараллеливание большая глупость;-)

AIv ★★★★★
()

если цель именно в "распараллеливании"...

то, IMHO, проще всего сделать как-то так:
for(int ish=0; ish<3; ish++) {
#pragma omp parallel for
for(int i=ish; i<N1; i+=3) {
//содержимое итерации последовательного цикла по ячейкам
}
}

А вообще конечно, главная загадка этого треда --- какой именно задаче нужно 100000 частиц в ячейке, особенно учитывая одномерную постановку.

VLev
()
Ответ на: комментарий от marat2345

вопрос существует алгоритм упорядочения LRnLA для произвольной сетки?

Нет и не будет.
От сетки как минимум требуется структурированность.

VLev
()
Ответ на: комментарий от AIv

Скока там ядер, четыре? Что быстрее, эрланг на четрых ядрах или фортран на одном?;-)

Как числодробилка, да, сам Эрланг сливает даже четырёх. Но совсем сбрасывать его со счетов, имхо, нельзя. Вот здесь http://gpuscience.com/cs/erlang-and-cuda-concurrent-and-fast/, с 22:10 рассказан и показан некоторый прогресс в дружбе CUDA с Эрлангом.

blexey ★★★★★
()
Ответ на: комментарий от anonymous

Что не так в этом подходе?

Может и все так, просто Вы не уточнили как именно реализован «динамический список».
Доступ к памяти на самом деле устроен частично блочным образом.
Потому, если скорость имеет какое-то значение, то и «динамический список» в своей реализации тоже должен состоять из блоков размером не меньше размера страницы виртуальной памяти, т.е. 4K.
На самом деле, всякие malloc и realloc об этом обычно знают AFAIK.

VLev
()
Ответ на: комментарий от blexey

некоторый прогресс в дружбе CUDA с Эрлангом.

Я не верю в чудеса (но это не значит, что их не бывает;-)), универсальные решения всегда проигрывают узкоспециализированным. Да, можно сделать код на языке автоматом параллелящим все что можно на доступном числе ядер, но он ИМНО будет проигрывать аккуратно сделанному коду, в котором параллельность организована с учетом знания специфики задачи.

AIv ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.