C# / F# Сравнение производительности

Посмотрите на эти вопросы, которые я недавно задавал:

• Является ли программа на F# более эффективной (с точки зрения выполнения), чем C#?
• Как я могу использовать функциональное программирование в реальном мире?
• Возможно ли, что в будущем F# будет оптимизирован больше, чем другие языки .Net?

Вот несколько ссылок по этой теме (или связанных с ней):

• http://cs.hubfs.net/forums/thread/3207.aspx
• http://strangelights.com/blog/archive/2007/06/17/1588.aspx
• http://khigia.wordpress.com/2008/03/30/ocaml-vs-f-for-big-integer-surprising-performance-test/
• http://cs.hubfs.net/blogs/f_team/archive/2006/08/15/506.aspx
• http://blogs.msdn.com/jomo_fisher/

Что я, кажется, помню из другого поста в блоге Роберта Пикеринга (или это был Скотт Хансельман?), Что, в конце концов, поскольку оба находятся на одной и той же платформе, вы может получаете одинаковую производительность от обоих, но вам иногда приходится `` крутить '' 'естественное выражение языка для этого. В примере, который я помню, ему пришлось крутить F#, чтобы получить сопоставимую производительность с C# ...

Естественный код F# (например, функциональный / неизменяемый) работает медленнее, чем естественный (императивный / изменяемый объектно-ориентированный) код C#. Однако этот вид F# намного короче обычного кода C#. Очевидно, здесь есть компромисс.

С другой стороны, в большинстве случаев можно добиться производительности кода F#, равной производительности кода C#. Обычно это требует кодирования в императивном или изменяемом объектно-ориентированном стиле, профилирования и устранения узких мест. Вы используете те же инструменты, что и в C#: например, .Net отражатель и профайлер.

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

• ссылки (по сравнению с переменными экземпляра класса), только в коде, выполняемом миллиарды раз

• Сравнение F# (<=) с System.Collections.Generic.Comparer, например, в двоичном поиске или сортировке

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

• Последовательности F# в два раза медленнее, чем LINQ. Это связано со ссылками и использованием функций в библиотеке F# для реализации перевода seq <_>. Это легко исправить, поскольку вы можете заменить модуль Seq на модуль с такими же сигнатурами, который использует Linq, PLinq или DryadLinq.

• Кортежи, кортеж F# - это класс, отсортированный в куче. В некоторых случаях, например, кортеж int * int, который может быть платным за использование структуры.

• Распределения, стоит помнить, что замыкание - это класс, созданный с помощью оператора new, который запоминает доступные переменные. Возможно, стоит «снять» замыкание или заменить его функцией, которая явно принимает переменные, к которым осуществляется доступ, в качестве аргументов.

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

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

Суть в том, что ваш код на F# может работать медленнее, чем на C#, из-за решений по разработке программы, но в конечном итоге эффективность может быть достигнута.