Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Параллельные вычисления с использованием DLL  (Прочитано 13002 раз)
0 Пользователей и 1 Гость смотрят эту тему.
ezus
Опытный

il
Offline Offline

« : 25-02-2014 11:38 » 

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

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

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

Спасибо.
« Последнее редактирование: 25-02-2014 11:40 от ezus » Записан
darkelf
Молодой специалист

no
Offline Offline

« Ответ #1 : 25-02-2014 12:12 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 25-02-2014 12:45 » 

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

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

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

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

Нередко эти параметры обратно пропорциональны, т.е. попытка улучшить один ведёт к ухудшению другого.
« Последнее редактирование: 25-02-2014 12:49 от Dimka » Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
ezus
Опытный

il
Offline Offline

« Ответ #3 : 25-02-2014 14:33 » 

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

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

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

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

no
Offline Offline

« Ответ #4 : 25-02-2014 14:57 » 

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

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

il
Offline Offline

« Ответ #5 : 25-02-2014 15:19 » 

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

no
Offline Offline

« Ответ #6 : 25-02-2014 15:24 » 

Насколько я помню - потоки разделяют память, так-что 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
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #7 : 25-02-2014 15:25 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #8 : 25-02-2014 15:26 » 

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
ezus
Опытный

il
Offline Offline

« Ответ #9 : 25-02-2014 15:34 » 

ezus, а ты её вообще смог загрузить в x64 процесс?
Цитата: Dimka
И почему не сделать много процессов?


А как?

Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #10 : 25-02-2014 15:49 » 

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
ezus
Опытный

il
Offline Offline

« Ответ #11 : 26-02-2014 06:47 » 

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

ru
Offline Offline
Пол: Мужской

« Ответ #12 : 26-02-2014 11:32 » 

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
ezus
Опытный

il
Offline Offline

« Ответ #13 : 27-02-2014 12:24 » 

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

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines