F # и С# CLR то же самое, то почему F # быстрее, чем С#

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

Был вопрос this в stackoverflow некоторое время назад, это может помочь вам выяснить некоторые причины, по которым F # может быть быстрее. Увеличение производительности в значительной степени зависит от приложения и функций кодирования, которые вы используете.

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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