Распределенный уровень Haskell в 2011 году?

Я прочитал много статей о распределенном Haskell. Проделана большая работа, но, похоже, она находится в области распределения вычислений. Я увидел пакет remote, который, похоже, реализует передачу сообщений в стиле Эрланг, но это 0,1 и ранняя стадия.

Я хотел бы внедрить систему, в которой есть много отдельных процессов, которые предоставляют разные службы и связаны друг с другом несколькими основными процессами. Это кажется естественным для Эрланг, но не для Хаскелла. Но мне нравится безопасность типа Haskell.

Было ли недавнее принятие управления процессами в стиле Эрланг в Haskell?

Ответы

Ответ 1

Если вы хотите узнать больше о пакете remote, aka CloudHaskell, см. статью, а также Джефф Эпштейн thesis. Он нацелен на то, чтобы обеспечить именно абстракцию актера, которую вы хотите, но, как вы говорите, она находится на ранних стадиях. Существует активная дискуссия об улучшениях в списке рассылки parallel-haskell, поэтому, если у вас есть особые потребности, которые remote не предоставляет, мы будем рады вам чтобы вскочить и помочь нам решить его будущие направления.

Более зрелым, но более низким уровнем, чем remote, является haskell-mpi. Если вы придерживаетесь интерфейса Simple, сообщения могут быть отправлены, содержащие произвольные Serialize экземпляры, но абстракция по-прежнему ниже, чем remote.

Существуют некоторые экспериментальные системы, например, описанные в разделе "Внедрение параллельной Haskell с распределенной памятью высокого уровня в Haskell" (Патрик Майер и Фил Триндер, IFL 2011, не могут найти PDF в Интернете). Он сочетает monad-par подход детерминированного потока данных parallelism с ограниченной способностью сделать I-структуры сериализуемыми по сети. Эти виды абстракции обещают сделать распределенные вычисления, но поскольку основное внимание уделяется вычислению чисто функциональных значений, а не обработке процессов в стиле Эрланга, они, вероятно, не будут хорошо подходят для вашего приложения.

Кроме того, для полноты я должен указать страницу вики Haskell в облаке и HPC Haskell, в которой описывается то, что я здесь описываю, а также подраздел распределенный Haskell, который, кажется, нуждается в обновлении.

Ответ 2

Я часто чувствую, что IPC и актеры - это функция перепроданности. Существует множество привлекательных систем обмена сообщениями, которые имеют привязки Haskell, например. MessagePack, 0MQ или Thrift. ИМХО, единственное, что вам нужно добавить, это правильная адресация процессов и определение того, кто/что управляет этой способностью адресации.

Кстати: несколько кодеров принимают, например. 0MQ в их среды Erlang, просто потому, что он предлагает возможность структурировать обмен сообщениями через посредников сообщений, а не полагаться на чистый процесс для обработки сообщений в супермасштабированном масштабе.

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

Вкратце: я бы, вероятно, увидел, может ли MessagePack или 0MQ соответствовать моим потребностям в Haskell и заботиться о остальном в моем коде.