Недавно в одном из обсуждений эффективности и применимости ЯВУ в коде ядра ОС затрагивался вопрос о том, насколько сложно реализовать поддержку в ядре того же питона. Я тогда написал, что технически препятствий никаких, но тогда неизбежно появится профессия "писатель драйверов на питоне", и большинство драйверов станет еще ужаснее, чем они есть сейчас.
И вот вчера один из потенциальных клиентов, тестируя мой "тонкий звуковой интерфейс" (драйвер виртуального звукового устройства, где функции аппаратного контроллера выполняет виндовое приложение), спросил, нет ли там ограничений на применение питона. Посетовал, что пытался писать на питоне APO (программные модули обработки звука для системного звукового движка), но обломался, так как у движка достаточно жесткие ограничения на структуру и поведение DLL, в которые оформляются APO.
При таких тенденциях, боюсь, таки дойдет и до драйверов ядра на питоне. Не знаю даже, смеяться тут, или сразу плакать.
Re: Применимость питона в критичном по времени коде
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>При таких тенденциях, боюсь, таки дойдет и до драйверов ядра на питоне. Не знаю даже, смеяться тут, или сразу плакать.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>При таких тенденциях, боюсь, таки дойдет и до драйверов ядра на питоне. Не знаю даже, смеяться тут, или сразу плакать.
Видел драйвер на шарпе. Код, кстати, получше, чем то, которое обычно вижу на плюсах. А пользователи разницы в работе не ощущают.
Re: Применимость питона в критичном по времени коде
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>большинство драйверов станет еще ужаснее, чем они есть сейчас.
А в чем ужасность написанных сейчас драйверов? Особо не вглядывался, но вроде работают стабильно, система не вылетает в BSODы, тот же звук не отваливается.
Re[2]: Применимость питона в критичном по времени коде
Здравствуйте, m2user, Вы писали:
A>>Видел драйвер на шарпе. Код, кстати, получше, чем то, которое обычно вижу на плюсах. А пользователи разницы в работе не ощущают.
M>Подо что можно писать драйвера на C#?
Та компания тогда писала под мобильный и десктопный Windows, так что, надо полагать, под одну из них.
Технических деталей я не знаю.
Re: Применимость питона в критичном по времени коде
Здравствуйте, opfor, Вы писали:
O>А в чем ужасность написанных сейчас драйверов?
Многие огромны (по сравнению с функциональностью), с весьма мутной структурой. Ну и нередко кладут болт на системные требования по длительности удержания блокировок, повышения приоритетов, использования ресурсов и т.п.
Re[3]: Применимость питона в критичном по времени коде
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Видел драйвер на шарпе.
ЕМ>Ядра, или user-mode?
Я очень далёк от написания драйверов, и даже не интересовался. Для сравнения, коллега писал проект на плюсах, когда я глянул его код, то увидел некоторые характерные особенности в виде своих обёрток над примерно всем (в т.ч. классы File и Port), но подо что он собирал, с каким SDK — понятия не имею.
После вопроса выше я стал читать и узнал, что kernel-драйвера на шарпе не поддерживаются, а для user-mode есть какой-то четырёхбуквенный проект, который действует с Висты. Может, это был он. А может, меня просто разыграли.
Я, наверно, просто заберу назад сделанное утверждение, потому что засомневался.
Re[4]: Применимость питона в критичном по времени коде
Здравствуйте, Alekzander, Вы писали:
A>узнал, что kernel-драйвера на шарпе не поддерживаются, а для user-mode есть какой-то четырёхбуквенный проект, который действует с Висты.
Под user mode чаще всего можно писать вообще на чем угодно. Там ограничения обычно чисто косметические — из службы нельзя напрямую использовать гуй, да нужна аккуратность с параллелизмом (любой драйвер всегда вызывается асихронно из разных потоков).
В ядре все гораздо более сурово. Хотя вот винда поддерживает в ядре полноценную структурированую обработку исключений (SEH), которая там в полный рост используется и из C, и из C++, а поддержку плюсовых исключений там не делают лишь потому, чтоб не набежало дилетантов, не умеющих использовать плюсы без исключений. Но ведь таки сделают однажды, все к тому идет.
Re: Применимость питона в критичном по времени коде
ЕМ>При таких тенденциях, боюсь, таки дойдет и до драйверов ядра на питоне. Не знаю даже, смеяться тут, или сразу плакать.
Учитывая последние функциональные тренды в Питоне, то комплиментарным языком к нему становится Rust. Т.е. переход с питона на Rust для толковых питонистов будет не таким уж и сложным делом. А как выше уже упомянули, драйвера на Rust вполне себе можно писать.
Re[3]: Применимость питона в критичном по времени коде
Здравствуйте, m2user, Вы писали:
A>>Видел драйвер на шарпе. Код, кстати, получше, чем то, которое обычно вижу на плюсах. А пользователи разницы в работе не ощущают.
M>Подо что можно писать драйвера на C#?
У шарпа есть опция Native AOT, который переводит Il код в С++ с использованием сборщика мусора.
Если использовать только ref структуры, то и нагрузка на GC будет минимальна.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, MaximVK, Вы писали:
MVK>драйвера на Rust вполне себе можно писать.
Я ж говорю, что "писать драйвера" технически (чтоб обслуживаемое устройство хоть как-то работало) можно на любом языке, хоть на бейсике. А вот как нужно, чтоб устройство работало быстро и без внезапных задержек — начинаются вопросы. В таких случаях, конечно, можно поставить в устройство достаточно мощный процессор, поднять на нем линукс (это уже давно делается массово), и написать встроенный софт опять же на произвольном языке, и повторять итерации любое количество раз.
Re: Применимость питона в критичном по времени коде
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я ж говорю, что "писать драйвера" технически (чтоб обслуживаемое устройство хоть как-то работало) можно на любом языке, хоть на бейсике. А вот как нужно, чтоб устройство работало быстро и без внезапных задержек — начинаются вопросы. В таких случаях, конечно, можно поставить в устройство достаточно мощный процессор, поднять на нем линукс (это уже давно делается массово), и написать встроенный софт опять же на произвольном языке, и повторять итерации любое количество раз.
Я тут профан, сразу скажу. Ни одного драйвера за свою жизнь не написал
Можешь объяснить, почему на Rust тяжелее, чем на C/C++ написать драйвер "чтоб устройство работало быстро и без внезапных задержек" без мощного проца и линукса на борту?
Re[2]: Применимость питона в критичном по времени коде
Здравствуйте, MaximVK, Вы писали:
MVK>Я тут профан, сразу скажу. Ни одного драйвера за свою жизнь не написал MVK>Можешь объяснить, почему на Rust тяжелее, чем на C/C++ написать драйвер "чтоб устройство работало быстро и без внезапных задержек" без мощного проца и линукса на борту?
Почитайте, например, про doubly linked list in Rust.
Совершенно простейшая для C концепция выламывается напрочь из Rust с его единственностью владеющей ссылки, требуя в итоге или unsafe-уровня, или Rc<> — то есть счётчика ссылок, который даёт накладные расходы.
Это только самый знаменитый пример, но удобен тем, что его обсудили на каждом углу.
Или наличие структур типа виндовой забыл-как-зовут где собственно запрос передаётся по стеку реализации, несколько фиксированных полей, а затем свободные. Конверсии такого типа это тоже unsafe, а политика времени жизни на каждое поле может быть своя и специфичная.
Если писать на Rust в сплошном unsafe, то нахрена тот Rust?
Если писать на Rust так, как на нём пишут, например, userland для многонитевости, то накладные расходы будут такими, что будет жалко компьютер с тем драйвером.
The God is real, unless declared integer.
Re[4]: Применимость питона в критичном по времени коде
Здравствуйте, MaximVK, Вы писали:
MVK>Можешь объяснить, почему на Rust тяжелее, чем на C/C++ написать драйвер "чтоб устройство работало быстро и без внезапных задержек" без мощного проца и линукса на борту?
В общих чертах: Rust — язык более высокого уровня, чем C++. Это означает, что компилятор и рабочая среда языка (runtime) берут на себя заботу о большем количестве неявных условий, правил и действий.
Большинство элементарных (то есть, неделимых, и не ссылающихся на известные конструкции) языковых конструкций в C++ порождает элементарный же код, в среднем из единиц процессорных команд. Исключением являются разве что создание/перехват исключения (типа, каламбур), да работа с длинными числами.
В большинстве остальных языков гораздо больше элементарных конструкций, которые могут раскрываться в нетривиальные командные последовательности (вызовы служебных функций, обращения к сервисам ОС, порождение аппаратных исключений и т.п.).
А практически любой драйвер, как программа достаточно низкого уровня, должен работать максимально предсказуемо. Если программист описывает в коде выполнение простой операции, предполагающей небольшое количество элементарных действий, то в них не должны вклиниваться всякие динамические выделения памяти, сборка мусора, оптимизация размещения, проверка целостности служебных баз данных и подобное.
Драйверы ядра вдобавок ограничены в спектре используемых средств ОС. Например, при работе на повышенных приоритетах (обработка аппаратных прерываний, синхронизация со службами ядра и т.п.) недоступны файловые операции, общие средства работы с динамической памятью, средства перепланировки потоков, операции ожидания и подобное. Поэтому программист должен иметь гарантию, что библиотека поддержки языка не потащит что-нибудь из этого за собой.
А линукс тут вообще ни при чем.
Re[5]: Применимость питона в критичном по времени коде
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, MaximVK, Вы писали:
MVK>>Можешь объяснить, почему на Rust тяжелее, чем на C/C++ написать драйвер "чтоб устройство работало быстро и без внезапных задержек" без мощного проца и линукса на борту?
ЕМ>В общих чертах: Rust — язык более высокого уровня, чем C++. Это означает, что компилятор и рабочая среда языка (runtime) берут на себя заботу о большем количестве неявных условий, правил и действий.
ЕМ> Если программист описывает в коде выполнение простой операции, предполагающей небольшое количество элементарных действий, то в них не должны вклиниваться всякие динамические выделения памяти, сборка мусора, оптимизация размещения, проверка целостности служебных баз данных и подобное.
