Нет. Планировщик ОС легко может ворочать приоритетами твоего приложения и от этого скорость немного будет скакать.
Также тут будет влиять скорость компьютера.
Чуть лучше будет, если попробуешь задавать задержку явно через sleep.
Если хочется приблизиться к чему-то более-менее равномерному - используй таймеры, которые предоставляет ОС.
Там тоже не будет точности реалтайма и часто не будет возможности задать очень низкий интервал, но погрешность будет более предсказуемая и не будет сильно зависеть от железа.
А чтобы измерить задержки - выводи время в каждом таком такие (можно даже не реальное, а системное).
Потом посмотри на равномерность интервалов через какой-нибудь excel.
6.38 ns ± 0.138 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)
0.138 ns это разброс, правильно понимаю?
Тоесть каждый цикл конструкции while может быть пройден быстрее или медленнее 0.138 ns ?
Такие же условия как и на юпитер ноутбуке если воссоздам на обычном пк
Так же можно опираться на эту дельту как на максимальную?
eegmak, 0.138 ns это стандартное отклонение за 100 миллионов циклов.
Так же можно опираться на эту дельту как на максимальную?
Вы пытаетесь спрашивать достаточно сложный вопрос, не описывая что конкретно вы хотите получить и почему используете питон. В обычных условиях, при отсутствии перегрузок или недостатка CPU/RAM/MEMORY - да можно опираться.
Каким образом в Java можно "понять" задержки, если там никакого реалтайма нет, JIT легко в процессе работы перелопачивают код, а сборщик мусора может в произвольный момент на произвольное время вообще всё остановить?
Василий Банников, Ну коммон, прочти хоть спеки https://en.wikipedia.org/wiki/Real_time_Java
Реалтайм это не приговор, просто нужно следовать определенным правилам.
Как то распределение памяти предварительно, избегание эксепшенов, подготовка потоков и прочее.
Это все используется в С, С++
Я даже думаю что это возможно и в питоне ( CPython )
Просто на С проще
Владимир Коротенко, прочитал по диагонали пару страниц. Сложилось впечатление, будто rtsj работает только в rt-окружении (тоесть уже в общем случае работать не будет) и только в тех реализациях рантайма, которые эту спецификацию поддерживают.
Ну и на каком бы языке ты ни писал - у тебя всё ещё остаётся ОС, другие приложения, разное железо, переменчивая частота процессора итд.
Если ставится задача работать в настоящем реалтайме - систему нужно строить начиная с железа.
Владимир Коротенко, Василий Банников, господа, реалтайм понятное дело широкое понятие. Чем меньше посредников тем быстрее.
Разве процесс менеджер на ОС имеет право на бесконечное время замораживать процесс?
Владимир Коротенко, в каких обстоятельствах такое необходимо? (Чтобы ос замораживала процесс на неограниченное время)
Любая ос где можно запустить без бубна питон код
Василий Банников, а серьёзных измерений по теме не имеется в свободном доступе?
те же госстандарты например в системах где важно время опираются ведь на чтото и ссылаются в выборе программных средств.
Василий Банников, почему не питон?
Один замер пускай покажет 1 секунду дельты. Пускай сто замеров покажут максимум секунду.
Можно сказать что больше секунды задержки не будет?
eegmak,
1. Тк у тебя тут обычный цикл, то на другом компьютере будет другой результат
2. Замер ты произвёл на ненагруденном компьютере.
И вот его нагрузили, например, игрой, а твоя программа осталась в фоне - вот теперь ОС понизила приоритет и дельта стала сильно больше секунды
3. Замер производился на ноутбуке на зарядке в режиме высокой производительности.
И вот ты отключаешь его от зарядки и он переходит в экономный режим - результат ожидаемый.
И это ещё не рассматриваем случай со спящим режимом
никогда не слышал чтобы в стандартах ссылались на какой-то конкретный продукт.
По стандарту нужно сослаться на спецификацию выбранных средств или исследования этих средств(если производитель питона не указал необходимые параметры :D) чтобы обосновать будущие тех характеристики.
Василий Банников, вы верно мыслите :D
Вы опять не ставите верхнюю планку для задержки процесса исполнения питон кода с высоким приоритетом?
Пускай это будет 10 секунд но как это обосновать что бесконечно процесс не может уходить во фриз или может?
Василий Банников, Владимир Коротенко, приведите пример который смогу повторить чтобы процесс правильно написаного питон кода(чтобы память освобождалась итд)
на неограниченное время остановился.
Мне кажется такое только в случае ошибки программиста возможно.
А во всех остальных случаях типа переменная какая то записана через сколько секунд передавать "фокус" параллельно запущенным процесам.
Ну это домыслы мб и бесконечно может фризиться. Есть конкретика?
ну вот видите а вы говорите что возможно только на реалтайм ос
С чего бы это?
ОС общего назначения позволяют назначать приоритет, но они не гарантируют что код будет выполнен за определенное время. А вот системы RTOS позволяют это делать. За счет этого они более тормознутые и более затратные. Забавно да?
они не гарантируют что код будет выполнен за определенное время
Вот откуда эта информация что в виндовс код не может быть выполнен за определеное время?
запуская питон скрипт или любой другой код вы ведь оцениваете "определенное время".
Код не будет крутиться вечно если алгоритм имеет конечную сложность.
Тоесть я понимаю разницу между "конкретное время" типа пять секунд и "конечное время" не более минуты.
Точнее даже не так..
Процесс может быть прерван не более чем на "конечное время".
А этих прерываний, само собой, может быть достаточно много.
В виндовс(или линукс) таких процессов которые могли бы прервать выполнение скрипта более чем на конечное время до x...
Пускай этих процессов в ос сто штук но все они прерывают выполнение на X
В rtos разве нет такой дельты?
Если не брать в рассчет нестабильность оборудования, а только вариативность алгоритма "общей системы"
В ртос ведь так же при обращении к памяти есть некоторая вариативность, наверняка эта вариативность при доступе к "битому" жесткому диску в виде дельты учитывается или нет?
Конечность процесса ведь гарантируется вне зависимости от того каким вариантом упакован файл на ssd
Владимир Коротенко, худший случай полюбому можно придумать)
По ограничениям если пройтись..
К примеру нельзя на виндовс более 64 usb устройств подключать или типа того..
Может нельзя более 2^64 процессов запускать в очередь. У каждого процесса дельта X таймаут на выполнение.
Как то так
Спасибо
eegmak, Вы не так мыслите. Задержки пофиг, главное результат в четко очерченное время. Если нет то задача убивается. Тут жестко и это как правило фэйл.