Python в операционной системе реального времени (ОСРВ)

Question

Я планирую внедрить небольшую систему сбора данных на платформе 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-среды обитания и не-Python-инструментов (например, Google Earth), что новая система может разрабатываться на работах большую часть времени из коробки.

Answer 1

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

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

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

3. Используйте модули С, когда это возможно. Вещи (обычно) идут быстрее с 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 для создания быстрых прототипов «твердых частей» системы в течение многих лет и для создания быстрых и грязных тестовых графических интерфейсов. Так появилась моя первая система RT Python: прототип (+ Psyco) был достаточно быстрым, даже при работающем тестовом графическом интерфейсе!

-BobC

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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