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

Question

В этом возрасте многих языков, кажется, отличный язык практически для каждой задачи, и я считаю себя профессионально борющимся против мантры «ничего, кроме С быстро », где скорость действительно означает« достаточно быстро ». Я работаю с очень рациональными людьми с открытым сердцем, которые любят сравнивать цифры, и все, что у меня есть, - это мысли и мнения. Не могли бы вы помочь мне найти мой путь мимо субъективных мнений и в «реальном мире»?

Не могли бы вы помочь мне найти исследование относительно того, что, если любые другие языки могут использоваться для программирования встроенных и (Linux) систем? Я очень хорошо мог выдвигать ложную гипотезу и очень оценил бы исследования, чтобы показать мне это. Не могли бы вы указать ссылки или включить хорошие номера, чтобы свести к минимуму комментарии «это только его мнение».

---

Так это мои особые требования

• памяти не является серьезным сдерживающим фактором
• портативность не является серьезной проблемой
• это не система реального времени

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

Бывают ситуации, когда вам требуется производительность в реальном времени, особенно во встроенных системах. У вас также есть серьезные ограничения памяти. Язык, подобный 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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

Вот несколько статей, которые сравнивают 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 или нет - это совсем другая тема. По-моему, это действительно должно зависеть от поставленной задачи. Но во встроенных системах у вас часто нет большого выбора.

Answer 10

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

Пример: The Computer Language Benchmarks Game.

Answer 11

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

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

В this link у вас есть сравнение между Ada и С.

Answer 12

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

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

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

Answer 13

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

Answer 14

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

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

• Getting Embedded with D (the programming language)
• How would you approach using D in a embedded real-time environment?

Answer 15

Для C:

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

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

Answer 16

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

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

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

Answer 17

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

И вот еще одна статья, под заглавием, Poor reasons for rejecting C++.

Answer 18

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

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

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

Answer 19

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

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

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

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

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

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

Answer 20

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

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