ZXMAK2 - Виртуальная машина ZX Spectrum

[ZXMAK]

А мой опыт тестирования эмуляторов показал, что управление приоритетом прекрасно везде работает. Ни один из пользователей EmuStudio, во всяком случае, никогда не говорил о проблемах с этим.

в старых системах любой процесс может выполнить операцию требующую административных привелегий. В новых это не работает (случаи когда юзер отключает UAC и дает всем процессам админские права, открывая дорогу вирусам не рассматриваем). Я ориентируюсь на новые, поэтому ZXMAK2 сам приоритетами не управляет и поэтому не требует административных прав для запуска
Более того, особой разницы между realtime приоритетом и нормальным я вообще не вижу. Если алгоритм хорошо спроектирован, он будет хорошо работать с любым приоритетом. Кроме того, сам подумай что будет если все процессы будут сами себе ставить realtime приоритет?

[Titus]

в старых системах любой процесс может выполнить операцию требующую административных привелегий. В новых это не работает (случаи когда юзер отключает UAC и дает всем процессам админские права, открывая дорогу вирусам не рассматриваем). Я ориентируюсь на новые, поэтому ZXMAK2 сам приоритетами не управляет и поэтому не требует административных прав для запуска

На сколько я понимаю, и в 7 и в 8 если ты не админ, процесс может поставить себе приоритет любой, кроме RealTime.

---------- Post added at 23:30 ---------- Previous post was at 23:28 ----------

Более того, особой разницы между realtime приоритетом и нормальным я вообще не вижу. Если алгоритм хорошо спроектирован, он будет хорошо работать с любым приоритетом.

Как не проектируй, но у тебя есть 20 миллисекунд на эмуляцию кадра, рендер видео, вывод этого всего и прочее. Если любой другой процесс жирно забрал время в эти 20мс, то как не проектируй, эмулятор тормознет.

---------- Post added at 23:32 ---------- Previous post was at 23:30 ----------

Кроме того, сам подумай что будет если все процессы будут сами себе ставить realtime приоритет?

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

[ZXMAK]

Как не проектируй, но у тебя есть 20 миллисекунд на эмуляцию кадра, рендер видео, вывод этого всего и прочее. Если любой другой процесс жирно забрал время в эти 20мс, то как не проектируй, эмулятор тормознет.

процесс который сам себе ставит приоритет - это на мой взгляд однозначный *****код, например если увижу что какой-то процесс требует приоритет выше нормального, пользоваться таким процессом не буду и удалю его
Эмулятор не сможет хорошо работать имея realtime приоритет. Этим он отбирает время у процессов которые могут лочить ресурсы. И если у них приоритет будет ниже чем у эмулятора, то эмулятор имея высокий приоритет будет жрать процессор вхолостую, т.к. всеравно будет ждать освобождения ресурсов, но ресурсы будут освобождаться медленно, т.к. эмулятор как собака на сене - сидит на процессоре, но ни сам не может его эффективно использовать, ни другим не дает чтобы быстрее освободить ресурсы

Поэтому даже не вижу смысла делать галочку "собака на сене"

В идеале я считаю эмулятор должен нормально работать с приоритетом ниже нормального, если это удалось - значит алгоритм выбран идеальный.

Мне вообще алгоритм сканирующий vblank не нравится, я думаю от него отказаться - это снизит потребление процессора и улучшит время реакции эмулятора.

[Titus]

процесс который сам себе ставит приоритет - это на мой взгляд однозначный *****код, например если увижу что какой-то процесс требует приоритет выше нормального, пользоваться таким процессом не буду и удалю его
Эмулятор не сможет хорошо работать имея realtime приоритет. Этим он отбирает время у процессов которые могут лочить ресурсы. И если у них приоритет будет ниже чем у эмулятора, то эмулятор имея высокий приоритет будет жрать процессор вхолостую, т.к. всеравно будет ждать освобождения ресурсов, но ресурсы будут освобождаться медленно, т.к. эмулятор как собака на сене - сидит на процессоре, но ни сам не может его эффективно использовать, ни другим не дает чтобы быстрее освободить ресурсы

Поэтому даже не вижу смысла делать галочку "работать как собака на сене"

В идеале я считаю эмулятор должен нормально работать с приоритетом ниже нормального, если это удалось - значит алгоритм выбран идеальный.

