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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Ваше здоровье, Джон Харроп.

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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