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

Question

Возможно ли, что Microsoft сможет создавать программы на F # во время выполнения виртуальной машины или, более вероятно, во время компиляции, обнаруживать, что программа была построена с использованием функционального языка, и автоматически распараллеливать ее?

Сейчас я считаю, что нет таких попыток автоматически выполнить программу, которая была скомпонована как однопоточная, как многопоточная.

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

Будут ли эти оптимизации видны в диспетчере задач в счетчике потоков процессов или это будет более низкий уровень, чем этот?

Answer 1

Я думаю, что это вряд ли в ближайшем будущем. И если это произойдет, я думаю, что это будет более вероятно на уровне IL (перезапись сборки), а не на уровне языка (например, что-то специфическое для F # / compiler). Это интересный вопрос, и я ожидаю, что некоторые хорошие умы смотрели на это и будут продолжать смотреть на это некоторое время, но в ближайшей перспективе, я думаю, основное внимание будет уделяться тому, чтобы людям было легче направлять многопоточность / распараллеливание программ, а не просто все это происходит как по волшебству.

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

Во всяком случае, это все домыслы; Кто может сказать, что принесет будущее? Я с нетерпением жду, чтобы узнать (и, надеюсь, некоторые из них произойдет). :)

Answer 2

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

Answer 3

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

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

Мы подробно исследовали это в контексте научных вычислений, и мы приняли гибридный подход в нашей библиотеке F # for Numerics. Наши параллельные алгоритмы, построенные на базе параллельной библиотеки задач Microsoft, требуют наличия дополнительного параметра, который является функцией, дающей оценку вычислительной сложности подзадачи. Это позволяет нашей реализации избежать чрезмерного разделения и обеспечить оптимальную производительность. Более того, это решение идеально подходит для языка программирования F #, поскольку параметр функции, описывающий сложность, обычно является анонимной функцией первого класса.

Ура, Джон Харроп.

Answer 4

Я думаю, что этот вопрос упускает из виду архитектуру .NET - F #, C # и VB (и т. Д.) Все компилируются в IL, который затем компилируется в машинный код через JIT-компилятор. Тот факт, что программа была написана на функциональном языке, не имеет значения - если есть оптимизации (например, хвостовая рекурсия и т. Д.), Доступные для компилятора JIT из IL, компилятор должен воспользоваться этим.

Естественно, это не означает, что написание функционального кода не имеет значения - очевидно, есть способы написания IL, которые будут лучше распараллеливаться - но многие из этих методов могут использоваться на любом языке .NET.

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

Answer 5

Microsoft в настоящее время разрабатывает 2 способа параллелизации кода: PLINQ (Pararllel Linq, который многим обязан функциональным языкам) и Task Parallel Library (TPL), которая первоначально была частью Robotics Studio. Бета-версия PLINQ доступна здесь .

Я бы положил свои деньги на PLINQ, став нормой для автоматического распараллеливания кода .NET.

Answer 6

Это возможно, но вряд ли. Microsoft тратит большую часть своего времени на поддержку и реализацию функций, запрашиваемых их крупнейшими клиентами. Обычно это означает C #, VB.Net и C ++ (не обязательно в таком порядке). F # не похоже, что он занимает первое место в списке приоритетов.

Answer 7

В настоящее время ведутся активные исследования по автоматическому распараллеливанию и автоматической векторизации для различных языков. И можно надеяться (поскольку мне действительно нравится F #), что они найдут способ определить, использовалось ли «чистое» подмножество без побочных эффектов, и затем распараллелить это. Кроме того, поскольку Саймон Пейтон-Джонс, отец Хаскелла, работает в Microsoft, мне трудно не поверить, что есть фантастические вещи.