Возможно ли, что F # будет оптимизирован больше, чем другие языки .Net в будущем?
Из вашего ответа на KennyTM я понимаю, что вы понимаете
python test_raw_input.py > xxx
, и это только второе использование, которое вы не понимаете:
python test_raw_input.py 2> xxx
Я думаю, что вы работаете в поведение, описанное здесь http://mail.python.org/pipermail/python-dev/2008-January/076446.html , что привело к ошибке http: // bugs. python.org/issue1927, в котором есть комментарий о том, что он еще не исправлен в сентябре.
Однако существует обходное решение: из https://groups.google. com / forum /? fromgroups = #! topic / chennaipy / R_VJYNdel-o , если вы
import readline
перед использованием raw_input, поведение будет таким, как вы ожидаете.
7 ответов
Я думаю, что это маловероятно в ближайшем будущем. И если бы это действительно происходит, я думаю, что это было бы более вероятно на уровне IL (перезапись блока), а не уровне языка (например, что-то характерное для F#/compiler). Это - интересный вопрос, и я ожидаю, что некоторые тонкие умы смотрели на это и продолжат смотреть на это некоторое время, но в краткосрочном, я думаю, что фокус будет идти, облегчая для людей предписывать, чтобы поточная обработка/распараллеливание программ, вместо того, чтобы просто иметь все это произошли как будто волшебством.
(Функции языка как асинхронные рабочие процессы F# , и библиотеки как параллельная задаче библиотека и другие , являются хорошими примерами краткосрочного прогресса здесь; они могут сделать большую часть тяжелого подъема для Вас, особенно когда Ваша программа является большим количеством описания, чем императив, но они все еще требуют, чтобы программист подписался, сделал анализ для правильности/содержательности, и вероятно сделал небольшие изменения к структуре кода, чтобы заставить все это работать.)
Так или иначе, это - все предположение; кто может сказать, что принесет будущее? Я надеюсь узнать (и надо надеяться заставить часть из него произойти).:)
Я не полагаю, что возможно автовекторизовать код обычно полезным способом, и фасет функционального программирования F# чрезвычайно не важен в этом контексте.
самая трудная проблема не обнаруживает, когда можно выполнить подвычисления параллельно, она определяет, когда это не ухудшит производительность, т.е. когда подзадачи будут брать достаточно долго для вычисления этого, стоит получить удар производительности параллельной икры.
Мы исследовали это подробно в контексте научных вычислений, и мы приняли гибридный подход в нашем F# для библиотеки Numerics. Наши параллельные алгоритмы, положился на Библиотеку Параллели Задачи Microsoft, потребуйте дополнительного параметра, который является функцией, дающей предполагаемую вычислительную сложность подзадачи. Это позволяет нашей реализации избегать чрезмерного подразделения и гарантировать оптимальную производительность. Кроме того, это решение идеально для языка программирования F#, потому что параметр функции, описывающий сложность, обычно является анонимной первоклассной функцией.
С наилучшими пожеланиями, Jon Harrop.
Существует активное исследование для автораспараллеливания и автоматической векторизации для множества языков. И можно было надеяться (так как я действительно как F#), что они задумают способ определить, если "чистый" побочный эффект, свободное подмножество использовалось и затем параллелизирует это. Также, так как Simon Peyton-Jones, родительский элемент Haskell работает в Microsoft I, нелегко не полагать, что существует некоторое фантастическое прибытие материала.
Microsoft в настоящее время разрабатывает 2 пути для распараллеливания кода: PLINQ (Pararllel Linq, который должен очень функциональным языкам) и Библиотека параллели задачи (TPL), которая была первоначально частью Studio Робототехники. Бета PLINQ доступна здесь .
я поместил бы свои деньги на PLINQ становление нормой для автораспараллеливания кода.NET.
Это возможно, но маловероятно. Microsoft тратит большую часть из, время, поддерживая и реализуя опции, которые требуют их крупнейшие клиенты. Это обычно означает C#, VB.Net и C++ (не обязательно в том порядке). F# не кажется, что это высоко в списке приоритетов.
Быть этим, F# получен на основании компиляторов Ocaml и Ocaml, может оптимизировать Ваши программы намного лучше, чем другие компиляторы, он, вероятно, мог быть сделан.
Я думаю, что вопрос упускает суть архитектуры.NET - F#, C# и VB (и т.д.). все компилируются в IL, который тогда компилируется в машинный код с помощью JIT-компилятора. То, что программа была записана на функциональном языке, не релевантно - если существует оптимизация (как хвостовая рекурсия, и т.д.) доступна JIT-компилятору от IL, компилятор должен использовать в своих интересах его.
Естественно, это не означает, что запись функционального кода не важна - очевидно, существуют способы записать IL, который параллелизирует лучше - но многие из этих методов могли использоваться на любом языке.NET.
Так, нет никакой потребности отметить IL как прибывающий из F# для исследования его на потенциальный параллелизм, и при этом такая вещь не была бы желательна.