Python в операционной системе реального времени (RTOS)

Я планирую внедрить небольшую систему сбора данных на платформе RTOS. (Либо в системе QNX, либо в RT-Linux.)

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

Или, по крайней мере, обернуть код C с помощью Python, чтобы обеспечить более легкий доступ к системе.

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

Спасибо

ПРИМЕЧАНИЕ 1: Причина подчеркивания в QNX заключается в том, что у нас уже есть система сбора данных на основе QNX 4.25 (M300) для наших экспериментов по атмосферному измерению. Это проприетарная система, и мы не можем получить доступ к ее внутренним компонентам. Если смотреть дальше на QNX, это может быть выгодно для нас, поскольку у 6.4 есть бесплатный вариант академического лицензирования, поставляется с Python 2.5 и недавняя версия GCC. Я никогда не тестировал систему RT-Linux, не знаю, насколько это сопоставимо с QNX с точки зрения стабильности и эффективности, но я знаю, что все члены среды обитания Python и не-Python (например, Google Earth), что новая система могут быть разработаны на работах большую часть времени из коробки.

ОТВЕТЫ

Ответ 1

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

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

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

Если вам нужна определенная многозадачность (не многопотоковая), Stackless Python может быть полезен. Это похоже на многопоточность, но потоки (или таскеты в Stackless lingo) не являются потоками уровня ОС, а Python/application-level, поэтому накладные расходы на переключение между тасками значительно снижаются. Вы можете настроить Stackless для многозадачности совместно или превентивно. Самый большой недостаток заключается в том, что блокировка IO, как правило, блокирует весь набор талисманов. В любом случае, учитывая, что QNX уже является системой реального времени, трудно предположить, можно ли использовать Stackless.

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

Ответ 2

Я создал несколько полностью-Python программных систем реального времени (RT) с периодом первичного цикла от 1 мс до 1 секунды. Есть несколько основных стратегий и тактик, которые я изучил на этом пути:

  • Использовать многопоточность/многопроцессорность только, чтобы отключить работу без RT от основного потока, где возможны очереди между потоками и возможна совместная потоковая передача (без превентивных потоков!).

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

  • Используйте C-модули, когда это возможно. Вещи (обычно) идут быстрее с помощью C! Но в основном, если вам не нужно писать самостоятельно: оставайтесь на Python, если нет альтернативы. Оптимизация производительности модуля C - это PITA, особенно когда перевод через интерфейс Python-C становится самой дорогой частью кода.

  • Используйте ускорители Python для ускорения вашего кода. Мой первый проект RT Python очень помог Psyco (да, я делал это некоторое время). Одной из причин, по которым я остаюсь с Python 2.x сегодня, является PyPy: Вещи всегда идут быстрее с LLVM!

  • Не бойтесь оживленного ожидания, когда требуется критическое время. Используйте time.sleep(), чтобы "подкрасться" в нужное время, а затем "ожидание" в течение последних 1-10 мс. Я смог получить повторяющуюся производительность с самосинхронизацией порядка 10 микросекунд. Убедитесь, что ваша задача Python выполняется с максимальным приоритетом ОС.

  • НОМЕРНЫЕ РОКИ! Если вы делаете "живую" аналитику или массу статистики, нет НИКАКОГО способа получить больше работы быстрее и с меньшим количеством работы (меньше кода, меньше ошибок), чем с помощью Numpy. Не на любом другом языке, о котором я знаю, включая C/С++. Если большинство вашего кода состоит из вызовов Numpy, вы будете очень быстрыми. Я не могу дождаться завершения работы порта Numpy в PyPy!

  • Помните, как и когда Python выполняет сборку мусора. Контролируйте использование памяти и при необходимости используйте GC. Обязательно отключите GC во время критических операций. Все мои системы RT Python работают непрерывно, а Python любит вести память. Тщательное кодирование может устранить почти все динамическое распределение памяти, и в этом случае вы можете полностью отключить GC!

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

  • Я упоминал использование PyPy? Ну, это стоит упомянуть дважды.

Существует много других преимуществ использования Python для разработки RT. Например, даже если вы достаточно уверены, что ваш целевой язык не может быть Python, он может принести огромные выгоды для разработки и отладки прототипа в Python, а затем использовать его как шаблон и средство тестирования для окончательной системы. Я использовал Python для создания быстрых прототипов "жестких частей" системы в течение многих лет и создания быстрых тестов GUI. Так появилась моя первая система RT Python: прототип (+ Psyco) был достаточно быстрым, даже при запущенном тестовом графическом интерфейсе!

-BobC

Изменить: Забыл упомянуть преимущества кросс-платформы: мой код работает практически везде: a) нет перекомпиляции (или зависимостей компилятора или необходимости для кросс-компиляторов) и b) почти не зависящего от платформы кода (в основном для такие как обработка файлов и последовательный ввод-вывод). Я могу разработать на Win7-x86 и развернуть на Linux-ARM (или любой другой ОС POSIX, все из которых имеют Python в эти дни). PyPy - это в первую очередь x86, но порт ARM развивается невероятно быстро.

Ответ 3

Как правило, причина, связанная с использованием языка высокого уровня в реальном времени, - неопределенность - когда вы запускаете рутину один раз, это может занять 100us; в следующий раз, когда вы запустите ту же процедуру, он может решить расширить хэш-таблицу, вызвав malloc, а затем malloc запросит ядро ​​для большей памяти, что может что-то сделать, от немедленного возврата к возврату миллисекунд позже, к возврату секунд спустя к ошибке, ни одна из которых немедленно (или контролируема) из кода. Если теоретически, если вы пишете на C (или даже ниже), вы можете доказать, что ваши критические пути будут "всегда" (запрещающие метеоритный удар) работать в X раз.

Ответ 4

Наша команда проделала определенную работу по объединению нескольких языков в QNX и имела довольно большой успех в этом подходе. Использование python может иметь большое влияние на производительность, а такие инструменты, как SWIG, а ctypes действительно упрощают оптимизацию кода и объединяют функции из разные языки.

Однако, если вы пишете что-нибудь критичное, это почти наверняка будет написано в c. Это означает, что вы избегаете неявных затрат интерпретируемого langauge, такого как GIL (Global Interpreter Lock) и конкуренция во многих небольших выделениях памяти. Обе эти вещи могут иметь большое влияние на то, как работает ваше приложение.

Также python на QNX не должен быть на 100% совместим с другими дистрибутивами (т.е./иногда отсутствуют модули).

Ответ 5

Одно важное замечание: Python для QNX обычно доступен только для x86.

Я уверен, что вы можете скомпилировать его для ppc и других арков, но это не будет работать из коробки.