Мы должны использовать C “по причинам производительности”, [закрытым]
ref говорит компилятору, что объект инициализируется прежде, чем ввести функцию, в то время как out говорит компилятору, что объект будет инициализирован в функции.
Поэтому, в то время как ref два пути, out, является единственным.
18 ответов
"Nothing but C is fast [enough]" is an early optimisation and wrong for all the reasons that early optimisations are wrong. If your system has enough complexity that something other than C is desirable, then there will be parts of the system that must be "fast enough" and parts with lighter constraints. If writing your code, for example, in Python will get the project finished faster, with fewer bugs, then you can follow up with some C or assembly code to speed up the time-critical parts.
Even if it turns out that the entire code must be written in C or assembly to meet the performance requirements, prototyping in a language like Python can have real benefits. You can take your working Python prototype and gradually replace parts with C code until you reach the necessary performance.
So, use the tools that let you get the development work done most correctly and most quickly, then use real data to determine where you need to optimize. It could be that C is the most appropriate tool to start with sometimes, but certainly not always, even in embedded systems.
На самом деле - не всегда.
Кажется, что среда выполнения .NET (но в качестве примера можно взять любую другую среду выполнения) накладывает несколько МБ накладных расходов во время выполнения. Если это все, что у вас есть (в ОЗУ), то вам не повезло. JavaME кажется более компактным, но все зависит от имеющихся у вас ресурсов.
В зависимости от встроенной платформы, если проблемы с памятью являются проблемой, вам, скорее всего, придется использовать язык программирования без сборщика мусора.
C в этом отношении, вероятно, наиболее известен командой и наиболее широко поддерживается доступными библиотеками и инструментами.
Бывают ситуации, когда требуется производительность в реальном времени, особенно во встроенных системах. У вас также есть серьезные ограничения памяти. Такой язык, как C, дает вам больший контроль над временем выполнения и пространством выполнения.
Итак, в зависимости от того, что вы делаете, C вполне может быть «лучше» или более подходящим.
Ознакомьтесь со следующими статьями
В Интернете есть несколько тестов для разных языков. Большинство из них вы найдете наверху реализации на C или C ++, так как они дают вам больше возможностей для реальной оптимизации.
Пример: The Computer Language Benchmarks Game .
Я на самом деле не системный / встроенный программист, но мне кажется, что встроенным программам обычно требуется детерминированная производительность - это сразу исключает многие языки со сборкой мусора, потому что они не детерминированный в целом. Однако была работа над детерминированной сборкой мусора (например, Metronome для Java: http://www.ibm.com/developerworks/java/library/j-rtj4/index.html )
Проблема заключается в одном из ограничений - соответствуют ли языки / среды выполнения детерминированным требованиям, требованиям к использованию памяти и т. Д.
Трудно спорить с C (или другими языками процедур, такими как Pascal, Modula-2, Ada) и сборкой для встраиваемых систем. Эти языки имеют большой успех. Как правило, вы хотите устранить риск неизвестности. Пытаться использовать что-либо кроме C или сборки, на мой взгляд, неизвестно. Сказав это, нет ничего плохого в смешанной модели, в которой вы используете одну из схем, которые переходят на C, или Python, или Lua, или JavaScript в качестве языка сценариев.
Что вам нужно, так это возможность быстро и легко перейти на C когда вам нужно.
Если вы убедите команду пойти с чем-то, что для них не доказано, проект станет вашим файлом cookie. Если он рухнет, скорее всего, это будет ваша вина.
Вот пара статьи, сравнивающие 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 или нет - это отдельная тема. На мой взгляд, это действительно должно зависеть от поставленной задачи. Но во встроенных системах у вас часто не так много выбора.
Помимо производительности, есть еще одно соображение: вы, скорее всего, будете иметь дело с низкоуровневыми API, которые были разработаны для использования в C или C ++ .
Если вы не можете использовать какой-либо SDK, вы только столкнетесь с проблемами вместо того, чтобы сэкономить время на разработке с использованием языка более высокого уровня. По крайней мере, вам придется переделывать кучу объявлений функций и определений констант.
Ada - это язык программирования высокого уровня, разработанный для встраиваемых систем и критически важных систем.
Это быстрый безопасный язык, в который встроена проверка данных повсюду. Это то, во что запрограммированы автопилоты в самолетах.
На по этой ссылке у вас есть сравнение между Ada и C.
Использование C для встроенных систем имеет несколько очень веских причин, из которых «перформанс» - лишь одно из второстепенных. Встроенный очень близок к железу, вам требуется ручной адрес памяти для связи с оборудованием. Все API и SDK доступны в основном для C.
Есть только несколько платформ, которые могут запускать виртуальную машину для Java или Mono, что частично связано с последствиями для производительности, но также и из-за дорогостоящих затрат на реализацию.
По моему опыту, использование C для встраиваемого и системного программирования не обязательно является проблемой производительности - часто это проблема переносимости. C, как правило, является наиболее портативным и хорошо поддерживаемым языком практически на всех платформах, особенно на платформах встроенных систем.
Если вы хотите использовать что-то еще во встроенной системе, часто нужно выяснить, какие варианты доступны, затем определить, являются ли производительность, потребление памяти, поддержка библиотек и т. д. "достаточно хорошими" для вашей ситуации.
Несколько человек упомянули Lua. Люди, которых я знаю, которые работали со встроенными системами, сказали, что Lua полезен, но на самом деле это не отдельный язык как таковой, а скорее библиотека, которую можно встроить в C.Он ориентирован на использование во встроенных системах, и, как правило, вы захотите для вызова кода Lua из C. Но чистый C упрощает (хотя и не обязательно упрощает) обслуживание, поскольку все это знают.
Эта статья (Майкла Барра) рассказывает об использовании C, C ++, ассемблера и других языков во встроенных системах и включает график, показывающий относительное использование каждого из них.
А вот еще одна статья с подходящим названием Плохо. причины отказа от C ++ .
Вы можете посмотреть на язык программирования D . Для этого может потребоваться некоторая настройка производительности, поскольку в некоторых областях Python может превзойти его. Я не могу указать вам на сравнительные тесты, так как не веду список, но, как указал Питер Олссон, Benchmarks & Language Implementations имеет D Digital Mars.
Вы, вероятно, также захотите чтобы посмотреть на эти прекрасные вопросы:
C действительно ваш лучший выбор.
Существует разница в написании переносимого кода на C и в том, чтобы слишком глубоко погрузиться в особенности гхи-викинга конкретного компилятора или угловых случаев языка (всего чего следует избегать). Но переносимость между компиляторами и версиями компиляторов. Количество сотрудников, которые смогут разрабатывать или поддерживать код. Компиляторам будет легче работать с ним, и они будут создавать лучший, чистый и надежный код.
Си никуда не денется, поскольку все новые языки разрабатываются для исправления недостатков всех предыдущих языков. C со всеми недостатками, которые пытаются исправить эти новые языки, по-прежнему остается сильным.
Для C:
- C часто является единственным языком, который поддерживается компиляторами для процессоров.
- Большинство библиотек и примеров кода также представлены в C.
- Большинство разработчиков встраиваемых систем имеют многолетний опыт работы с C, но очень мало опыта в чем-либо еще.
- Позволяет прямое аппаратное взаимодействие и ручное управление памятью.
- Простая интеграция с языком ассемблера.
C будет использоваться в течение многих лет. приходить. Во встроенной разработке - это монополия, которая подавляет любые попытки изменений. Язык, которому нужна виртуальная машина, такой как Java или Lua, никогда не станет популярным во встроенной среде. Скомпилированный язык может иметь шанс, если он предоставит новые привлекательные функции по сравнению с C.
C широко распространен, доступен практически для любой архитектуры, обычно с первого дня доступности процессора. На втором месте С ++. Если ваша система может поддерживать C ++ и у вас есть необходимый опыт, используйте его вместо C - это все, что есть C, и многое другое, поэтому есть несколько причин не использовать его.
C ++ - более крупный язык, и поддерживаются конструкции и методы, которые могут потреблять ресурсы или вести себя неприемлемым образом во встроенной системе, но это не причина не использовать язык, а, скорее, как использовать его надлежащим образом.
Java и C # (на Micro. Net или WinCE) могут быть жизнеспособными альтернативами не в реальном времени.