Предоставляет ли F # вам автоматический параллелизм?

Question

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

Answer 1

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

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

• http://blogs.msdn.com/dsyme/archive/2007/10/11/introducing-f-asynchronous-workflows.aspx
• http://strangelights.com/blog/archive/2007/09/29/1597.aspx
• http://www.infoq.com/articles/pickering-fsharp-async

Answer 2

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

Answer 3

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

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

Answer 4

Мое понимание состоит в том, что это не будет Parallel Extensions is being modified, чтобы сделать его потребляемым с помощью F #. Который не сделает его автоматически многопоточным, должен сделать его очень простым.

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Еще один шанс для ссылки на Luca's PDC talk. Восемь минут, начиная с 52:20, представляют собой потрясающую демонстрацию рабочих процессов F # async. Это круто!

Answer 8

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

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