2009-08-14 1 views
4

Я видел много аргументов в отношении общей производительности кода C, составленного с помощью компилятора C++ - Мне любопытно, есть ли какие-либо солидные экспериментальные исследования, погребенные под всеми анекдотическими пламенными войнами, которые вы найдете в Интернете поиск. Меня особенно интересует пакет GCC, но любые точки данных будут интересны. (Сравнение сборки «Hello, World!» Не так проворно, как хотелось бы. :-)Существуют ли окончательные исследования/эксперименты по компиляции C с использованием компилятора C++?

Я обычно предполагаю, что вы используете флаги «встроенного стиля» - без исключений или RTTI. Я также не возражаю узнать, есть ли исследования по самому времени компиляции. ТИА!

+0

Сравнение различных компиляторов? Сравнение компиляции C с компиляцией C++ одним и тем же компилятором? (будет ли разница?) А что такое флаги «встроенного стиля»? –

+0

К тому же комплексу компилятора (т. Е. Gcc vs. g ++). Из-за различий в спецификации полезная оптимизация может быть более или менее применима в промежуточном представлении одного языка по сравнению с другим (или некоторые оптимизации могут быть включены для одного языка, который не включен для другого). Я упомянул два встроенных флага стиля - те, которые запрещают поддержку исключений, и те, которые отключают RTTI. – cdleary

+0

Если вы скомпилируете C-подобный код, я не вижу, как любой из этих флагов применим в любом случае - если у вас есть только POD, в любом месте нет деструкторов и, следовательно, нет необходимости в коде обработки исключений. Поскольку нет виртуальных функций, RTTI не требуется, за исключением вызовов 'typeid', разрешенных во время компиляции, и если их нет, тогда нет никакой необходимости. –

ответ

1

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

+0

Правильно, вот что говорит большинство людей в пламенной войне; однако на lkml также есть некоторые доказательства того, что ядро ​​Linux попыталось собрать компиляцию с g ++ некоторое время назад и закончилось значительным замедлением. – cdleary

+0

Компиляция ядра Linux - особый случай; они имеют такие ограничения, как размер стека и распределение кучи, которые не применяются к обычным приложениям. – MarkR

+0

На ядре Linux на C++: это было не просто замедление. Были трудности с управлением памятью, и вся обработка исключений в ядре - это кошмар для управления через контексты. Торвальдс упоминает об этом в письме об этом еще в 2004 году. Я не знаю, сколько из этого изменилось с тех пор. –

0

Я не пробовал это с точки зрения производительности, но я думаю, что компиляция приложений C с помощью компилятора C++ является хорошей идеей, так как это помешает вам совершать «непослушные» вещи, такие как использование не объявленных функций.

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

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

Вам также не нужно будет использовать некоторые C99 вещи, такие как bool_t, которые C++ не поддерживает на основе наличия собственных.

+0

Я имею в виду, что у меня есть существующий код кода C, и я желая сделать небольшие синтаксические поправки (например, отличать значения из malloc, избавиться от stdbool и т. д.), чтобы заставить его скомпилировать с компилятором C++, и меня интересует дельта производительности. – cdleary

+0

Я должен был сказать: «Попробуй и посмотри». Я не думаю, что двоичный файл будет работать медленнее во время выполнения, он может быть немного больше и иметь более длительное время запуска. – MarkR

+0

Правильно, поэтому мой вопрос заключается в том, интересно ли люди «пробовали» и видели «кучу раз» (надеюсь, в разных приложениях), записывали результаты и публиковали их. ;-) – cdleary

1

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

Что вы в основном получаете, когда компилируете код C с помощью компилятора C++, является гораздо более строгая проверка (объявления функций и т. Д.). IMO это сделало бы компиляцию C-кода с компилятором C++ весьма привлекательным. Но учтите, что если у вас есть большая база кода кода C, которая никогда не запускается с помощью компилятора C++, вы, вероятно, столкнетесь с крутым боем на высоту до , пока код не будет достаточно чистым, чтобы увидеть какие-либо значимые предупреждения.

+0

