Параллельные вычисления с использованием DLL

[ezus]

Привет!
Есть 32-бит DLL С++ , которая получает из C# информацию об изделии и выполняет вычисления для этого изделия.
Вычисления очень емкие как по памяти так и по загрузке процессора.
В C# есть очередь изделий на обработку.
Принято решение организовать параллельное вычисление на отдельных процессорных ядрах.
При этом каждому запуску DLL требуется максимально возможная память.
БУдет бежать на 64-битах.

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

Вопросы: с чего начать? куда сунуться?  что почитать?

Спасибо.

[darkelf]

Назначить программе/потоку выделенные процессоры можно через SetProcessAffinityMask()/SetThreadAffinityMask().

[Dimka]

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

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

Всё это profiler показывает. Надо с ним сидеть, анализировать.

И ещё, в таких делах важно чётко понимать, по какому параметру ищется оптимум:
- минимизировать время решения одной задачи / обработки транзакции;
- максимизировать количество решаемых задач / обрабатываемых транзакций в единицу времени.

Нередко эти параметры обратно пропорциональны, т.е. попытка улучшить один ведёт к ухудшению другого.

[ezus]

Dimka - я так понял, что любые нити, созданные стандартными методами, будут распределяться по разным ядрам автоматически без специальных указаний?

Тип вычислений я отметил - голый расчет с небольшими обращениями к диску в начале и в конце.

Про критерии правильно - у нас минимизация обработки ВСЕЙ очереди.

Особенно волнует память. Все треды бегут в одной памяти или каждый получает свои 2G?
Можно ли выделить больше?

[darkelf]

Dimka - я так понял, что любые нити, созданные стандартными методами, будут распределяться по разным ядрам автоматически без специальных указаний?

По-умолчанию - распределяются по всем.

Особенно волнует память. Все треды бегут в одной памяти или каждый получает свои 2G?
Можно ли выделить больше?

Насколько я помню - потоки разделяют память, так-что 2G на процесс, а вообще - если я правильно понял (http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx), в 64-х битном режиме для x64 прикладной программы должно быть доступно 8T виртуальной памяти.

[ezus]

Насколько я помню - потоки разделяют память, так-что 2G на процесс, а вообще - если я правильно понял (http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx), в 64-х битном режиме для x64 прикладной программы должно быть доступно 8T виртуальной памяти.

Да, но сама DLL 32-битная.
Поэтому и вопрос: можно ли ее как-нибудь увеличить?

[darkelf]

Насколько я помню - потоки разделяют память, так-что 2G на процесс, а вообще - если я правильно понял (http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx), в 64-х битном режиме для x64 прикладной программы должно быть доступно 8T виртуальной памяти.

Да, но сама DLL 32-битная.
Поэтому и вопрос: можно ли ее как-нибудь увеличить?

пишут, что "4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set", больше в 32-х битном приложении физически не получится адресовать.

[Dimka]

ezus, а ты её вообще смог загрузить в x64 процесс?

[Dimka]

И почему не сделать много процессов?

[ezus]

ezus, а ты её вообще смог загрузить в x64 процесс?

И почему не сделать много процессов?

А как?

[Dimka]

ezus, ну вот как её загрузить, я не знаю, потому и спрашиваю: ты уже этот вопрос решил, прежде чем рассуждать о нитях?

Что касается многих процессов: просто - по процессу на задачу или по процессу на ядро. Другое дело, что там за алгоритм диспетчеризации задач, и можно ли всё это разделить между процессами - это как раз вопрос открытый, и вопрос не ко мне.

[ezus]

В любом случае спасибо.
Очевидно, я задал свой вопрос не совсем корректно.
Меня больше интересует где можно почитать о технической стороне этого дела.
А с дизайном все более-менее понятно.

[Dimka]

ezus, для меня этот вопрос непонятный. Потому что если ты выбрал конкретный дизайн, остаётся лишь в MSDN посмотреть нужные функции. Чего там читать? Если же дизайн ещё не определён, то я даже не знаю, кто бы мог написать книжку по решению твоей конкретной проблемы.

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

Вся интрига заключается в том, какие объёмы данных придётся гонять. Если небольшие - смело можно начинать писать. Если большие, WCF может быть полезен лишь для управления, а сами данные придётся как-то передавать/загружать иначе.

[ezus]

Во!!! Спасибо за первое непонятное слово "WCF".
Именно  это мне и надо. Названия инструментов, пакетов, классов,темплейтов и т.п.
MSDN - штука очень хорошая, но надо знать, что искать.