шаблон для .NET параллелизма за один компьютер

Question

Я подозреваю, что скоро исчерпаю скорость, улучшая возможности потоков на нескольких ядрах в одном компьютере.

Что нужно учить программисту на настольных компьютерах .NET, чтобы перенести выполнимую задачу на несколько компьютеров?Я предпочитаю свести к минимуму общее программирование жизненного цикла, поэтому было бы предпочтительным, если бы были минимальные изменения между локальным развертыванием и локальным развертыванием.

Что касается человеко-часов программиста, это linux, LAMP иликакой-то другой способ работы стека лучше, чем C # .NET в Windows для такого приложения?

Редактировать: Некоторая дополнительная информация из моих собственных комментариев ниже.Интенсивная вычислительная часть проблемы может быть сделана сколь угодно большой, поэтому не стоит беспокоиться о распределении / перекомбинировании накладных расходов, поскольку накладные расходы будут составлять лишь небольшой процент времени, в течение которого вам придется ждать результата.Это команда разработчиков из одного человека.Просто предложение, и я не знаю, хорошо это или нет: как насчет WCF и XML как средства для распространения проблемы полностью локальным невежественным способом Azure и верят, что (когда-нибудь) это будет работать на Azure безизменения и без преимуществ осведомленности Azure.Это просто неисследованная идея, и я надеюсь, что у кого-то есть идея получше, даже если это не решение для Windows.

Другое редактирование: У Digipede есть предложение для повышения производительностии документ о различии между кластером и сеткой.

http://www.digipede.net/downloads/Digipede_CCS_Whitepaper.pdf

Поскольку моя проблема больше похожа на сетку, чем на кластер, и я хочу сделать это дешево, я просто попробую подход WCF.

Answer 1

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

Совместное использование ресурсов сложнее на разных машинах. Совместное использование объектов в памяти является простым в нескольких потоках в одном и том же процессе, но требует некоторой разработки для достижения аналогичных результатов на разных машинах. Замки в основном не существуют на машинах. Обратите внимание на использование службы / сервера очереди сообщений для координации работы между несколькими компьютерами, возврата результатов в агрегатор и т. Д.

Вы упоминаете "в помещениях против помещений". Если вы рассматриваете ресурсы для локальных вычислений, обязательно поищите поставщиков услуг облачных вычислений или эластичных вычислений. Как ни странно, они не используются на одном дыхании с параллельным программированием так часто, как вы думаете. Облачные вычисления предлагают вам возможность увеличить параллелизм до сотен или тысяч вычислительных узлов, за которые вы платите только во время их использования. Когда ваши вычисления завершены или источник данных для анализа отправляется домой в конце дня, вы можете «отключить» свои облачные узлы и остановить часы выставления счетов, пока не запустите их снова.

Amazon, Google и Microsoft являются тремя крупными поставщиками облачных услуг (среди прочих), и каждый из них имеет свои особенности, сильные и слабые стороны. Я работаю над материалом Azure в Microsoft. Встроенные очереди сообщений Azure довольно удобны для запуска рабочих процессов производителя / потребителя в масштабе.

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

C # / .NET очень хорошо работает для кодирования параллельных систем по сравнению с C ++ или сценариями в других средах. Учитывайте языковые возможности, средства отладки и готовые библиотеки и службы, доступные вам, при оценке того, какая платформа лучше всего подходит для вашего набора навыков и желаемого дизайна системы.

Answer 2

Создание механизма вычислительной фермы с использованием WCF было бы простым IMO.Поскольку вы уже используете C # в Windows, это естественный прогресс по сравнению с переключением языка или технологического стека.

Первым шагом в этом процессе будет разработка механизма, с помощью которого вычислительные работники могли бы сообщать о своей доступности.на мастер машину.Либо мастер будет иметь априорные знания о работниках, либо (что лучше) им нужен согласованный механизм для «обнаружения» сервера, например, в хорошо известной области.Если вы скажете мастеру, скажем, www.all-your-cycles-belong-to-us.org, у вас будет служба WCF, обслуживающая входящие предложения о времени вычислений.Если ваш механизм делегирования может настраиваться в соответствии с количеством работников, тем лучше.

Определение ваших контрактов на обслуживание, данные и ошибки между мастером и работниками может потребовать некоторых экспериментов для достижения наилучшего баланса элегантности программирования, вычислительная пропускная способность и гибкость / перспективность.

Опыт показывает, что проблемы этого (и других) подходов:

1. Работник умолкает.

   Трудно сказать, из-за проблем с сетью, «занятости» в течение длительных периодов или фактического простоя, пока связь с мастером не будет восстановлена.В моей повседневной работе у нас есть тысячи машин, которые периодически «звонят домой», а полный час без звонка домой считается «отключенным».Должны ли вы заставить другого работника выполнять ту же работу или подождать произвольное количество времени для завершения оригинала?Только вы знаете свой алгоритм, но сочетание обоих подходов может помочь.

2. Злоупотребление рабочими.

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

3. Результаты поступают не по порядку.

   Можно ли повторно установить набор результатов?собран в правильном порядке мастером, если разные рабочие заканчивают в разное время?

4. Управление версиями кода.

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

5. Разные работники.

   Наличие первоклассного мульти- Сотрудник ЦПУ, участвующий в вашей вычислительной ферме вместе с компьютерами с низким уровнем соло-ядро-соло-процессор, может привести к странному поведению, если вы не будете знать, что у рабочих разные спецификации.Адаптация интерфейсов WCF, позволяющая работнику подсказать, какую нагрузку он может взять, может стоить некоторого внимания.

Answer 3

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

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

Хорошее введение можно прочитать здесь: Параллельные дела

очень хорошая сторонняя библиотека xcoappspace доступна в качестве альтернативной реализации кросс-компьютерного взаимодействия на основе ccr. Я думаю, что это даже проще, чем DSS. Хорошая статья для чтения после того, как вы закончите статью CCR; ^) xcoappspace

Многие из этих концепций были популяризированы языком Erlang.

Answer 4

Честно говоря, я бы сказал, что между стеками нет никакой разницы. Задача, с которой вы столкнетесь, состоит в том, чтобы разбить работу и воссоздать производительность каждой машины. У Microsoft есть исследовательский проект по ВИЧ , который делает именно то, что вы хотите, используя технологию .NET, чтобы «разделить и победить» большую вычислительную проблему.