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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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