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

Question

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

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

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

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

Спасибо

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

6. Numpy ROCKS! Если вы делаете «живую» аналитику или массу статистических данных, существует NO способ получить больше работы быстрее и с меньшими затратами (меньше кода, меньше ошибок), чем с помощью Numpy. Не на любом другом языке, о котором я знаю, включая C/C++. Если большинство вашего кода состоит из вызовов Numpy, вы будете очень быстрыми. Я не могу дождаться, когда порт Numpy в PyPy будет завершен!

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

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

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

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

-BobC

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