C помітно швидший за C ++ [закрито]

Наскільки я розумію, усі мови сценаріїв та основні наукові програми, як правило, написані на мові C; це робить реалізацію безладною, але певним чином прямою.

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

Що робить C швидшим і чи помітна різниця у проекті, такому як python або sqlite, який повинен бути найшвидшим?

C ++ часто використовується для наукових програм. Популярність C може зменшуватися в цьому домені. Fortran залишається популярним як мова "низького рівня".

У C ++ "ви платите лише за те, що використовуєте". Отже, немає нічого, що могло б зробити це повільнішим, ніж С. Зокрема, для наукових програм шаблони виразів дозволяють виконати певну спеціальну оптимізацію за допомогою механізму шаблонів для обробки семантики програм.

Причиною того, що C є кращим для таких проектів, як Python, є те, що він, як правило, стає менш заплутаним для читання, тому велика кодова база буде доступнішою для більшої групи учасників.

SQLite має вимогу до невеликого розміру виконуваного коду, де C має невеликий край. Розумне використання C ++ все ще дозволяє використовувати його у вбудованих додатках, але він менш популярний через страх, що небажані мовні функції не потраплять.

Я не думаю, що причина пов’язана настільки з продуктивністю, скільки зі сумісністю. Мова С ++ є більш складною, ніж мова С, але з точки зору продуктивності не повинно бути помітної різниці в будь-якому випадку. Деякі конструкції C ++ швидші за еквівалент C ( std::sortшвидше ніж qsort), і, мабуть, є хороші приклади навпаки.

РЕДАГУВАТИ: Що стосується взаємодії ...

В основному стандарт C ++ не визначає деяких речей, які можуть знадобитися для зручності взаємодії між двійковими файлами, створеними за допомогою різних компіляторів / версій. Найбільш помітним питанням тут було б узгодження імен символів у двійковому файлі. На мові C мова визначає єдине відображення кожного символу в коді до імені двійкового символу. Функція, що викликається my_function, створить символ у двійковому файлі, що викликається my_function. З іншого боку, і через такі функції, як перевантаження функцій, імена функцій C ++ повинні бути зіпсовані(переведено у різні символи функції у двійковому файлі, кодуючи типи аргументів та типи повернення), а стандарт не визначає, як виконується манґлінг. Це, в свою чергу, означає, що одну і ту ж функцію в C ++ можна скомпілювати до різних символів залежно від компілятора (якщо extern "C"це не використовується для примусової сумісності C для цих функцій у C ++).

Зрештою, інтерфейс між мовою сценаріїв та власним кодом у будь-якому випадку повинен бути інтерфейсом C, навіть якщо деталі того, як він реалізований внутрішньо, можуть бути C / C ++ / будь-якою іншою рідною мовою.

(Я навмисно не хочу вступати у полум’яну війну мовних приставок, С ++ дійсно потужний, але він також трохи страшний, оскільки це набагато складніша мова, ніж С, і деякі речі, які виглядають простими, можуть вплинути на продуктивність)

Як згадував Бьярн у [D&E], ефективність є однією з головних цілей C ++. Отже, C ++ працює повільніше лише тоді, коли програміст використовує свої "додаткові" функції, такі як віртуальні функції, про які ви згадали, інформацію про rtt тощо

Тому я думаю, що це скоріше з психологічних причин - використовується C, оскільки він не допускає "повільних" функцій C ++.

Мови за своєю суттю не швидші і не повільніші, перекладачі та компілятори можуть бути більш-менш ефективними.

Крім того, мови вищого рівня забезпечують абстракційні рівні, які зазвичай мають вартість виконання. Якщо ви не використовуєте їх, компілятор може бути досить розумним, щоб їх видалити, але це може бути неможливим, якщо семантика мови не дозволяє зробити це безпечно ... А якщо вони вам потрібні, реалізуйте їх самостійно на мові нижчого рівня, можливо, буде повільніше, ніж на використанні "повільної" мови.