Будет ли F # работать хорошо при написании математических функций для программы на C #?

Question

Кто-нибудь знает, насколько хорошо F # измеряет производительность по сравнению с C #. У меня есть C # raytracer с большим количеством векторных манипуляций, алгоритмов столкновения лучей и т. Д., И я подумал, что они могут быть легче выражены в F #. Я не спрашиваю, насколько хорошо F # умеет выражать математические задачи, на что уже ответили здесь , а скорее стоит ли ожидать лучшей или худшей производительности? Так как трассировка лучей очень сильно влияет на производительность, даже небольшие случаи низкой производительности могут стать проблемой в неправильных местах.

Edit:

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

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

Во-первых, реализация делегатов на .NET в настоящее время довольно неэффективно и, следовательно, F # использует свой собственный тип FastFunc для первоклассный высокопроизводительный функции.

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

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

И наоборот, компилятор C # лучше при оптимизации циклов с помощью IEnumerables и лучше при оптимизации вычисления над типами значений (например, комплексная арифметика).

Приветствия, Джон Харроп.

Answer 1

Да, F # будет работать лучше.

Вот некоторые результаты производительности для однопоточного алгоритма, реализованного на разных языках (бенчмаркинг функций активации для нейронных сетей):

C #:

10^7 iterations using Sigmoid1() took 3899,1979 ms
10^7 iterations using Sigmoid2() took 411,4441 ms

Чистый C:

10^7 iterations using sigmoid1: 628 ms
10^7 iterations using sigmoid2: 157 ms

F #:

10^7 iterations using sigmoid1: 588.843700 ms
10^7 iterations using sigmoid2: 156.626700 ms

Подробнее

Answer 2

F # будет вести себя так же, как C # для вычислений (поскольку это всего лишь IL). Просто представьте свой вектор как структуру - так как вы будете создавать многие из тех объектов, которые недолговечны.

Единицы измерения не влияют на производительность, фактически во время компиляции информация о единицах измерения полностью удаляется. Таким образом, вы на самом деле не можете сказать, что в вашем коде F # указаны единицы измерения.

Answer 3

Может быть, вы уже знаете, а может и нет.

Гугл по имени "Люк Хобан", он сделал трассировщик лучей с C # 3.0 и теперь работает в команде Microsoft F #.

См. Также: http://blogs.msdn.com/lukeh/ и http://blogs.msdn.com/lukeh/archive/2007/04/03/a-ray-tracer-in-c-3-0.aspx.

Он должен знать.

Answer 4

Производительность F # примерно такая же, как в C #, они оба скомпилированы в IL, что является важным фактором (в отличие от IronPython и IronRuby, которые интерпретируются и, следовательно, намного медленнее). Производительность алгоритма зависит в большей степени от его реализации, чем от выбора F # или C #, поскольку F # поможет реализовать его в несколько строк кода, у вас гораздо больше шансов обнаружить оптимизацию в F #, чем в C #.

Также в этой статье есть аналогичный подход к проблеме перфорации: http://diditwith.net/2008/04/03/ApplesAndOranges.aspx

Answer 5

F # лучше подходит для параллельного программирования. Так что из коробки это может быть быстрее, чем C # (на многоядерных процессорах / процессорах).

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

Answer 6

Моя первоначальная реакция заключается в том, что производительность будет одинаковой из-за того, что C # и F # выводят MSIL. Но структуры, которые вы используете, могут оказаться разными. Тема подробно обсуждалась по ссылкам здесь на SO .

Answer 7

Фактически, теоретически, машина x86 может выполнять только сборку x86, которая имеет императивный характер, поэтому теоретически возможно достичь производительности функционального языка в обязательном порядке. Таким образом, вы можете писать программы на C #, которые равны или лучше, чем их аналоги на F #. Ключевое слово здесь может . Это не значит, что все программы на C # лучше, чем программы на F # или что-то в этом роде. Как правило, производительность F # очень приемлема в большинстве задач. В некоторых случаях производительность F # слишком сильно отстает от C #, но в целом это нормально для большинства приложений. Однако, если вы хотите иметь детальный контроль над тем, что на самом деле делает ваш код, функциональные языки не для вас. У вас больше возможностей для оптимизации в C #, чем в F #. Кстати, под F # я имею в виду не написание императивного кода, а нормальный функциональный подход (если вы хотите писать код с обязательным требованием, я не думаю, что F # имеет смысл).