Почему использование компилятора C++ приводит к более строгой проверке?Или вы один из тех людей, которые, кажется, никогда не слышали о предупреждающих флажках (по крайней мере, '-pedantic -Wall -Wextra' для gcc; для более полного списка см. Здесь: http://stackoverflow.com/questions/432835/how-do-you-make-that-you-as-programmer-have-written-quality-c-code/432852 # 432852)? – Christoph

+0

@Christoph: C++ _as language_ является более строгим. Например, он не допускает неявных преобразований из'void * 'в любой другой тип указателя - вы должны явно указывать. Такие вещи, о которых я говорил. – sbi

+0

C++ может быть более безопасным, но вы хотите использовать компилятор C++ для компиляции кода C *! (Не) проблема неявного отбрасывания «void *» в сторону, на C++ совместима с C более чем на C99 - на самом деле это будет регрессия, поскольку C++ не поддерживает такие вещи, как сложные литералы или назначенные инициализаторы ; единственная реальная проблема, которую я могу придумать для компилятора C++, может решить, это молчание при отбрасывании 'const' через возвращаемое значение (библиотечных) функций, но тогда вам придется использовать перегруженную версию C++ stdlib, которая привела бы к в коде, который больше не может быть скомпилирован с компилятором C – Christoph

-1

В прошлом я делал такие вещи, как посмотрите на размер двоичного файла, который для C++ был огромным, это не значит, что они просто связаны в кучу непринужденных библиотек. Самым простым может быть использование gcc -S myprog.cpp vs gcc -S myprog.c и разграничение выхода ассемблера.

+0

Размер результирующего бинарного сообщения очень мало (если вообще) его производительности. Также не представлено его asm-представление. – ezpz

+0

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

+0

Конечно, если производительность желательна, вы бы не использовали gcc в любом случае –

13

Добавление Datapoint (или, по крайней мере, анекдот):

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

В тот момент, когда мы начали переключение, мы очень внимательно посмотрели на сгенерированный код сборки (используя GCC) на ряд функций и подтвердили, что он фактически был по существу идентичным, был ли файл скомпилирован как C или C++ - где «по существу идентичны» я имею в виду различия в таких вещах, как имена символов и материал в начале и конце файла сборки; фактические инструкции в середине функций были точно идентичны.

Извините, что у меня нет более надежного ответа.

Редактировать добавить, 2013-03-24: Недавно я наткнулся на статью, где Расти Рассел по сравнению производительности на GCC компилируется с компилятором и скомпилирован с C++ компилятор, в ответ на недавний переключатель для компиляции GCC как C++: http://rusty.ozlabs.org/?p=330. Выводы интересны: версия, скомпилированная с помощью компилятора C++, была немного медленнее; разница составляла около 0,3%. Однако это было полностью объяснено различиями во времени загрузки, вызванными большей информацией об отладке; когда он разделил двоичные файлы и удалил информацию об отладке, различия составляли менее 0,1%, то есть практически неотличимы от шума измерения.

+2

Не нужно жалеть, это, кажется, самый обоснованный ответ. – sbi

0

Не делайте этого, если код не предназначен. Те же допустимые языковые конструкции могут приводить к разному поведению, если они интерпретируются как C или как C++. Вы могли бы представить очень трудно понять ошибки. Менее проблематичный, но все же кошмар ремонтируемости; некоторые C-конструкции (особенно из C99) недействительны в C++.

1

Проект GCC в настоящее время находится на этапе перехода от C к C++, то есть GCC может быть реализован на C++ в будущем, он в настоящее время написан на C. Следующая версия GCC будет записана в подмножестве C который также действителен C++.

Some performance tests были выполнены на g++ против gcc, на кодовой базе ССЗ. Они сравнивали время загрузки, что означает компиляцию gcc с помощью sysmem-компилятора, а затем компиляцию с результирующим компилятором, а затем повторение и проверка результатов одинаковы.

Резюме: Использование g ++ было на 20% медленнее. Варианты компилятора были несколько разными, но считалось, что это не приведет к 20% -ной разнице.

Обратите внимание, что это измеряет разные программы gcc vs g ++, которые, хотя они в основном используют один и тот же код, имеют разные интерфейсы.