Предоставляет ли вам F # автоматический параллелизм? - PullRequest
17 голосов
/ 25 марта 2009

Под этим я имел в виду: когда вы разрабатываете свои побочные эффекты приложения и т. Д., Будет ли код F # автоматически распределяться по всем ядрам?

Ответы [ 8 ]

15 голосов
/ 25 марта 2009

Нет, боюсь, что нет. Учитывая, что F # не является чистым функциональным языком (в самом строгом смысле этого слова), было бы довольно сложно сделать это, я полагаю. Основным способом эффективного использования параллелизма в F # является использование Async Workflows (в основном, через модуль Async, как мне кажется). TPL (Task Parallel Library), который вводится в .NET 4.0, будет выполнять аналогичную роль в F # (хотя, в частности, он может одинаково хорошо использоваться во всех языках .NET), хотя я не могу сказать, что Я точно знаю, как он собирается интегрироваться с существующей асинхронной структурой. Возможно, Microsoft просто посоветует использовать TPL для всего, или, возможно, они оставят оба варианта, и один из них в конечном итоге станет стандартом де-факто ...

В любом случае, вот несколько статей об асинхронном программировании / рабочих процессах в F #, чтобы вы могли начать.

8 голосов
/ 25 марта 2009

F # не делает его автоматическим, он просто делает его легким.

Еще один шанс связаться с Лука на PDC talk . Восемь минут, начинающихся в 52:20 - это потрясающая демонстрация асинхронных рабочих процессов F #. Это качается!

3 голосов
/ 25 марта 2009

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

Конечно, F # может упростить распараллеливание вашего кода, особенно если у вас нет побочных эффектов ... но это другой вопрос.

2 голосов
/ 26 марта 2009

На аннотациях чистоты: Кодовые контракты имеют атрибут Pure. Я помню, что некоторые части BCL уже использовали это. Потенциально, этот атрибут мог бы также использоваться структурами распараллеливания, но я не знаю о такой работе на данный момент. Кроме того, я даже не уверен, насколько хорошо кодовые контакты можно использовать из F #, поэтому здесь много неизвестного.

Тем не менее, будет интересно посмотреть, как все это объединится.

2 голосов
/ 25 марта 2009

Как и другие, упомянутые выше, F # не будет автоматически масштабироваться по ядрам и все равно будет нуждаться в такой среде, как порт ParallelFX, о которой упоминал Джош.

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

1 голос
/ 25 марта 2009

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

Я хотел бы видеть расширение F #, которое объявляет функцию pure . То есть у него нет побочных эффектов, которые не обозначены типом функции. Идея состоит в том, что функция является чистой, только если она ссылается на другие «известные-чистые» функции. Конечно, это было бы полезно, только если бы тогда было возможно требовать, чтобы делегат, переданный в качестве параметра функции, ссылался на чистую функцию.

1 голос
/ 25 марта 2009

Насколько я понимаю, это не так, но Параллельные расширения модифицируются , чтобы сделать их потребляемыми F #. Это не сделает его автоматически многопоточным, это должно сделать его очень легким для достижения.

1 голос
/ 25 марта 2009

нет не будет. Вы все еще должны явно маршалировать вызовы в другие потоки через один из многих механизмов, поддерживаемых F #.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...