Это твои идеалогические заморочки, практика показывает, что это не так)

Во первых, я не говорил про realtime приоритет, а про high приоритет, он на один ниже и ничего не лочит. Но даже в realtime все работает идеально, если грамотно спроектирован эмулятор. Нигде он не сидит в холостую и ничего не жрет. Как только выполнил все, что надо, отдал время другим процессам.

Значит тебе пока что не удалось) Как удастся, поделись опытом, может и я откажусь от высокого приоритета)

[ZXMAK]

Это твои идеалогические заморочки, практика показывает, что это не так)

мои заморочки основаны на том, что планировщик задач охотнее и быстрее выделяет время тем процессам, которые его меньше всего требуют. А те процессы, которые желают эксклюзивно держать у себя процессор в монопольном пользовании, просто обречены на потерю процессора в самый неподходящий момент. Система такого не любит. И попытка ограничить систему используя realtime приоритет ничего хорошего не даст.

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

[Titus]

Поэтому для оптимизации нужно думать не как украсть у системы лишний квант времени, а как снизить требования к необходимому времени.

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

[ZXMAK]

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

ты не понимаешь простую вещь, windows - это не система, где один процесс может захватить все ресурсы и монопольно использовать их.
Система шарит ресурсы между всеми процессами в равной степени.

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

Windows не настолько умна, чтобы рулить приоритетами, в зависимости от локов на ресурсах. Поэтому твой вызов просто уйдет на прожигание времени в холостом цикле, в ожидании пока не закончится вызов другого процесса, у которого ты украл время. Однако он не закончится до тех пор, пока ему не предоставят время. А твой процесс его не предоставляет, т.к. поставил себе риалтайм приоритет.

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

Так что высокий приоритет преимуществ не дает, а наоборот, при неразумном использовании может привести к тому что все будет наглухо висесть.

[Titus]

ты не понимаешь простую вещь, windows - это не система, где один процесс может захватить все ресурсы и монопольно использовать их.
Система шарит ресурсы между всеми процессами в равной степени.

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

...

Так что высокий приоритет преимуществ не дает, а наоборот, при неразумном использовании может привести к тому что все будет наглухо висесть.

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

Ты можешь рассказывать чего угодно - от некошерности руления приоритетами в среде винды до чего-то еще, но только не то, что это не дает преимуществ или завешивает систему, потому что я 10 ЛЕТ пользуюсь подобной базой в эмуляторе, а это достаточная практика для собирания багов)

[ZXMAK]

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

Ты можешь рассказывать чего угодно - от некошерности руления приоритетами в среде винды до чего-то еще, но только не то, что это не дает преимуществ или завешивает систему, потому что я 10 ЛЕТ пользуюсь подобной базой в эмуляторе, а это достаточная практика для собирания багов)

видеокарта может быть захвачена кем угодно, в том числе и самой системой, это никак не зависит от приоритета. Процесс с любым приоритетом, даже Low, может сделать вызов драйверу видеокарты и пока вызов не завершится это залочит видеокарту даже для самых мажорных процессов с realtime приоритетом. Мажорные процессы ничего не смогут с этим сделать, у них будет процессорное время, но они будут его жечь вхолостую ожидая пока не завершится вызов к драйверу, сделаный каким-то процессом у которого какой-то жалкий Low приоритет. А он быстро не завершится, т.к. какой-то шибко умный процесс решил оттяпать себе времени по максимуму.

Чтобы решить эту проблему, нужно не красть у системы время, повышая приоритет, а наоборот - давать системе как можно больше времени, чтобы блокировки установленные другими процессами снялись как можно быстрее

Кроме видеокарты в системе полно таких ресурсов - звуковая карта, диск, память и т.п.

[Titus]

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

Чтобы решить эту проблему, нужно не красть у системы время, повышая приоритет, а наоборот - давать системе как можно больше времени, чтобы блокировки установленные другими процессами снялись как можно быстрее

Какие ты можешь назвать 'мажорные' процессы, которым доступ к видюхе важнее, чем эмулятору?

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

---------- Post added at 00:24 ---------- Previous post was at 00:22 ----------

Кроме видеокарты в системе полно таких ресурсов - звуковая карта, диск, память и т.п.

Звуковая карта (программный мишкер, отправляющий смикшированный фрагмент звуковухе) работает не зависимо от приоритетов процессов.