шаблон для параллелизма .NET вне одного компьютера
Я подозреваю, что скоро исчерпаю возможности повышения скорости потоков на нескольких ядрах в одном компьютере.
Что нужно учить программисту .NET для переноса выполнимой параллельной задачи на несколько компьютеров? Я предпочитаю свести к минимуму общее программирование жизненного цикла, поэтому было бы предпочтительным, если бы были минимальные изменения между локальным развертыванием и локальным развертыванием.
Что касается человеко-часов программиста, то это linux, LAMP или какой-то другой стек намного лучше, чем C #. из моих собственных комментариев ниже. Вычислительная часть проблема может быть сделана сколь угодно большой поэтому накладные расходы для распределения / рекомбинации не беспокойтесь, потому что накладные расходы быть лишь небольшой процент времени Вы должны ждать результата. Эта это команда разработчиков одного человека. Просто предложение, и я не знаю, если это хорошо или нет: как насчет WCF и XML как средство для распространения проблемы в полностью локальный Лазурно-невежественный путь и верь, что это будет (когда-нибудь) работать на Azure без изменений и без преимуществ быть лазурью осознанный. Это просто неисследованный идея, и я надеюсь, что у кого-то есть лучше, даже если это не Windows solution.
Another edit: Digipede has an offering for performance improvements and a paper on the distinction between a cluster and a grid.
http://www.digipede.net/downloads/Digipede_CCS_Whitepaper.pdf
Since my problem is more grid-like than cluster and I want to do it cheaply, I'll just try the WCF approach.
4 ответа
Создание механизма вычислительной фермы с использованием WCF будет простым IMO. Поскольку вы уже используете C# на Windows, это естественное развитие, по сравнению со сменой языка или технологического стека.
Ранним шагом в этом процессе было бы создание механизма, с помощью которого рабочие-вычислители могли бы сообщать о своей доступности главной машине. Либо мастер будет иметь apriori знания о рабочих, либо (что лучше) ему потребуется последовательный механизм для "определения местоположения" сервера, например, в хорошо известном домене. Разместив мастер, скажем, на www.all-your-cycles-belong-to-us.org, вы сможете иметь WCF-сервис, обслуживающий входящие предложения вычислительного времени. Если ваш механизм делегирования может настраиваться в зависимости от количества работников, тем лучше.
Определение контрактов на обслуживание, данные и сбои между мастером и рабочими может потребовать некоторых экспериментов для достижения наилучшего баланса между элегантностью программирования, вычислительной производительностью и гибкостью/перспективностью.
По опыту, проблемы этого (и других) подходов следующие:
Рабочий молчит.
Из-за проблем с сетью, длительного периода "занятости" или фактического простоя трудно сказать, пока не будет восстановлена связь с мастером. На моей работе у нас тысячи машин, которые периодически "звонят домой", и целый час без звонка домой считается "простоем". Должны ли вы отправить другого работника выполнять ту же самую работу или подождать произвольное количество времени для завершения первоначальной работы? Только вы знаете свой алгоритм, но смесь обоих подходов может помочь.
Злоупотребление рабочими.
Если ваша вычислительная задача действительно сложна, вы можете запустить процессор на всех рабочих. Будет ли это приемлемо? Если вы арендуете процессорные циклы, то да. Если вы используете свободные циклы на простаивающих машинах (а-ля SETI), то нет.
Результаты приходят не по порядку.
Может ли мастер собрать ваш набор результатов в правильном порядке, если разные рабочие заканчивают работу в разное время?
Версионирование кода.
Если вы исправляете код, как вы можете разослать его всем рабочим, чтобы убедиться, что у них правильная версия? Есть много вариантов решения этой проблемы, но стоит подумать об этом раньше, чем позже.
Разнородные работники.
Наличие высококлассного многопроцессорного рабочего, участвующего в вашей вычислительной ферме наряду с низкопробными машинами с одним ядром и одним процессором, приведет к странному поведению, если вы не будете знать, что рабочие имеют разные спецификации. Адаптация ваших WCF интерфейсов, чтобы позволить рабочему подсказать, сколько нагрузки он может взять на себя, может стоить некоторого внимания.
Я бы рекомендовал почитать о технологиях CCR и DSS от Microsoft. Это действительно хорошая реализация распараллеливания посредством отправки битов работы в "порты". Эти порты считываются рабочими (потоками), что, как дополнительный эффект, позволяет действительно эффективно использовать доступные ядра.
DSS - это дополнительный слой, который позволяет легко использовать одну и ту же концепцию на нескольких машинах.
хорошее введение можно прочитать здесь: concurrent affairs
очень хорошая библиотека сторонних разработчиков xcoappspace доступна как альтернативная реализация межкомпьютерного взаимодействия на основе ccr. Я думаю, что это даже проще, чем dss. Хорошая статья для чтения после того, как вы закончите статью о CCR ;^) xcoappspace
многие из этих концепций были популяризированы языком Erlang.
Честно говоря, разницы между стеками нет. Перед вами стоит задача разделить работу и воссоздать производительность каждой машины. У Microsoft есть проект исследования ВИЧ , который делает именно то, что вы хотите, используя технологию .NET, чтобы «разделять и преодолевать» большую вычислительную проблему.
Главное, на что следует обратить внимание при переходе от многопоточных к распределенным вычислениям, - это увеличение накладных расходов на спулинг заданий на удаленных машинах по сравнению со спулингом другого потока на текущей машине. Гранулярность рабочих элементов должна быть достаточно большой, чтобы оправдать значительно более медленный обмен данными между узлами - обмен сообщениями между потоками на одном компьютере на много порядков быстрее, чем обмен сообщениями между разными компьютерами по сети.
Совместное использование ресурсов на разных машинах сложнее. Совместное использование объектов в памяти просто в нескольких потоках одного процесса, но для достижения подобного на разных машинах требуется определенная инженерия. Замки в принципе не существуют на разных машинах. Посмотрите на использование службы/сервера очередей сообщений для координации работы между несколькими машинами, возврата результатов в агрегатор и т.д.
Вы упомянули "на территории и вне ее". Если вы рассматриваете возможность использования вычислительных ресурсов вне помещений, обязательно поищите поставщиков услуг облачных или эластичных вычислений. Как ни странно, эти понятия не используются в одном дыхании с параллельным программированием так часто, как вы думаете. Облачные вычисления предлагают вам возможность масштабировать параллелизм до сотен или тысяч вычислительных узлов, за которые вы платите только в то время, когда вы их фактически используете. Когда ваши вычисления закончены или живой источник данных для анализа уходит домой в конце рабочего дня, вы можете "выключить" свои облачные узлы и остановить счет до тех пор, пока не запустите их снова.
Amazon, Google и Microsoft - три крупных поставщика облачных услуг (среди прочих), и у каждого из них свои особенности, сильные и слабые стороны. Я работаю над Azure в Microsoft. Встроенные в Azure очереди сообщений довольно удобны для масштабного выполнения рабочих процессов производитель/потребитель.
Используете ли вы в качестве платформы LAMP или .NET - это действительно не столько вопрос производительности, сколько инструментов и навыков, которыми располагает ваша команда разработчиков. Преднамеренный выбор целевой платформы, которая не соответствует набору навыков вашей команды разработчиков, - это отличный способ добавить много времени и затрат на переобучение к графику проекта.
C#/.NET очень хорошо подходит для кодирования параллельных систем по сравнению с C++ или скриптингом в других средах. Учитывайте особенности языка, средства отладки, готовые библиотеки и сервисы, доступные вам при оценке того, какая платформа лучше всего подходит для вашего набора навыков и желаемого дизайна системы.