Насколько C++ быстрее, чем C#?

https://stackoverflow.com/questions/138361

02-07-2019
|

Вопрос

Или сейчас все наоборот?

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

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

Решение

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

Таким образом, C++ во многих случаях быстрее.Но это только часть ответа.Случаи, когда C++ на самом деле быстрее, — это высокооптимизированные программы, где опытные программисты тщательно оптимизировали код.Это не только отнимает много времени (и, следовательно, дорого), но также часто приводит к ошибкам из-за чрезмерной оптимизации.

С другой стороны, код на интерпретируемых языках становится быстрее в более поздних версиях среды выполнения (.NET CLR или Java VM) без каких-либо дополнительных действий.И есть много полезных оптимизаций, которые могут сделать JIT-компиляторы, которые просто невозможны в языках с указателями.Кроме того, некоторые утверждают, что сбор мусора обычно должен быть таким же быстрым или даже более быстрым, чем ручное управление памятью, и во многих случаях это так и есть.Обычно все это можно реализовать и на C++ или C, но это будет намного сложнее и подвержено ошибкам.

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

Имейте в виду, что оптимизировать правильную программу относительно легко, но исправить оптимизированную программу гораздо труднее.

Дать реальный процент преимущества в скорости невозможно, это во многом зависит от вашего кода.Во многих случаях реализация языка программирования даже не является узким местом.Возьмите ориентиры на http://benchmarksgame.alioth.debian.org/ с большой долей скептицизма, так как они в основном тестируют арифметический код, который, скорее всего, вообще не похож на ваш код.

Другие советы

Возможно, C# не быстрее, но он делает ВАС/МЕНЯ быстрее.Это самая важная мера того, что я делаю.:)

Это на пять апельсинов быстрее.Или скорее:не может быть (правильного) общего ответа.C++ — это статически компилируемый язык (но есть и оптимизация на основе профилей), C# запускается с помощью JIT-компилятора.Различий так много, что на такие вопросы, как «насколько быстрее», невозможно ответить, даже указав порядки величин.

Я собираюсь начать с несогласия с частью принятого (и получившего широкое одобрение) ответа на этот вопрос, заявив:

На самом деле есть множество причин, по которым Jated Code будет работать медленнее, чем правильно оптимизированная программа C ++ (или другого языка без превышения выполнения) включая:

вычислительные циклы, затраченные на JIT-код во время выполнения, по определению недоступны для использования при выполнении программы.
любые горячие пути в JITter будут конкурировать с вашим кодом за кеш инструкций и данных в ЦП.Мы знаем, что кэш доминирует, когда дело доходит до производительности, и в родных языках, таких как C++, такого типа конкуренции нет по определению.
Бюджет времени оптимизатора времени выполнения обязательно много более ограничен, чем у оптимизатора времени компиляции (как отметил другой комментатор)

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

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

Это очень длинная и сложная тема, но я считаю, что для полноты стоит упомянуть, что оптимизатор времени выполнения C# превосходен и способен выполнять определенные динамические оптимизации во время выполнения, которые просто недоступны для C++ во время компиляции ( статический) оптимизатор.Даже несмотря на это, преимущество, как правило, по-прежнему остается за собственным приложением, но динамический оптимизатор является причиной "почти определенно», указанный выше.

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

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

Вместо этого я написал немного более идиоматический код C++ и сравнил его с кодом C#, предоставленным @Wiory.Два основных изменения, которые я внес в код C++, заключались в следующем:

1) использовал вектор::резерв()

2) сгладил массив 2d до 1d, чтобы добиться лучшей локальности кэша (смежный блок)

С# (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

Время выполнения (выпуск):В этом:124 мс, Заполнение:165 мс

