Мы должны использовать C "из соображений производительности"
В наш век многих языков, кажется, есть отличный язык для почти каждой задачи, и я обнаружил, что профессионально борюсь с мантрой "ничего, кроме С, быстро", где "быстрое" действительно означает "достаточно быстро". Я работаю с очень рациональными, непредубежденными людьми, которые любят сравнивать цифры, и все, что у меня есть, это мысли и мнения. Не могли бы вы помочь мне найти дорогу мимо субъективных мнений и в "реальный мир"?
Не могли бы вы помочь мне найти исследование относительно того, что, если бы другие языки могли использоваться для программирования на встраиваемых и (Linux) системах? Я вполне мог выдвинуть ложную гипотезу и был бы очень признателен, если бы исследование показало мне это. Не могли бы вы дать ссылку или включить хорошие цифры, чтобы помочь свести комментарии "это только его / ее мнение" к минимуму.
Так что это мои конкретные требования
- память не является серьезным ограничением
- мобильность не является серьезной проблемой
- это не система реального времени
19 ответов
"Ничего, кроме C - это быстро [достаточно]" - это ранняя оптимизация и неправильная по всем причинам, по которым ранняя оптимизация ошибочна. Если ваша система имеет достаточную сложность, что желательно что-то отличное от C, то будут части системы, которые должны быть "достаточно быстрыми", и части с более легкими ограничениями. Если при написании вашего кода, например, на Python, проект будет завершен быстрее, с меньшим количеством ошибок, то вы можете использовать код C или ассемблера, чтобы ускорить критичные по времени детали.
Даже если окажется, что весь код должен быть написан на C или сборке, чтобы соответствовать требованиям к производительности, создание прототипов на языке, подобном Python, может принести реальные преимущества. Вы можете взять свой рабочий прототип Python и постепенно заменять части кодом C, пока не достигнете необходимой производительности.
Итак, используйте инструменты, которые позволят вам выполнить работу по разработке наиболее правильно и максимально быстро, а затем используйте реальные данные, чтобы определить, где вам нужно оптимизировать. Может случиться так, что C - самый подходящий инструмент для начала, но, конечно, не всегда, даже во встроенных системах.
По моему опыту, использование C для встроенного и системного программирования не обязательно является проблемой производительности - это часто проблема переносимости. C, как правило, является наиболее переносимым, хорошо поддерживаемым языком практически на любой платформе, особенно на платформах встраиваемых систем.
Если вы хотите использовать что-то другое во встроенной системе, часто нужно выяснить, какие варианты доступны, а затем определить, достаточно ли хороши производительность, потребление памяти, поддержка библиотек и т. Д. Для вашей ситуации.
Использование C для встроенных систем имеет несколько очень веских причин, из которых "производительность" является лишь одной из второстепенных. Встроенный очень близко к аппаратному обеспечению, вам нужно ручное обращение к памяти для связи с аппаратным обеспечением. Все API и SDK доступны в основном для языка Си.
Существует только несколько платформ, которые могут работать с виртуальной машиной для Java или Mono, что частично связано с влиянием на производительность, а также с дорогостоящими затратами на внедрение.
Помимо производительности, есть еще одно соображение: вы, скорее всего, будете иметь дело с низкоуровневыми API, которые были разработаны для использования в C или C++.
Если вы не можете использовать какой-либо SDK, вы только столкнетесь с проблемами, а не сэкономите время на разработке с использованием языка более высокого уровня. По крайней мере, вы в конечном итоге переделаете кучу объявлений функций и постоянных определений.
Для C:
- C часто является единственным языком, который поддерживается компиляторами для процессоров.
- Большинство библиотек и пример кода также есть вероятность на C.
- Большинство разработчиков встраиваемых систем имеют многолетний опыт работы с Си, но совсем немного опыта.
- Позволяет прямой аппаратный интерфейс и ручное управление памятью.
- Простая интеграция с языком ассемблера.
C собирается быть вокруг в течение многих лет. Во встроенной разработке это монополия, которая подавляет любые попытки изменений. Язык, которому нужна виртуальная машина, такая как Java или Lua, никогда не станет мейнстримом во встроенной среде. Скомпилированный язык может иметь шанс, если он предоставляет новые привлекательные возможности по сравнению с C.
В Интернете существует несколько тестов для разных языков. В большинстве из них вы найдете реализацию на C или C++, так как они дают вам больше возможностей для реальной оптимизации.
Пример: игра "Тесты компьютерного языка".
Трудно поспорить против C (или других процедурных языков, таких как Pascal, Modula-2, Ada) и ассемблера для встраиваемых. Существует большая история успеха с этими языками. Как правило, вы хотите устранить риск неизвестного. Попытка использовать что-либо кроме C или сборки, на мой взгляд, неизвестно. Сказав это, нет ничего плохого в смешанной модели, в которой вы используете одну из схем, которые идут на C, или Python, Lua или JavaScript в качестве языка сценариев.
То, что вы хотите, это возможность быстро и легко перейти к C, когда вам нужно.
Если вы убедите команду пойти с чем-то, что им не доказано, проект - это ваш файл cookie. Если он рухнет, скорее всего, это будет ваша вина.
Ada - это язык программирования высокого уровня, разработанный для встраиваемых и критически важных систем.
Это быстрый безопасный язык, в который встроена проверка данных. Это то, на что запрограммированы автопилоты в самолетах.
По этой ссылке у вас есть сравнение между Ада и C.
Эта статья (Майкл Барр) рассказывает об использовании C, C++, ассемблера и других языков во встроенных системах, и включает в себя график, показывающий относительное использование каждого из них.
А вот еще одна статья под соответствующим названием " Бедные причины отказа от C++".
Есть ситуации, когда вам нужна производительность в реальном времени, особенно во встроенных системах. У вас также есть серьезные ограничения памяти. Такой язык, как C, дает вам больший контроль над временем выполнения и пространством выполнения.
Таким образом, в зависимости от того, что вы делаете, С вполне может быть "лучше" или более подходящим.
Проверьте следующие статьи
C вездесущ, доступен практически для любой архитектуры, обычно с первого дня доступности процессора. С ++ - второе место. Если ваша система может поддерживать C++ и у вас есть необходимый опыт, используйте его вместо C - это все, чем является C, и более того, поэтому есть несколько причин, по которым он не используется.
C++ является более крупным языком, и существуют поддерживаемые конструкции и методы, которые могут потреблять ресурсы или вести себя неприемлемым образом во встроенной системе, но это не причина для использования языка, а скорее для его правильного использования.
Java и C# (на Micro.Net или WinCE) могут быть жизнеспособными альтернативами не в режиме реального времени.
Возможно, вы захотите взглянуть на язык программирования D. Он может использовать некоторую настройку производительности, так как есть некоторые области, в которых Python может превзойти его. Я не могу на самом деле указать вам на сравнение сравнений, так как не вел список, но, как указал Питер Олссон, " Тесты и языковые реализации" имеют D Digital Mars.
Вы, вероятно, также захотите взглянуть на эти прекрасные вопросы:
Я на самом деле не системный / встроенный программист, но мне кажется, что встроенным программам, как правило, нужна детерминированная производительность - это сразу исключает многие языки с сборкой мусора, потому что они не являются детерминированными в целом. Однако была проведена работа по детерминированной сборке мусора (например, Metronome for Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html).
Проблема заключается в одном из ограничений - соответствуют ли языки / среды выполнения детерминистическим требованиям, использованию памяти и т. Д.
С действительно ваш лучший выбор.
Существует разница в написании переносимого кода на C и в слишком глубоком понимании особенностей ghee whiz конкретного компилятора или угловых случаев языка (всего этого следует избегать). Но переносимость между компиляторами и версиями компилятора. Количество сотрудников, которые смогут разрабатывать или поддерживать код. Компиляторам будет легче с ним работать, и они будут создавать более качественный, чистый и надежный код.
C is not going anywhere, with all the new languages being designed to fix the flaws in all the prior languages. C, with all the flaws these new languages are trying to fix, still stands strong.
Несколько человек упомянули Луа. Мои знакомые, которые работали со встроенными системами, сказали, что Lua полезен, но на самом деле это не собственный язык, а скорее библиотека, которая может быть встроена в C. Она предназначена для использования во встроенных системах, и, как правило, вы захотите вызывать Lua-код из C. Но чистый C упрощает (хотя и не обязательно облегчает) обслуживание, поскольку все это знают.
Вот пара статей, в которых сравниваются C# и C++:
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 или C++ могут быть явным победителем с точки зрения производительности во многих случаях. Но часто разницы невелики. Использовать ли C или нет - это совсем другая тема. На мой взгляд, это действительно должно зависеть от поставленной задачи. Но во встроенных системах у вас часто нет большого выбора.
В зависимости от встроенной платформы, если ограничения памяти являются проблемой, вам, скорее всего, придется использовать язык программирования без сбора мусора.
C в этом отношении, вероятно, является наиболее известным в команде и наиболее широко поддерживаемым из доступных библиотек и инструментов.
Правда есть - не всегда.
Кажется, что среда выполнения.NET (но любая другая среда выполнения может быть взята в качестве примера) накладывает несколько МБ времени выполнения. Если это все, что у вас есть (в оперативной памяти), то вам не повезло. JavaME кажется более компактным, но все же все зависит от имеющихся у вас ресурсов.
Компиляторы C работают намного быстрее даже в настольных системах из-за того, что по сравнению с C++ функции языка не сравнятся, поэтому я могу представить, что на встроенных системах разница нетривиальна. Это приводит к сокращению времени итерации, хотя в OTOH у вас нет таких возможностей C++ (как коллекции), которые могут замедлить работу в долгосрочной перспективе.