Мне нужна высокая производительность. Будет различие, если я буду использовать C или C++?

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

Хорошие ответы. Я бы сказал так:

1. Сделайте алгоритм как можно более эффективным с точки зрения его формальной структуры.

2. C ++ будет таким же быстрым, как C, за исключением , что он соблазнит вас сделать глупость такие вещи, как создание объектов, которые вам не нужны, так что не попадайтесь на удочку. Такие вещи, как классы контейнеров STL и итераторы, могут выглядеть новейшими и лучшими, но они убьют вас в горячей точке.

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

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

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

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

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

надеюсь, что это поможет

Другой аспект:

Шаблоны C ++ могут быть отличным инструментом для создания / оптимизированные варианты кода.

Например, C qsort требует вызова функции компаратора, тогда как std :: sort может встроить переданный функтор. Это может иметь существенное значение, если сравнение и обмен сами по себе дешевы.

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

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

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

edit : хорошо, см. Bjarne Страуструп обсуждение qsort и std :: sort , а также статья, упоминаемая в FAQ ( Изучение стандартного C ++ как нового языка ), где он показывает, что код в стиле C ++ может быть не только короче и читабельнее (из-за более высокой абстракции), но также несколько быстрее.

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

Пока вы не используете какие-либо виртуальные функции и т. Д., Вы не заметите каких-либо значительных различий в производительности. Ранний C ++ был скомпилирован в C, поэтому, если вы знаете точки, в которых это создает значительные накладные расходы (например, с виртуальными функциями), вы можете четко вычислить различия.

Кроме того, я хочу отметить, что использование C ++ может дать вы много выиграете, если будете использовать библиотеки STL и Boost. В частности, STL предоставляет очень эффективные и проверенные реализации наиболее важных структур данных и алгоритмов, так что вы можете сэкономить много времени на разработку.

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

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

C ++ также предоставляет шаблоны, которые обеспечивают лучшую производительность, чем использование void * для общего программирования.

Нет, если вы не используете виртуальные функции.

Изменить: Если у вас есть случай, когда вам нужен динамизм во время выполнения, тогда да, виртуальные функции работают так же быстро или быстрее чем созданный вручную оператор if-else . Однако, если вы добавляете ключевое слово virtual перед методом, но на самом деле вам не нужен полиморфизм, вы будете платить ненужные накладные расходы. Компилятор не будет оптимизировать его во время компиляции. Я просто указываю на это, потому что это одна из особенностей C ++, которая нарушает «принцип нулевых накладных расходов» (цитируя Страуструпа).

В качестве примечания, поскольку вы упоминаете интенсивное использование fp math:

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

Класс Solver будет построен один раз, я так понимаю, а метод run выполняется один раз ... в такой среде вы не увижу разницы. Вместо этого есть на что остерегаться:

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

• Создание экземпляров классов обычно означает ... выделение памяти! Опять же, создание экземпляров нескольких объектов и их повторное использование практически не требуется. Но будьте осторожны при создании объектов только для того, чтобы сразу же их разрушить и восстановить!

• Выберите правильный вариант плавающей запятой для вашей архитектуры, насколько позволяет проблема. Возможно, что double будет быстрее, чем float , хотя для этого потребуется больше памяти. Вы должны поэкспериментировать, чтобы настроить это. В идеале вы должны использовать #define или typedef , чтобы указать тип, чтобы его можно было легко изменить в одном месте.

• Целочисленные вычисления, вероятно, быстрее, чем вычисления с плавающей запятой. В зависимости от числового диапазона ваших данных вы также можете рассмотреть возможность использования целых чисел, рассматриваемых как десятичные дроби с фиксированной запятой. Если вам нужно 3 десятичных разряда, вы можете использовать int s и просто считать их «миллиардом». Вам нужно будет не забыть сдвигать десятичные дроби после деления и умножения ... но ничего страшного. Если вы используете какие-либо математические функции помимо базовой арифметики, конечно, это, конечно, убило бы эту возможность.

Практическое правило - не оптимизируйте, пока не знаете, что оптимизировать. Итак, начните с C ++ и получите рабочий прототип. Затем профилируйте его и перепишите горлышки бутылок в сборке. Но, как отмечали другие, выбранный алгоритм будет иметь гораздо большее влияние, чем язык.

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

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