С++14 (Клан v3.8/C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

Время выполнения (выпуск):В этом:398 мкс (да, это микросекунды), Заполнение:152 мс

Общее время работы:С#:289 мс, C++ 152 мс (примерно на 90 % быстрее)

Наблюдения

Изменение реализации C# на ту же реализацию 1D массива выступила в начале:40 мс, Заполнение:171 мс, Всего:211 мс (C ++ все еще был почти на 40% быстрее).
Гораздо сложнее спроектировать и написать «быстрый» код на C++, чем написать «обычный» код на любом из этих языков.
(Возможно) удивительно легко добиться низкой производительности в C++;мы видели это на примере производительности незарезервированных векторов.И таких подводных камней очень много.
Производительность C# просто поразительна, если учесть все, что происходит во время выполнения.И эта производительность сравнительно проста в доступе.
Еще больше анекдотических данных, сравнивающих производительность C++ и C#: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

Суть в том, что C++ дает вам гораздо больше контроля над производительностью.Хотите использовать указатель?Ссылка?Стек памяти?Куча?Динамический полиморфизм или устранение накладных расходов во время выполнения виртуальной таблицы с помощью статического полиморфизма (через шаблоны/CRTP)?В C++ вам придется...э-э, добраться до делайте все эти выборы (и даже больше) самостоятельно, в идеале, чтобы ваше решение наилучшим образом соответствовало проблеме, которую вы решаете.

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

По моему опыту (а я много работал с обоими языками), основная проблема C# по сравнению с C++ — это высокое потребление памяти, и я не нашел хорошего способа контролировать это.Именно потребление памяти в конечном итоге замедлило работу программного обеспечения .NET.

Другим фактором является то, что JIT-компилятор не может уделять слишком много времени расширенной оптимизации, поскольку он выполняется во время выполнения, и конечный пользователь заметит это, если это займет слишком много времени.С другой стороны, у компилятора C++ есть все необходимое время для оптимизации во время компиляции.Этот фактор гораздо менее значим, чем потребление памяти, ИМХО.

Один конкретный сценарий, в котором C++ все еще имеет преимущество (и будет в ближайшие годы), возникает, когда полиморфные решения могут быть предопределены во время компиляции.

В целом инкапсуляция и отложенное принятие решений — это хорошо, поскольку они делают код более динамичным, его легче адаптировать к меняющимся требованиям и проще использовать в качестве основы.Вот почему объектно-ориентированное программирование на C# очень продуктивно и его можно обобщить термином «обобщение».К сожалению, этот конкретный вид обобщения требует затрат во время выполнения.

Обычно эта стоимость незначительна, но есть приложения, в которых накладные расходы на вызовы виртуальных методов и создание объектов могут иметь значение (особенно потому, что виртуальные методы препятствуют другим оптимизациям, таким как встраивание вызовов методов).Именно здесь у C++ есть огромное преимущество, поскольку вы можете использовать шаблоны для достижения другого типа обобщения, которое имеет нет влияет на время выполнения, но не обязательно менее полиморфен, чем ООП.Фактически, все механизмы, составляющие ООП, можно смоделировать, используя только методы шаблонов и разрешение во время компиляции.

В таких случаях (и, надо признать, они часто ограничиваются специальными проблемными областями) C++ выигрывает у C# и сопоставимых языков.

C++ (или C, если уж на то пошло) дает вам детальный контроль над структурами данных.Если вы хотите немного покрутиться, у вас есть такая возможность.Большие управляемые приложения Java или .NET (OWB, Визуальная студия 2005 г.), которые используют внутренние структуры данных библиотек Java/.NET, несут с собой этот багаж.Я видел сеансы дизайнера OWB, использующие более 400 МБ ОЗУ и BIDS для куба или ЭТЛ дизайн также достигает сотен МБ.

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

По моему мнению, в больших приложениях разница не столько в JIT, сколько в структурах данных, которые использует сам код.Если приложение перегружено памятью, вы получите менее эффективное использование кэша.Промахи в кэше современных процессоров обходятся довольно дорого.В чем C или C++ действительно выигрывают, так это в том, что вы можете оптимизировать использование структур данных, чтобы эффективно использовать кэш ЦП.

Для графики стандартный класс C# Graphics работает намного медленнее, чем GDI, доступ к которому осуществляется через C/C++.Я знаю, что это не имеет ничего общего с языком как таковым, а скорее со всей платформой .NET, но графика — это то, что предлагается разработчику в качестве замены GDI, и ее производительность настолько плоха, что я бы даже не осмелился заниматься графикой. с этим.

У нас есть простой тест, который мы используем, чтобы оценить скорость работы графической библиотеки: он просто рисует случайные линии в окне.C++/GDI по-прежнему быстро обрабатывает 10 000 строк, в то время как C#/Graphics с трудом справляется с 1000 строками в реальном времени.

Сбор мусора является основной причиной, по которой Java# НЕ МОЖЕТ использоваться для систем реального времени.

Когда состоится ГК?
Как много времени это займет?

Это недетерминировано.

Нам нужно было определить, сравним ли производительность C# с C++, и для этого я написал несколько тестовых программ (используя Visual Studio 2005 для обоих языков).Оказалось, что без сборки мусора и с учетом только языка (а не фреймворка) C# имеет практически такую же производительность, как и C++.Распределение памяти в C# происходит намного быстрее, чем в C++, и C# имеет небольшое преимущество в детерминированности, когда размеры данных увеличиваются за пределы границ строки кэша.Однако за все это в конечном итоге пришлось заплатить, и это привело к огромным затратам в виде недетерминированного снижения производительности C# из-за сборки мусора.

Как обычно, это зависит от приложения.Есть случаи, когда C#, вероятно, незначительно медленнее, а другие случаи, когда C++ в 5 или 10 раз быстрее, особенно в тех случаях, когда операции можно легко выполнить SIMD.

Я знаю, что это не то, о чем вы спрашивали, но C# часто быстрее. писать чем C++, что является большим преимуществом в коммерческой среде.

C/C++ может работать намного лучше в программах, где есть либо большие массивы, либо тяжелые циклы/итерации по массивам (любого размера).Именно по этой причине графика в C/C++ обычно работает намного быстрее, поскольку в основе почти всех графических операций лежат тяжелые операции с массивами..NET общеизвестно медлителен в операциях индексирования массивов из-за всех проверок безопасности, и это особенно верно для многомерных массивов (и да, прямоугольные массивы C# даже медленнее, чем зубчатые массивы C#).

Бонусы C/C++ наиболее заметны, если вы придерживаетесь непосредственно указателей и избегаете Boost. std::vector и другие контейнеры высокого уровня, а также inline каждая возможная маленькая функция.По возможности используйте массивы старой школы.Да, вам понадобится больше строк кода, чтобы выполнить то же самое, что вы делали в Java или C#, поскольку вы избегаете контейнеров высокого уровня.Если вам нужен массив с динамическим размером, вам просто нужно не забыть соединить new T[] с соответствующим delete[] заявление (или используйте std::unique_ptr) — цена за дополнительную скорость заключается в том, что вам придется писать код более тщательно.Но взамен вы избавляетесь от накладных расходов на управляемую память/сборщик мусора, которые легко могут составлять 20% и более от времени выполнения сильно объектно-ориентированных программ как на Java, так и на .NET, а также таких массивных управляемых программ. затраты на индексацию массива памяти.В некоторых конкретных случаях приложения C++ также могут извлечь выгоду из некоторых изящных переключателей компилятора.

Я опытный программист на C, C++, Java и C#.Недавно мне представился редкий случай реализовать одну и ту же алгоритмическую программу на последних трех языках.В программе было много математических операций и операций с многомерными массивами.Я сильно оптимизировал это на всех трех языках. Результаты были типичными для менее строгих сравнений:Java была примерно в 1,3 раза быстрее, чем C# (большинство JVM более оптимизированы, чем CLR), а версия необработанного указателя C++ работала примерно в 2,1 раза быстрее, чем C#. Обратите внимание, что программа на C# использовала только безопасный код — я считаю, что вам лучше написать ее на C++, прежде чем использовать unsafe ключевое слово.

Чтобы кто-нибудь не подумал, что я имею что-то против C#, в заключение я скажу, что C#, вероятно, мой любимый язык.Это самый логичный, интуитивно понятный и быстрый язык разработки, с которым я когда-либо сталкивался.Все прототипы я делаю на C#.Язык C# имеет множество небольших, тонких преимуществ перед Java (да, я знаю, что у Microsoft была возможность исправить многие недостатки Java, поздно вступив в игру и, возможно, скопировав Java).Тост за Java Calendar класс кто-нибудь?Если Microsoft когда-нибудь приложит серьезные усилия для оптимизации CLR и .NET JITter, C# может серьезно взять верх.Честно говоря, я удивлен, что они этого еще не сделали — они сделали так много вещей правильно в языке C#, почему бы не дополнить это серьезными оптимизациями компилятора?Может быть, если мы все попросим.

>Из того, что я слышал...

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

Как вы собираетесь решить, более или менее правдоподобны то, что говорят здесь люди, по сравнению с тем, что вы слышали изначально?

Одним из способов было бы попросить доказательство.

Когда кто-то утверждает, что «есть области, в которых C# оказывается быстрее, чем C++» Спроси их почему они говорят, что, попросите показать вам размеры, попросите показать вам программы.Иногда они просто допустили ошибку.Иногда вы обнаружите, что они просто выражают мнение, а не делятся чем-то, что, по их мнению, является правдой.

Часто в утверждениях людей смешиваются информация и мнения, и вам придется попытаться разобраться, что есть что.Например, из ответов на этом форуме:

«Возьмите ориентиры на http://shootout.alioth.debian.org/С большим скептицизмом, поскольку они в значительной степени тестируют арифметический код, который, скорее всего, вовсе не похож на ваш код ».

Спросите себя, действительно ли вы понимаете, что "Они в значительной степени проверяют арифметический код" означает, а затем спросите себя, действительно ли автор действительно показал вам, что его требование верно.
«Это довольно бесполезный тест, поскольку он действительно зависит от того, насколько хорошо отдельные программы были оптимизированы;Мне удалось ускорить некоторые из них в 4-6 раз или более, что прояснилось, что сравнение между неоптимизированными программами довольно глупо ».

Спросите себя, действительно ли автор показал вам, что ему удалось «ускорить некоторых из них в 4-6 раз или более» - это легко сделать!

Языки .NET могут быть такими же быстрыми, как код C++, или даже быстрее. но код C++ будет иметь более постоянную пропускную способность поскольку среда выполнения .NET должна приостановиться на ГК, даже если он очень умно относится к своим паузам.

Итак, если у вас есть код, который должен выполняться быстро и без пауз, .NET введет задержку. в какой-то момент, даже если вы очень осторожны с сборщиком мусора во время выполнения.

Для «поразительно параллельных» задач при использовании Intel TBB и OpenMP на C++ я наблюдал примерно 10-кратное увеличение производительности по сравнению с аналогичными (чисто математическими) задачами, решаемыми с C# и TPL.SIMD — это одна из областей, в которой C# не может конкурировать, но у меня также сложилось впечатление, что TPL имеет значительные накладные расходы.

Тем не менее, я использую C++ только для задач, критичных к производительности, где я знаю, что смогу использовать многопоточность и быстро получать результаты.Во всем остальном C# (а иногда и F#) вполне подойдет.

Это чрезвычайно расплывчатый вопрос, на который нет однозначного ответа.

Например;Я предпочитаю играть в 3D-игры, созданные на C++, чем на C#, потому что производительность, конечно, намного выше.(И я знаю XNA и т. д., но это далеко не настоящее).

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

Теоретически для длительно работающих приложений серверного типа JIT-компилируемый язык может стать много быстрее, чем скомпилированный в собственном коде аналог.Поскольку JIT-компилируемый язык обычно сначала компилируется в промежуточный язык довольно низкого уровня, вы в любом случае можете выполнить множество высокоуровневых оптимизаций прямо во время компиляции.Большим преимуществом является то, что JIT может продолжать перекомпилировать разделы кода на лету, получая все больше и больше данных об использовании приложения.Он может организовать наиболее распространенные пути кода, чтобы предсказание ветвей выполнялось как можно чаще.Он может переупорядочивать отдельные блоки кода, которые часто вызываются вместе, чтобы хранить их оба в кеше.Он может потратить больше усилий на оптимизацию внутренних циклов.

Я сомневаюсь, что это делается с помощью .NET или какой-либо из JRE, но это исследовалось еще когда я учился в университете, поэтому вполне разумно думать, что подобные вещи могут вскоре найти свой путь в реальный мир. .

Приложения, требующие интенсивного доступа к памяти, например.манипуляции с изображениями обычно лучше писать в неуправляемой среде (C++), чем в управляемой (C#).Оптимизированные внутренние циклы с арифметикой указателей гораздо проще контролировать в C++.В C# вам, возможно, придется прибегнуть к небезопасному коду, чтобы хотя бы добиться такой же производительности.

я проверял vector в эквиваленте C++ и C# - List и простые 2d-массивы.

Я использую выпуски Visual C#/C++ 2010 Express.Оба проекта представляют собой простые консольные приложения, я тестировал их в стандартном (без пользовательских настроек) режиме выпуска и отладки.Списки C# выполняются на моем компьютере быстрее, инициализация массива в C# также выполняется быстрее, математические операции выполняются медленнее.

Я использую Intel Core2Duo P8600@2,4 ГГц, C# — .NET 4.0.

Я знаю, что векторная реализация отличается от списка C#, но я просто хотел протестировать коллекции, которые я буду использовать для хранения своих объектов (и возможность использовать метод доступа к индексу).

Конечно нужно очищать память (скажем, при каждом использовании new), но я хотел сохранить код простым.

Векторный тест C++:

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

Тест списка С#:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

С++ — массив:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

С# — массив:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

Время:(Выпуск/Отладка)

С++

Инициализация массива 600/606 мс,
заполнение массива 200/270 мс,
Инициализация и заполнение вектора 1 сек/13 сек.

(Да, 13 секунд, у меня всегда проблемы со списками/векторами в режиме отладки.)

С#:

Инициализация массива 20/20 мс,
Заполнение массива 403/440 мс,
710/742 мс. Инициализация и заполнение списка.

Смотря как.Если байт-код транслируется в машинный код (а не только JIT) (я имею в виду, если вы выполняете программу) и если ваша программа использует много выделений/освобождений, это может быть быстрее, потому что ГК Алгоритму достаточно одного прохода (теоретически) через всю память один раз, но обычные вызовы malloc/realloc/free C/C++ вызывают накладные расходы при каждом вызове (накладные расходы на вызовы, накладные расходы на структуру данных, промахи в кеше;)).

Так что теоретически это возможно (в том числе и для других языков GC).

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

Еще одним большим преимуществом является то, что SQL, как и ЛИНК «расширение» предоставляет компилятору возможность оптимизировать вызовы к базам данных (другими словами, компилятор может скомпилировать весь LINQ в один двоичный файл «blob», где вызываемые функции встроены или оптимизированы для вашего использования, но я размышляю здесь ).

Я предполагаю, что есть приложения, написанные на C#, работающие быстро, а также есть другие приложения, написанные на C++, работающие быстро (ну, C++ просто старше...и возьмите UNIX тоже...)
- вопрос действительно в том - на что это жалуются пользователи и разработчики...
Ну, ИМХО, в случае с C# мы имеем очень удобный пользовательский интерфейс, очень хорошую иерархию библиотек и целую интерфейсную систему CLI.В случае C++ у нас есть шаблоны, ATL, COM, MFC и целый набор уже написанного и работающего кода, такого как OpenGL, DirectX и так далее...Разработчики жалуются на неопределённо учащающиеся вызовы GC в случае C# (значит программа работает быстро, и через одну секунду — бац!он застрял).
Писать код на C# очень просто и быстро (не забывать, что это также увеличивает вероятность ошибок).В случае с C++ разработчики жалуются на утечки памяти, - значит, краши, вызовы между DLL, а также на "DLL ад" - проблемы с поддержкой и заменой библиотек на более новые...
Я думаю, что чем больше у вас навыков в языке программирования, тем выше качество (и скорость) будет характеризовать ваше программное обеспечение.

Я бы сказал это так:программисты, которые пишут более быстрый код, лучше осведомлены о том, что заставляет современные машины работать быстро, и, кстати, именно они используют соответствующий инструмент, позволяющий применять точные методы низкоуровневой и детерминированной оптимизации.По этим причинам именно эти люди используют C/C++, а не C#.Я бы даже констатировал это как факт.

> В конце концов, ответы где-то должны быть, не так ли?:)

Эмм, нет.

Как отмечалось в нескольких ответах, вопрос недостаточно конкретизирован способами, которые вызывают в ответ вопросы, а не ответы.Если взять только один путь:

вопрос объединяет язык с языковой реализацией - эта программа на C одновременно в 2194 раза медленнее и в 1,17 раза быстрее чем эта программа на C# - мы должны были бы спросить вас: Какие языковые реализации?

И какие тогда программы?Какая машина?Какая ОС?Какой набор данных?

Если я не ошибаюсь, шаблоны C# определяются во время выполнения.Это должно быть медленнее, чем шаблоны времени компиляции C++.

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

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

Вердикт:

С#:Быстрее развитие, медленнее бег
С++:Медленное развитие, более быстрый бег.

Это действительно зависит от того, чего вы пытаетесь достичь в своем коде.Я слышал, что это всего лишь городская легенда о том, что существует какая-либо разница в производительности между VB.NET, C# и управляемым C++.Однако я обнаружил, по крайней мере при сравнении строк, что управляемый C++ превосходит C#, который, в свою очередь, превосходит VB.NET.

Я ни в коем случае не проводил исчерпывающих сравнений алгоритмической сложности между языками.Я также просто использую настройки по умолчанию для каждого из языков.В VB.NET я использую настройки, требующие объявления переменных и т. д.Вот код, который я использую для управляемого C++:(Как видите, этот код довольно прост).Я использую то же самое на других языках в Visual Studio 2013 с .NET 4.6.2.

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

Между C# и C++ есть некоторые существенные различия с точки зрения производительности:

C# основан на GC/куче.Выделение и сбор мусора сами по себе являются накладными расходами из-за нелокальности доступа к памяти.
Оптимизаторы C++ с годами стали очень хорошими.JIT-компиляторы не могут достичь того же уровня, поскольку у них ограничено время компиляции и они не видят глобальной области видимости.

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

Вдохновленный этим, я провел быстрый тест с 60 процентами общих инструкций, необходимых в большинстве программ.

Вот код C#:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

Строковый массив и список массивов используются намеренно для включения этих инструкций.

Вот код С++:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

Размер входного файла, который я использовал, составлял 40 КБ.

И вот результат -

Код C++ выполнился за 9 секунд.
Код С#:4 секунды!!!

О, но это было в Linux...При работающем C# Мононуклеоз...И C++ с g++.

Хорошо, это то, что я получил в Windows – Визуальная студия 2003 г.:

Код C# выполнился за 9 секунд.
Код C++ – ужасные 370 секунд!!!

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow