Python в операционной системе реального времени (RTOS)
Я планирую внедрить мелкомасштабную систему сбора данных на платформе RTOS. (Либо на QNX, либо в системе RT-Linux.)
насколько я знаю, эти задания выполняются с использованием C / C++, чтобы получить максимальную отдачу от системы. Однако мне интересно знать и хочу узнать мнения некоторых опытных людей, прежде чем я слепо прыгну в действие кодирования, было бы целесообразно и мудрее написать все на Python (от низкоуровневого инструмента, взаимодействующего через блестящий графический пользовательский интерфейс.) Если нет, смешайте с критическими по времени частями дизайна с "C" или напишите все на C и даже не Поставьте строку кода Python.
или, по крайней мере, обертывание кода C с помощью Python для обеспечения более легкого доступа к системе.
в какую сторону вы посоветовали бы мне работать? Я был бы рад, если бы вы указали некоторые аналогичные случаи дизайна и дальнейшие чтения.
спасибо
Примечание 1: причиной акцент на QNX обусловлен тем, что у нас уже есть система сбора данных на основе QNX 4.25 (M300) для наших экспериментов по атмосферным измерениям. Это проприетарная система, и мы не можем получить доступ к ее внутренностям. Глядя дальше на QNX может быть выгодно для нас, так как 6.4 имеет бесплатный вариант академического лицензирования, поставляется с Python 2.5 и недавней версией GCC. Я никогда не тестировал систему RT-Linux, не знаю, насколько она сопоставима с QNX с точки зрения стабильности и эффективности, но я знаю что все члены Python habitat и не-Python tools (например, Google Earth), что новая система может быть разработана на работает большую часть времени из коробки.
5 ответов
Я не могу говорить за каждый настройка сбора данных там, но большинство из них проводят большую часть своего "реального времени" ожидание для данных, чтобы войти-по крайней мере, те, над которыми я работал.
тогда, когда данные тут войдите, вам нужно немедленно записать событие или ответить на него, а затем вернуться к ожидающей игре. Это, как правило, наиболее важной частью системы сбора данных. Для этого причина, я бы вообще скажем, придерживайтесь C для частей ввода-вывода сбора данных, но нет никаких особенно убедительных причин не использовать Python на некритических частях.
Если у вас есть довольно свободные требования-нужна только миллисекундная точность, возможно, - это добавляет еще немного веса, чтобы делать все в Python. Что касается времени разработки, если вам уже комфортно с Python, у вас, вероятно, будет готовый продукт значительно раньше, если вы должны были делать все в Python и рефакторинг только по мере появления узких мест. Выполнение основной части вашей работы в Python также облегчит тщательную проверку вашего кода, и, как правило, будет меньше строк кода и, следовательно, меньше места для ошибок.
Если вам нужно специально multi -задание (не Multi-нить),Stackless Python может быть полезным. Это как многопоточность, но потоки (или tasklets, в Stackless lingo) не являются потоками уровня ОС, а Python/application-level, поэтому накладные расходы на переключение между tasklets значительно снижается. Вы можете настроить Stackless на многозадачность совместно или упреждающе. Самый большой недостаток заключается в том, что блокирование ввода-вывода обычно блокирует весь набор задач. В любом случае, учитывая, что QNX уже является системой реального времени, трудно предположить, будет ли Stackless стоить с помощью.
Я бы проголосовал за то, чтобы взять как можно более-Python-возможный маршрут-я вижу его как низкую стоимость и высокую выгоду. Если и когда вам нужно переписать на C, у вас уже будет рабочий код для начала.
Я построил несколько все-Python soft real-time (RT) систем, С временами основного цикла от 1 мс до 1 секунды. Есть некоторые основные стратегии и тактики, которые я узнал по пути:
использовать многопоточность/многопроцессорность только для разгрузки не-RT работы из основного потока, где очереди между потоками приемлемы и возможна совместная резьба (нет упреждающих потоков!).
избегайте GIL. Что в основном означает не только избегать потоков, но и избегать системных вызовов в максимально возможной степени, особенно во время критически важных операций, если они не являются неблокирующими.
используйте модули C, когда это практично. Вещи (обычно) идут быстрее С C! Но в основном, если вам не нужно писать свои собственные: оставайтесь в Python, если на самом деле нет альтернативы. Оптимизация производительности модуля C - это Пита, особенно при переводе через интерфейс Python-C становится самой дорогой частью кода.
используйте ускорители Python для ускорения кода. Мой первый проект RT Python значительно выиграл от Psyco (да, я делаю это некоторое время). Одна из причин, по которой я остаюсь с Python 2.x сегодня это PyPy: Things всегда быстрее с LLVM!
Не бойтесь занят-подождите, когда это необходимо время. Использование времени.sleep (), чтобы "подкрасться" в нужное время, затем занят-ожидание в течение последних 1-10 МС. Я смог получить повторяемую производительность с самосинхронизацией порядка 10 микросекунд. Убедитесь,что ваша задача Python выполняется с максимальным приоритетом ОС.
Numpy ROCKS! Если вы делаете "живую" аналитику или тонны статистики, есть нет способ получить больше работы быстрее и с меньшим количеством работы (меньше кода, меньше ошибок), чем с помощью Numpy. Не на любом другом языке, который я знаю, включая C / C++. Если большинство вашего кода состоит из Numpy вызовов, вы будете очень, очень быстро. Я не могу дождаться завершения порта Numpy для PyPy!
имейте в виду, как и когда Python делает сборку мусора. Контролируйте использование памяти и при необходимости заставляйте GC. Обязательно явно отключите GC во время критических по времени операций. Все мои системы RT Python работают непрерывно, и Python любит свинью память. Тщательное кодирование может устранить почти все динамические выделения памяти, и в этом случае вы можете полностью отключить GC!
попробуйте выполнить обработку пакетами в максимально возможной степени. Вместо обработки данных со скоростью ввода попробуйте обработать данные со скоростью вывода, которая часто намного медленнее. Обработка в партиях также делает его более удобным для сбора статистики более высокого уровня.
Я упоминал об использовании PyPy? Ну, это стоит упомянуть дважды.
есть много других преимуществ в использовании Python для разработки RT. Например, даже если вы уверены, что ваш целевой язык не может быть Python, он может заплатить огромные преимущества для разработки и отладки прототипа в Python, а затем использовать его как шаблон и инструмент тестирования для окончательной системы. Я использовал Python для создания быстрых прототипов "жестких частей" системы в течение многих лет и для создания быстрых тестовых GUIs. Вот как появилась моя первая система RT Python: прототип (+Psyco) был достаточно быстрым, даже с тестом GUI работает!
-BobC
Edit: забыл упомянуть кросс-платформенные преимущества: мой код работает практически везде с a) без перекомпиляции (или зависимостей компилятора, или необходимости кросс-компиляторов), и b) почти без зависящего от платформы кода (в основном для разных вещей, таких как обработка файлов и последовательный ввод-вывод). Я могу разрабатывать на Win7-x86 и развертывать на Linux-ARM (или любой другой ОС POSIX, все из которых имеют Python в эти дни). PyPy в первую очередь x86 на данный момент, но порт ARM развивается с невероятной скоростью.
Обычно причиной, выдвинутой против использования языка высокого уровня в контексте реального времени, является неопределенность -- когда вы запускаете процедуру один раз, это может занять 100us; в следующий раз, когда вы запускаете ту же самую процедуру, она может решить расширить хэш-таблицу, вызвав malloc, затем malloc запрашивает у ядра больше памяти, которая может сделать что угодно от мгновенного возврата к возврату миллисекунд позже к возврату секунд позже erroring, но не сразу очевидно (или управляемо) из кода. Тогда как теоретически, если вы пишете в C (или даже ниже), вы можете доказать, что ваши критические пути будут "всегда" (за исключением удара метеора) работать в X раз.
наша команда проделала некоторую работу, объединив несколько языков на QNX и имела довольно большой успех с подходом. Использование python может оказать большое влияние на производительность и такие инструменты, как глоток и ctypes делают его действительно легким оптимизировать код и совместить характеристики от различных языков.
однако, если вы пишете что-нибудь критическое по времени, это почти наверняка должно быть написано на c. Это означает, что вы избегаете неявных затрат интерпретируемого langauge как Гил (Глобальная Блокировка Интерпретатора), и утверждение на многих небольших выделениях памяти. Обе эти вещи могут иметь большое влияние на то, как ваше приложение выполняет.
также python на QNX, как правило, не совместим на 100% с другими дистрибутивами (т. е. иногда отсутствуют модули).
одно важное примечание: Python для QNX обычно доступен только для x86.
Я уверен, что вы можете скомпилировать его для ppc и других archs, но это не сработает из коробки.