Мы должны использовать C "по соображениям производительности"

Ответ 1

"Ничего, кроме C быстро [достаточно]", является ранней оптимизацией и неправильной по всем причинам, из-за которых неправильная ранняя оптимизация. Если ваша система имеет достаточную сложность, что желательно нечто, отличное от C, тогда будут части системы, которые должны быть "достаточно быстрыми" и части с более легкими ограничениями. Если вы пишете свой код, например, в Python вы получите проект быстрее, с меньшим количеством ошибок, тогда вы сможете следить за некоторыми C или ассемблерными кодами, чтобы ускорить критичные по времени детали.

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

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

Ответ 2

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

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

Ответ 3

Использование C для встроенных систем имеет некоторые очень веские причины, из которых "производительность" является лишь одной из второстепенных. Embedded очень близок к аппаратным средствам, вам нужна ручная память, предназначенная для связи с оборудованием. Все API и SDK доступны для C в основном.

Есть только несколько платформ, которые могут запускать виртуальную машину для Java или Mono, что частично связано с последствиями производительности, а также из-за дорогостоящих затрат на внедрение.

Ответ 4

Помимо производительности, есть еще одно соображение: скорее всего, вы будете иметь дело с низкоуровневыми API, которые были предназначены для использования на C или С++.

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

Ответ 5

Для C:

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

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

Ответ 6

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

Пример: Компьютерная игра Benchmarks Game.

Ответ 7

Трудно спорить с C (или другими языками процедур, такими как Pascal, Modula-2, Ada) и сборкой для встроенных. С этими языками существует большая история успеха. Как правило, вы хотите удалить риск неизвестного. По-моему, попытка использовать что-либо, кроме C или сборки, неизвестна. Сказав это, нет ничего плохого в смешанной модели, где вы используете одну из схем, которые идут на C, или Python, или Lua или JavaScript в качестве языка сценариев.

Вы хотите, чтобы быстро и легко перейти на C, когда вам нужно.

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

Ответ 8

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

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

Ознакомьтесь со следующими статьями

• http://theunixgeek.blogspot.com/2008/09/c-vs-python-speed.html

• http://wiki.python.org/moin/PythonSpeed/PerformanceTips (особенно, если Python не является секцией C)

• http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php

Ответ 9

Эта статья (Майкл Барр) рассказывает об использовании C, С++, ассемблер и других языков во встроенных системах и включает в себя график, показывающий относительное использование каждого из них.

И вот еще одна статья, подходяще озаглавленная Плохие причины отказа от С++.

Ответ 10

Ada - это высокоуровневый язык программирования, предназначенный для встроенных систем и критически важных систем.

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

В эта ссылка у вас есть сравнение между Ada и C.

Ответ 11

Вы можете посмотреть на D язык программирования. Он может использовать некоторую настройку производительности, так как есть некоторые области, которые Python может превзойти. Я не могу направить вас на сравнительные сравнения, так как не сохранил список, но, как указал Питер Олссон, Контрольные показатели и языковые реализации имеет D Digital Mars.

Вероятно, вы также захотите посмотреть на эти прекрасные вопросы:

• Встраивание с D (язык программирования)
• Как вы подходите к использованию D во встроенной среде реального времени?

Ответ 12

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

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

Java и С# (на Micro.Net или WinCE) могут быть жизнеспособными альтернативами для не реального времени.

Ответ 13

Я на самом деле не системный/встроенный программист, но мне кажется, что встроенные программы обычно нуждаются в детерминированной производительности, что сразу же исключает многие сборники мусора, потому что они не детерминированы вообще. Тем не менее, работа над детерминированной сборкой мусора (например, Metronome for Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html)

Проблема связана с ограничениями - совместимы ли языки/среды выполнения с детерминированными потребностями использования памяти и т.д.

Ответ 14

C действительно ваш лучший выбор.

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

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

Ответ 15

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

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

Ответ 16

Вот пара статей, которые сравнивают С# с С++:

http://systematicgaming.wordpress.com/2009/01/03/performance-c-vs-c/

http://journal.stuffwithstuff.com/2009/01/03/debunking-c-vs-c-performance/

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

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

Ответ 17

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

Ответ 18

Правда - не всегда.

Кажется, что среда исполнения .NET(но любая другая среда выполнения может быть взята в качестве примера) накладывает несколько МБ служебных данных во время выполнения. Если это все, что у вас есть (в ОЗУ), вам не повезло. JavaME кажется более компактным, но он все еще зависит от ресурсов, которые у вас есть в вашем распоряжении.

Ответ 19

Много кода C работает быстро, потому что люди, которые его написали, были Zen Masters of software. Они должны быть хозяевами, кусая пулю и узнавая не только то, что хочет пользователь, но и то, что хочет компилятор, что хочет O/S, что хочет оборудование, зная структуры данных и алгоритмы, как задние части рук, зная, как чтобы выжать максимум из кэшей на кристалле, и что будет делать следующее поколение процессоров и графических процессоров с их кодом.

Не так сложно писать программное обеспечение, которое работает, и работает правильно. Очень сложно написать программное обеспечение, которое работает 10x-5000X (да, что в 5 тысяч раз быстрее), которое все еще легко читать и понимать, может быть расширено по разумной цене и будет продолжать выполнять на исключительных уровнях в течение нескольких поколений Процессоры впереди.

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

После 20 лет написания кода C я недавно написал приложение, которое превышает требования, требуемые 10 000X. Мне довелось пересмотреть его сегодня, все 500 строк кода. Для каждой строки кода на странице я написал и удалил как минимум еще 10, сравнивал их, проверял и в конечном итоге отбрасывал. Какой смысл в достижении производительности до сих пор выше того, что было указано? Потому что в какой-то момент ничего не получилось бы.

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

Печальная истина: "Ничего не получается, как успех". Я бы предпочел, чтобы производительность мне не нужна, чем нужна производительность, которой у меня нет. Если вы приближаетесь к второму условию, ваша компания выходит из бизнеса и, вероятно, намного раньше, чем вы думаете. Мне не нравится писать "провалившиеся киты", успех которых в том, что их разрушает. C убирается с моего пути и позволяет мне внедрять новшества так, как ни один другой язык не делает.

Ответ 20

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

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