Возможно ли, что F# будет оптимизирован больше, чем другие языки.Net в будущем?
Возможно ли, что Microsoft сможет создавать программы на F# во время выполнения виртуальной машины или, более вероятно, во время компиляции, обнаруживать, что программа была построена с использованием функционального языка, и автоматически лучше распараллеливать ее?
Сейчас я считаю, что нет таких попыток автоматически выполнить программу, которая была создана как однопоточная как многопоточная.
То есть, разработчик будет кодировать однопоточную программу. И компилятор выплюнет скомпилированную программу, которая является многопоточной, с мьютексами и синхронизацией, где это необходимо.
Будут ли эти оптимизации видны в диспетчере задач в счетчике потоков процессов или это будет более низкий уровень, чем этот?
7 ответов
Я думаю, что это вряд ли в ближайшем будущем. И если это произойдет, я думаю, что это будет более вероятно на уровне IL (перезапись сборки), а не на уровне языка (например, что-то специфическое для F#/compiler). Это интересный вопрос, и я ожидаю, что некоторые хорошие умы смотрели на это и будут продолжать смотреть на это некоторое время, но в ближайшей перспективе, я думаю, основное внимание будет уделяться тому, чтобы людям было легче направлять многопоточность / распараллеливание программ, а не просто все это происходит, как по волшебству.
(Языковые функции, такие как асинхронные рабочие процессы F#, и библиотеки, такие как библиотека параллельных задач и другие, являются хорошими примерами краткосрочного прогресса; они могут сделать большую часть тяжелой работы для вас, особенно когда ваша программа более декларативна, чем обязательна, но они все еще требуют от программиста выбора, выполнения анализа на предмет корректности / значимости и, возможно, внесения небольших изменений в структуру кода, чтобы все это работало.)
Во всяком случае, это все домыслы; Кто может сказать, что принесет будущее? Я с нетерпением жду, чтобы узнать (и, надеюсь, некоторые из них произойдет).:)
То, что F# является производным от компиляторов Ocaml и Ocaml, может оптимизировать ваши программы намного лучше, чем другие компиляторы, это, вероятно, можно было бы сделать.
Я не верю, что можно автоматически векторизовать код общепринятым способом, и аспект функционального программирования в F# в этом контексте не имеет значения.
Самая сложная проблема состоит не в том, чтобы определить, когда можно выполнять параллельные вычисления, а в том, когда это не приведет к снижению производительности, то есть когда подзадачам потребуется достаточно много времени, чтобы вычислить, стоит ли снижать производительность параллельного вызова.
Мы подробно исследовали это в контексте научных вычислений, и мы приняли гибридный подход в нашей библиотеке F# for Numerics. Наши параллельные алгоритмы, построенные на базе параллельной библиотеки задач Microsoft, требуют наличия дополнительного параметра, который является функцией, дающей оценку вычислительной сложности подзадачи. Это позволяет нашей реализации избежать чрезмерного разделения и обеспечить оптимальную производительность. Более того, это решение идеально подходит для языка программирования F#, поскольку параметр функции, описывающий сложность, обычно является анонимной функцией первого класса.
Приветствия, Джон Харроп.
Я думаю, что этот вопрос упускает из виду архитектуру.NET - F#, C# и VB (и т. Д.) Все компилируются в IL, который затем компилируется в машинный код через JIT-компилятор. Тот факт, что программа была написана на функциональном языке, не имеет значения - если есть оптимизация (например, хвостовая рекурсия и т. Д.), Доступная для JIT-компилятора из IL, компилятор должен воспользоваться этим.
Естественно, это не означает, что написание функционального кода не имеет значения - очевидно, есть способы написания IL, которые будут лучше распараллеливаться - но многие из этих методов могут быть использованы на любом языке.NET.
Таким образом, нет необходимости помечать IL как исходящий от F#, чтобы проверить его на потенциальный параллелизм, и при этом такая вещь не желательна.
Есть активные исследования для автоматического распараллеливания и автоматической векторизации для различных языков. И можно надеяться (поскольку мне действительно нравится F#), что они найдут способ определить, использовалось ли "чистое" подмножество без побочных эффектов, и затем распараллелить это. Кроме того, с тех пор, как Саймон Пейтон-Джонс, отец Хаскелла, работает в Microsoft, мне трудно не поверить, что происходит нечто фантастическое.
В настоящее время Microsoft разрабатывает 2 способа параллелизации кода: PLINQ (Pararllel Linq, который многим обязан функциональным языкам) и Task Parallel Library (TPL), которая изначально была частью Robotics Studio. Бета-версия PLINQ доступна здесь.
Я бы положил свои деньги на PLINQ, став нормой для автоматического распараллеливания кода.NET.
Это возможно, но вряд ли. Microsoft тратит большую часть своего времени на поддержку и реализацию функций, запрашиваемых их крупнейшими клиентами. Обычно это означает C#, VB.Net и C++ (не обязательно в таком порядке). F# не похоже, что он занимает первое место в списке приоритетов.