F # и C # CLR то же самое, почему F # быстрее, чем C # - PullRequest
7 голосов
/ 01 февраля 2011

Я в замешательстве и буду признателен, если вы меня просветите.F # использует тот же CLR, что и C #, и основной код идентичен, тогда как можно предположить, что функция работает быстрее, когда написана на F #, чем C #?Если я использую только неизменяемые переменные в C # и производительность должна быть как можно выше, тогда зачем использовать F #?

Ответы [ 7 ]

14 голосов
/ 01 февраля 2011

базовый код идентичен? Сомнительно. В общем, F # будет быстрее в некоторых вещах и медленнее в других. То же самое относится и к C #. Или даже VB. У каждого языка есть свои плюсы. Если есть общая производительность плюс в большинстве областей, это в компиляторе.

Если я использую только неизменяемые переменные в C # и производительность должна быть как можно выше, тогда зачем использовать F #? Нет смысла переключаться на производительность в одиночку, если на самом деле есть реальная разница, если перф не является вашей проблемой. Что касается необходимости переключения, если вы используете только те функции, которые хороши в C #, я бы сказал «не переключаться».

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

В конечном счете, вам нужно взглянуть на «бизнес-проблему» и определить путь. Вы должны рассмотреть «лучший» язык как часть микса, но вы также должны изучить основную компетенцию и т. Д.

10 голосов
/ 01 февраля 2011

1) Если вы напишите код C # и код F #, который будет скомпилирован для одного и того же IL (промежуточного языка CLR), тогда код будет демонстрировать одинаковые характеристики производительности.Однако реализация одного и того же алгоритма в C # и F # не гарантирует, что будет сгенерирован один и тот же IL, поэтому реальная производительность может отличаться.Я считаю, что на практике иногда код F # будет быстрее, а в других случаях C # будет быстрее.

2) Есть много причин для выбора языка реализации помимо производительности.Например, некоторые люди считают F # более кратким, читаемым и более легким для рассуждений, чем C # для определенных проблемных областей, что было бы одной из причин, по которым он предпочитал бы.Для подавляющего большинства программ разница в производительности на 5 или 10% будет незаметна для пользователей, поэтому, если язык предлагает примерно сопоставимую производительность, но более высокую производительность, то имеет смысл использовать этот язык.

6 голосов
/ 01 февраля 2011

Вас может заинтересовать статья Функции, связанные с производительностью в F # и C # . Что касается «зачем использовать F #», я не могу говорить за вас, но для себя я использую F #, потому что мне это нравится больше.

6 голосов
/ 01 февраля 2011

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

3 голосов
/ 01 февраля 2011

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

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

1 голос
/ 27 октября 2017

Нет причин переключаться, но я предлагаю компоненты, созданные в соответствии с лучшими стандартами.F # применяет множество стандартов, упрощает тестирование в реальном времени во время разработки и устраняет проблемы изменчивости, циклической зависимости, а также большинство проверок типов / нулевых ссылок.C #, с другой стороны, имеет большинство разработчиков и инструментов и может быть разработан с учетом функционального паттерна, но не всегда корректен.Я фанат C # и почти всегда выбираю C #, но я часто вижу, что F # - это то, что мне больше всего нужно для создания более чистого и надежного кода.Думаю, я лично предпочитаю смешивать два языка, когда могу, но, как уже упоминалось, более важно работать с тем, что ваша команда разработчиков также может поддерживать и проверять.Во многих ситуациях команда разработчиков будет против, но в некоторых они будут за это, потому что они также хотят не только сделать кодовую базу максимально возможной, но и изучить новые вещи.Просто не тратьте слишком много времени на выбор правильного языка, если вы уверены, что F # лучше, представьте его и посмотрите, есть ли у вас консенсус для его завершения таким образом.Держите ваш проект отдельно, даже если они в одном решении, и используйте F #, когда он работает лучше всего, и C #, когда он работает лучше всего.Выучить F # не так уж сложно, но для разработчика, который просто необходим, поначалу это может показаться уродливым и запутанным.Просто объясните это немного, и я думаю, что это заставляет мяч двигаться.Временами для рассмотрения F # должны быть алгоритмы, в которых вам требуется не только производительность, но и немедленное тестирование результатов.Это ускоряет время разработки и время выполнения, побеждает, побеждает.Другие могут быть моделями, если модели состоят из множества неизменных значений.F # работает во всех областях, но для меня сторона пользовательского интерфейса проще в C #, а также в таких вещах, как ViewModels, где логика немного отличается, но это мнение.Вы будете удивлены выигрышем, который вы получите от сладкой комбинации двух.Кроме того, функциональное программирование становится проще благодаря linq, lambda и более новому синтаксису C #, где C # в основном выглядит функциональным, поэтому ваш шаг к использованию F # может оказаться не таким сложным, как это было бы много лет назад.но вы поняли ... F # мощный, используйте его, когда он работает лучше всего, и то же самое для C #.Я начал с VB.NET, но больше не рекомендовал бы его просто потому, что его не поддерживает новая технология, такая как .NET Core.Тем не менее, иногда есть преимущество в том, чтобы использовать его ... Хотя это будет гораздо меньше, чем преимущество F #.В связи с этим я просто придерживаюсь двух основных цветов C #, F #.

0 голосов
/ 29 июля 2014

Ответ не в скорости или ресурсах до н.э., они почти одинаковы.Некоторые обсуждаемые улучшения и недостатки ... Причина F # - время разработки и развертывания.F # более упорядочен и готов построить с более безопасным кодом.Меньше подвержены ошибкам и более точны, не беспокоясь о простых вещах, таких как счетчики циклов и проверка типов, перекрестная многопоточность и т. Д. Поэтому писать не только легче и быстрее, но и гораздо меньше ошибок.Вы получаете больше того, что действительно хотели, не беспокоясь о мелочах.Это означает меньше тестирования и больше оперативного развертывания, больше доверенного кода и более точных функций, которые не несут ненужных накладных расходов.Таким образом, результатом является более быстрый написанный код, оптимизированная производительность по своей природе и такое же большое доверие с меньшим количеством ошибок.

...