Re[11]: ФП и многоядерная архитектура
От: remark Россия http://www.1024cores.net/
Дата: 27.11.08 07:23
Оценка:
Здравствуйте, thesz, Вы писали:

T>>>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.


R>>Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему.


T>Причём здесь "на слабо"?


T>Вот тебе интересна какая-то тема. Её надо обязательно изучить. Любое теоретическое изучение будет неполным, поэтому надо изучить практически.


T>Значит, надо сделать систему.


Ну почему же сразу обязательно. Во-первых, я интересуюсь таким кол-вом вещей, что на всё делать по полномасштабной системе — это мне надо будет по 48 часов свободного времени в сутки. Приходится искать какие-то разумные компромиссы, что-то я пробую практически, что-то — нет. Во-вторых, с опытом и знаниями приходит т.н. "техническая интуиция", это когда даже не пробуя технологию практически можешь предвидеть, где у неё будут сильные стороны, где слабые, откуда ждать подвохов и т.д.
Симуляцию на агентном подходе я не пробовал, но 2 самых критичных места я подозреваю — я их указывал. И я не говорил, что сделанная с наскоку симуляция на агентном подходе будет прекрасно масштабироваться, я как раз уверен в обратном — поэтому писать целиковую систему, что бы увидеть, что она действительно не будет масштабироваться мне мало смысла...



T>Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.


А можешь дать какие-то ссылки на "dynamic dataflow".
Исходя из того, что я нашёл (хотя я не уверен, что нашёл именно то, что ты имеешь в виду), это фактически тот же агентный подход — имеем фифо-очереди, имеем агентов. Как я понял отличие в том, что агенты — примитивные, т.е. выполняют очень простые операции (хотя это и не было там явно указано).
Если это так, то сильно напоминает COSA:
http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
Правда COSA — синхронная и детерминированная, а из-за этих свойств там достаточно сложно добиться эффективной реализации — автор как-то очень уклончиво говорит о реализации...



R>>Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.


T>Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.


Что ты имеешь в виду под преобразованиями? Для OpenMP в общем случае не нужны никакие преобразования (хотя анализ нужен). Для агентного — это зависит. Если гранулярность обработчиков сообщений достаточна, то особо ничего делать и не надо; если недостаточна, то один вариант — действительно делать какие-то преобразования программы (возможно — тривиальные, возможно — нет), второй вариант — всё же попытаться наделить ран-тайм достаточным интеллектом.



R>>По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.


T>А если она не решается? Ась?


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


Или ты имеешь в виду, что теоретический максимум это и есть те самые 20% и наша задача как выжать их? Ну тогда тут надо заниматься такими вещами как ограничивать кол-во рабочих потоков числом 2, иначе мы в лучшем случае будем тратить процессорное время впустую, а в худшем производительность будет деградировать. Далее детектировать топологию системы и привязать эти два потока к ближайшим ядрам желательно разделяющим кэш (но ни в коем случае ни к двум аппаратным потокам внутри одного ядра, и ни в коем случае не к двум процессорам, находящимся на разных NUMA узлах).
Кстати, хороший вопрос — какие из упоминавшихся систем (Haskell, Erlang) это могут?


T>(вообще-то решается, конечно, но отнюдь не простым вставлением par и pseq. Преобразования будут потяжелее. И для разных типов систем — синхронные, асинхронные — разными, с разным результатом.)


T>>>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки.

R>>Так проблема была в низкой гранулярности?

T>Не "была", а "будет".


T>Это я рассуждал о будущей системе, которую я сейчас прикидываю.


Ты это хочешь перекладывать на конечного программиста? Или этот анализ будет делать ран-тайм?


R>>По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.


T>Её, как и всё остальное, надо проверять.


T>Бремя доказательства лежит на высказавшем.


Её надо не только проверять, для начала надо придумать алгоритм, как это можно делать...


R>>>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.


T>>>Э-эх.


R>>Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.


T>Я про другое.


T>Ты сперва добейся независимой работы этой сотни агентов.


T>А то ты о самом сложном говоришь, как о решённой задаче.


Не понял. Работа разных агентов по определению независима. Что ты имеешь в виду?



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.