.net 4.0 Параллельная библиотека задач против MPI.NET

Заменяет ли параллельная библиотека задач .net 4.0 MPI.NET для высокопроизводительных вычислений?

Здесь можно найти MPI.NET http://www.osl.iu.edu/research/mpi.net/svn/ - это высокопроизводительная и простая в использовании реализация интерфейса передачи сообщений (MPI) для среды Microsoft .NET. MPI является стандартом де-факто для написания параллельных программ, работающих в системе с распределенной памятью, такой как вычислительный кластер.

В .NET 4 TPL говорится: «Библиотека параллельных задач (TPL) - это набор общедоступных типов и API в пространствах имен System.Threading и System.Threading.Tasks в .NET Framework версии 4. Цель TPL - сделать Повышение производительности разработчиков за счет упрощения процесса добавления параллелизма и параллелизма к приложениям. TPL динамически масштабирует степень параллелизма для наиболее эффективного использования всех доступных процессоров. Кроме того, TPL обрабатывает разделение работы и планирование потоков о ThreadPool, поддержке отмены, управлении состоянием и других низкоуровневых деталях. Используя TPL, вы можете максимизировать производительность своего кода, сосредоточившись на работе, для выполнения которой предназначена ваша программа ».

Моя цель - создать приложение, которое может работать в Windows HPC 2008 ... какой путь?


.net parallel-processing mpi hpc
person Jalal El-Shaer    schedule 03.06.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Передача сообщений - это другой способ обратиться к идее параллельного программирования. И Axum, и Erlang используют передачу сообщений. На самом деле они не могут быть сопоставлены напрямую, поскольку оба обращаются к двум конкретным реализациям.

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

TPL, исходя из моего ограниченного понимания, предназначен для того, чтобы построить / заменить / значительно улучшить текущую модель потоковой передачи в .NET, т.е. у вас есть фактические потоки, которые вы контролируете, и вы общаетесь, передавая аргументы или используя общее состояние.

Если это с нуля и дизайн будет разбит на очень маленькие сегменты кода, я бы предложил MPI.NET. Если тип работы требует интенсивного использования ЦП (например, математическая работа), я бы предложил маршрут TPL.

Изменить: давно редактировать, это старый ответ! MPI.NET напрямую подходит для высокопроизводительных вычислений, поскольку он делает границу связи узлов высокопроизводительных вычислений прозрачной и настраиваемой. MPI.NET отправляет сообщения конечным точкам - это точки, определенные как IP-адреса / адреса портов в файлах конфигурации. Код не знает, что конечная точка пересекает границу сети.

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

person Adam Houldsworth    schedule 04.06.2010
comment
Итак, вы предлагаете MPI.NET для приложений HPC? - person Jalal El-Shaer; 12.06.2010
comment
Посмотрите, пожалуйста, resourcekit.windowshpc.net/MORE_INFO/SeqToParallelHPC.html - person Jalal El-Shaer; 12.06.2010
comment
Привет, jalchr, к сожалению, все не так просто. Если вы выполняете тяжелую математическую работу (например, это сильно ограничивает один поток), выбирайте TPL, это хорошая структура для многопоточности в стандартной модели. Единственная полезная область для MPI.NET (ну, для меня Axum) в настоящее время - это сеть, где участники могут прослушивать сетевые порты, не потребляя ресурсов ЦП. MPI.NET не очень подходит. - person Adam Houldsworth; 12.06.2010

arrow_upward
7
arrow_downward

Насколько я понимаю, TPL не поддерживает распределенные вычисления, в то время как MPI.NET поддерживает.

person Peladao    schedule 24.06.2010