Сколько быстрее C++, чем C#?
ПОЦЕЛУЙ. С вашими перечислениями вы будете делать всевозможные другие вещи для переключения / случая, так почему печать должна отличаться? Забывание случая в вашей типографии печати не является огромной сделкой, если вы считаете, что есть около 100 других мест, которые вы можете забыть. Просто скомпилируйте -Wall, который будет предупреждать о не исчерпывающих совпадениях. Не используйте «default», потому что это сделает ключ исчерпывающим, и вы не получите предупреждения. Вместо этого позвольте коммутатору выйти и обработать случай по умолчанию, например ...
const char *myenum_str(myenum e)
{
switch(e) {
case ONE: return "one";
case TWO: return "two";
}
return "invalid";
}
21 ответ
Нет никакой строгой причины, почему основанный на байт-коде язык как C# или Java, который имеет JIT, не может быть с такой скоростью, как код C++. Однако код C++ раньше был значительно быстрее в течение долгого времени, и также сегодня все еще во многих случаях. Это происходит главным образом из-за более усовершенствованной оптимизации JIT, сложной для реализации, и действительно прохладные только прибывают сейчас.
, Таким образом, C++ быстрее, во многих случаях. Но это - только часть ответа. Случаи, где C++ на самом деле быстрее, являются высоко оптимизированными программами, где опытные программисты полностью оптимизировали ад из кода. Это не является только очень трудоемким (и таким образом дорогим), но также и обычно приводит к ошибкам из-за сверхоптимизации.
, С другой стороны, код на интерпретируемых языках становится быстрее в более поздних версиях времени выполнения (CLR.NET или Java VM) без Вас делающий что-либо. И существует много полезных JIT-компиляторов оптимизации, может сделать, которые просто невозможны на языках с указателями. Кроме того, некоторые утверждают, что сборка "мусора" должна обычно быть настолько же быстрой или быстрее как ручное управление памятью, и во многих случаях это. Можно обычно реализовывать и достигать всего этого в C++ или C, но это будет намного более сложным и подверженным ошибкам.
, Поскольку Donald Knuth сказал, "преждевременная оптимизация является корнем всего зла". Если Вы действительно знаете наверняка, что Ваше приложение будет главным образом состоять из очень производительности критическая арифметика, и что это будет узкое место, и это, конечно, будет быстрее в C++, и Вы уверены, что C++ не будет конфликтовать с Вашими другими требованиями, пойдите для C++. В любом другом случае концентрат при первом реализовывании Вашего приложения правильно на любом языке подходит Вам лучше всего, затем найдите узкие места производительности, если это работает слишком медленный, и затем думайте о том, как оптимизировать код. В худшем случае Вы, возможно, должны были бы обратиться к коду C через внешний функциональный интерфейс, таким образом, у Вас все еще будет способность записать критические части на более низком языке уровня.
Имеют в виду, что относительно легко оптимизировать корректную программу, но намного тяжелее исправить оптимизированную программу.
Предоставление фактических процентов преимуществ скорости невозможно, оно в основном зависит от Вашего кода. Во многих случаях реализация языка программирования не является даже узким местом. Возьмите сравнительные тесты в http://benchmarksgame.alioth.debian.org/ с большим скептицизмом, поскольку они в основном тестируют арифметический код, который наиболее вероятен не подобный Вашему коду вообще.
>, В конце концов, ответы должны быть где-нибудь, не так ли?:)
Umm, нет.
Как несколько отмеченных ответов, вопрос под-указанным способами, которые приглашают вопросы в ответ, не ответы. Взять всего один путь:
- вопрос соединяет язык с реализацией языка - эта программа C и в 2,194 раза медленнее и в 1.17 раза быстрее , чем эта программа C# - мы должны были бы спросить Вас: , Который реализации языка?
И затем который программы? Какая машина? Который ОС? Какой набор данных?
Я предполагаю, что существуют приложения, записанные в C#, работающем быстро, а также существует больше C++ записанные приложения, работающие быстро (хорошо C++, просто более старый..., и возьмите UNIX также...)
- вопрос действительно - что является той вещью, пользователи и разработчики жалуются на...
ну, по моему скромному мнению, в случае C# у нас есть очень комфорт UI, очень хорошая иерархия библиотек и целая интерфейсная система CLI. В случае C++ у нас есть шаблоны, ATL, COM, MFC и целая хижина alreadyc записанный и рабочий код как OpenGL, DirectX и так далее... Разработчики жалуются на indeterminably повышенные вызовы GC в случае C# (означает прогоны программы быстро, и за одну секунду - удар! это застревает).
Для записи кода в C#, очень простом и быстром (чтобы не забыть, что также увеличивают шанс ошибок. В случае C++ разработчики жалуются на утечки памяти, - средство сокрушает, вызовы между DLLs, а также "ада DLL" - проблема с библиотеками поддержки и замены более новыми...
я думаю больше навыка, который Вы будете иметь на языке программирования, больше качества (и скорость) будет характерно для Вашего программного обеспечения.
Приложения, которые требуют интенсивного доступа к памяти, например, обработки изображения, обычно более обеспечены записанный в неуправляемой среде (C++), чем управляемый (C#). Оптимизированные внутренние циклы с адресной арифметикой с указателями намного легче иметь контроль над в C++. В C# Вы, возможно, должны были бы обратиться к небезопасному коду для ровного получения около той же производительности.
В теории, для длительного приложения серверного типа, скомпилированный в JIT язык может стать очень быстрее, чем исходно скомпилированный дубликат. Так как скомпилированный язык JIT вообще сначала компилируется в промежуточный язык довольно низкого уровня, можно сделать большую правильно высокоуровневую оптимизацию во время компиляции так или иначе. Большое преимущество прибывает, в котором JIT может продолжить перекомпилировать разделы кода на лету, поскольку это надевает все больше данных, как приложение используется. Это может расположить наиболее распространенные пути выполнения кода, чтобы позволить предсказанию ветвлений успешно выполняться максимально часто. Это может перестроить отдельные блоки кода, которые часто собираются для хранения их обоих в кэше. Это может потратить больше усилия, оптимизировав внутренние циклы.
я сомневаюсь, что это сделано.NET или любым из JREs, но она исследовалась назад, когда я был в университете, таким образом, весьма разумно думать, что подобные вещи могут найти свой путь в реальный мир в какой-то момент скоро.
Это - чрезвычайно неопределенный вопрос без реальных категорических ответов.
, Например; я играл бы в 3D игры, которые создаются в C++, чем в C#, потому что производительность, конечно, намного лучше. (И я знаю XNA, и т.д., но он не прибывает никакой путь около реальной вещи).
, С другой стороны, как ранее упомянуто; необходимо разработать на языке, который позволяет Вам сделать то, что Вы хотите быстро, и затем при необходимости оптимизируете.
Один конкретный сценарий, где C++ все еще имеет власть (и будет, в течение многих последующих лет) происходит, когда полиморфные решения могут быть предопределены во время компиляции.
Обычно инкапсуляция и задержанное принятие решений являются хорошей вещью, потому что это делает код более динамичным, легче адаптироваться к изменяющимся требованиям и легче использовать в качестве платформы. Поэтому объектно-ориентированное программирование в C# очень продуктивно, и это может быть обобщено в термин “generalization”. К сожалению, этот конкретный вид обобщения прибывает в стоимость во времени выполнения.
Обычно, эта стоимость является несущественной, но существуют приложения, где издержки виртуальных вызовов метода и создания объекта могут иметь значение (тем более, что виртуальные методы предотвращают другую оптимизацию, такую как встраивание вызова метода). Это - то, где C++ имеет огромное преимущество, потому что можно использовать шаблоны для достижения другого вида обобщения, которое имеет никакой влияние на время выполнения, но является не обязательно любым менее полиморфным, чем ООП. На самом деле все механизмы, которые составляют ООП, могут быть смоделированы с помощью, только обрабатывают по шаблону разрешение времени компиляции и методы.
В таких случаях (и по общему признанию, они часто ограничиваются специальными проблемными областями), C++ выигрывает у C# и сопоставимых языков.
Я знаю, что это не то, что Вы спрашивали, но C# часто более быстр к запись , чем C++, который является большой премией в коммерческой установке.
Как обычно, это зависит от приложения. Существуют случаи, где C# является, вероятно, незначительно более медленными, и другими случаями, где C++ в 5 или 10 раз быстрее, особенно в случаях, где операциями может быть легко SIMD'd.
Мы должны были определить, был ли C# сопоставим с C++ в производительности, и я записал некоторые тестовые программы для того (использующий Visual Studio 2005 для обоих языков). Оказалось, что без сборки "мусора" и только рассмотрения языка (не платформа) C# имеет в основном то же представление в качестве C++. Выделение памяти является путем быстрее в C#, чем в C++, и C# имеет небольшой край в детерминизме, когда размеры данных увеличены вне границ строки кэша. Однако все это нужно было в конечном счете оплатить и существует огромная стоимость в форме недетерминированных хитов производительности для C# из-за сборки "мусора".
Сборка "мусора" является главной причиной, Java# не МОЖЕТ использоваться для систем реального времени.
-
, Когда GC произойдет?
-
, Сколько времени это возьмет?
Это недетерминировано.
Для графики стандартный класс Графики C# является путем медленнее, чем GDI получил доступ через C/C++. Я знаю, что это не имеет никакого отношения к языку по сути, больше с общей платформой.NET, но Графика - то, что предлагается разработчику как замена GDI, и ее производительность так плоха, я даже не смел бы делать графику с ним.
у Нас есть простой сравнительный тест, который мы используем, чтобы видеть, как быстро графическая библиотека, и это просто проводит случайные линии в окне. C++ / GDI является все еще мгновенным с 10 000 строк, в то время как C#/Graphics испытывает затруднения при выполнении 1000 в режиме реального времени.
C++ (или C в этом отношении) дает Вам мелкомодульный контроль над Вашими структурами данных. Если Вы хотите к биту - вертят Вас, имеют ту опцию. Большой управляемый Java или приложения.NET (OWB, Visual Studio 2005 ), которые используют внутренние структуры данных библиотек Java/.NET, несут багаж с ними. Я видел, что сессии разработчика OWB используют по 400 МБ RAM и ПРЕДЛОЖЕНИЙ на куб или дизайн ETL, входящий 100's МБ также.
На предсказуемой рабочей нагрузке (такой как большинство сравнительных тестов, которые много раз повторяют процесс) JIT может получить Вас код, который оптимизирован достаточно хорошо, что нет никакого практического различия.
IMO на крупных приложениях различием не является так JIT как структуры данных, что сам код использует. Где приложение тяжело памятью, Вы получите менее эффективное использование кэша. Неудачные обращения в кэш на современных центральных процессорах являются довольно дорогими. То, где C или C++ действительно побеждают, - то, где можно оптимизировать использование структур данных для игры приятно с кэшем ЦП.
> Из того, что я услышал...
Ваша трудность, кажется, находится в решении, вероятно ли то, что Вы услышали, и та трудность будет просто повторена, когда Вы попытаетесь оценить ответы на этот сайт.
, Как Вы собираетесь решить, говорят ли вещи люди здесь, более или менее вероятны, чем, что Вы первоначально слышали?
Один путь состоял бы в том, чтобы попросить [1 118] доказательство .
, Когда кто-то требует ", существуют некоторые области, в которых C# оказывается быстрее, чем C++" спрашивает их , почему они говорят, что , попросите, чтобы они показали Вам измерения, попросите, чтобы они показали Вам программы. Иногда они будут просто делать ошибку. Иногда Вы будете узнавать, что они просто выражают мнение вместо того, чтобы совместно использовать что-то, что они могут показать, чтобы быть верными.
Часто информация и мнение будут перепутаны в том, чего требуют люди, и необходимо будет попытаться разобраться, который является который. Например, от ответов на этом форуме:
-
"Берут сравнительные тесты в http://shootout.alioth.debian.org/ с большим скептицизмом, поскольку они в основном тестируют арифметический код, который наиболее вероятен не подобный Вашему коду вообще".
Спрашивают себя, если Вы действительно понимаете то, что "они в основном тестируют арифметический код" средства, и затем спрашивают себя, если автор на самом деле показал Вам, что его требование верно.
-
"Это - довольно бесполезный тест, так как он действительно зависит от того, как хорошо отдельные программы были оптимизированы; мне удалось ускорить некоторые из них к 4-6 разам или больше, прояснив, что сравнение между неоптимизированными программами довольно глупо".
Спрашивают себя, показал ли автор на самом деле Вам, что им управляют для "ускорения некоторых из них к 4-6 разам или больше" - это - легкое требование сделать!
По моему опыту (и я работал много с обоими языками), основной проблемой с C# по сравнению с C++ является потребление верхней памяти, и я не нашел хороший способ управлять им. Это было потребление памяти, которое в конечном счете замедлит программное обеспечение.NET.
Другой фактор - то, что JIT-компилятор не может выкроить слишком много времени, чтобы сделать усовершенствованную оптимизацию, потому что это работает во времени выполнения, и конечный пользователь заметил бы его, если требуется слишком много времени. С другой стороны, компилятор C++ имеет все время, он должен сделать оптимизацию во время компиляции. Этот фактор является намного менее значительным, чем потребление памяти, по моему скромному мнению.
Это - пять апельсинов быстрее. Или скорее: не может быть никакого (корректного) общего ответа. C++ является статически скомпилированным языком (но тогда, существует ведомая оптимизация профиля, также), выполнения C#, которым помогает JIT-компилятор. Существует столько различий, что на вопросы как “how много faster” нельзя ответить, даже путем предоставления порядков величины.
C# не может быть быстрее, но он делает ВАС/ME быстрее. Это - самая важная мера для того, что я делаю.:)
При «смущающе параллельных» проблемах при использовании Intel TBB и OpenMP на C ++ я наблюдал примерно 10-кратное увеличение производительности по сравнению с аналогичными (чисто математическими) проблемами, выполняемыми с C # и TPL. SIMD - это одна из областей, в которой C # не может конкурировать, но у меня также сложилось впечатление, что TPL имеет значительные накладные расходы.
Тем не менее, я использую C ++ только для задач, критичных к производительности, где я знаю, что смогу многопоточность и получить результаты быстро. , Для всего остального C # (а иногда и F #) просто отлично.
Языки .NET могут быть такими же быстрыми, как код C ++, или даже быстрее, , но код C ++ будет иметь более постоянную пропускную способность , чем код Среда выполнения .NET должна приостанавливаться для GC , даже если она очень умно делает паузы.
Итак, если у вас есть код, который должен постоянно работать быстро, без пауз, .NET в какой-то момент привнесет задержку , даже если вы очень осторожны с сборщиком мусора во время выполнения.
Вдохновленный этим, я провел быстрый тест с 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();
}
Строковый массив и Arraylist специально используются для включения этих инструкций.
Вот код на C ++:
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 секунд.
- Код C #: 4 секунды !!!
О, но это было в Linux ... С C #, работающим на Mono ... И C ++ с g ++.
Хорошо, вот что я получил в Windows - Visual Studio 2003 :
- Код C # запускался за 9 секунд.
- Код на C ++ - ужасные 370 секунд !!!
Ну, это зависит от обстоятельств. Если байт-код транслируется в машинный код (а не только JIT) (я имею в виду, если вы выполняете программу) и , если ваша программа использует много распределений / освобождений, это может быть быстрее, потому что Алгоритму GC достаточно одного прохода (теоретически) через всю память один раз, но обычные вызовы malloc / realloc / free C / C ++ вызывают накладные расходы при каждом вызове (накладные расходы на вызовы, накладные расходы на структуру данных, промахи в кеше;)) .
Так что теоретически это возможно (также для других языков GC).
Я действительно не вижу крайнего недостатка в невозможности использовать метапрограммирование с C # для большинства приложений, потому что большинство программистов все равно не используют его.
Еще одно большое преимущество заключается в том, что SQL, как и «расширение» LINQ , предоставляет компилятору возможности для оптимизации вызовов баз данных (другими словами, компилятор может скомпилировать весь LINQ в один «blob-объект»). "двоичный файл, в котором вызываемые функции встроены или оптимизированы для вашего использования, но я здесь размышляю).