Есть ли в Интернете какое-либо сравнение производительности C # / F #, чтобы показать правильное использование нового языка F #?
C # / F # Сравнение производительности
Ответы (3)
Естественный код 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 #, из-за решений по разработке программы, но в конечном итоге эффективность может быть достигнута.
Посмотрите на эти вопросы, которые я недавно задавал:
- Является ли программа 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 # ...
inline
.
- person J D; 21.04.2010