|
| |
| 2.17, Аноним (17), 19:27, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– |
Глянул специально ядро. Есть варианты: 100, 250, 300, 1000. Но как я понял, можно и пропатчить, если сильно надо.
| | |
| |
| 3.81, Аноним (-), 06:26, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| –8 +/– | |
>можно и пропатчить, если сильно надо.
Этот жаргон меня уже достал. Можно сконфигурировать исходники ядра, выставив частоту в 1000 Гц и заново скомпилировать. Наложение патча это другое действие.
| | |
|
| 2.19, Oe (?), 19:28, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +4 +/– |
Закончиться динамической частотой таймера. Я её даже на ардуинке делал, пока есть задачи 1000 Гц, когда задач нет можно дропать до 100 Гц чтобы проц не пробуждался часто.
| | |
| |
| 3.76, Аноним (76), 01:56, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –4 +/– |
в винде так сделано из коробки :) т.е. по дефолту 64 или 100гц, а если софтине нужно больше, то она сама выставляет нужный таймер.
| | |
| |
| 4.86, n00by (ok), 07:55, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 А в каком году документировали такой эффект от вызова timeBeginPeriod()? Я этот момент не застал, в нулевых пришлось расковырять планировщик полностью, начиная с ISR таймера, что бы обосновать "всем известный" хак.
| | |
| 4.105, Аноним (91), 11:18, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Взять хотя бы 2025 Server: точность таймера выставляется на 0.5мс, глобально для всей системы. Windows 11 24H2 - 1ms, но уже для приложений, локально.
| | |
| 4.154, nrv (ok), 04:36, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
 ага
и там безальтернативно впилен .NET Framework, в который впилен XAML
который для своей отрисовки ставит свою частоту
на которую потом ругается powercfg /energy
..если это, конечно, сабж
| | |
|
|
| 2.21, Аноним (-), 19:35, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +4 +/– | |
> Закончится тем, что 1000 это много, а 500 в самый раз. :)
Смотря для чего. На обычном десктопе - вы точно хотите 1000Гц, для уменьшения латенси и уменьшения всяких нездоровых дергов. Ибо чем быстрее шедулинг задач - тем ниже латенси каждой задачи. Быстрее очередь доходит до энного желающего пожрать ресурсы проца.
Это разумеется ведет к некоему оверхеду. Однако в "full dynticks" ядрах эффект не такой уж и большой - ибо если известно что в энный момент делать нечего, то и прерывания от таймера скипаются, что частично аннулирует аргументы второго инженера из гугля.
Как видно из бенчей - результат разный и всяко плюс-минус считанные проценты. На десктопе и лаптопе более приятный десктоп от более низкой латенси - явно перевешивает экрномию на спичках.
| | |
| |
| |
| 4.121, Аноним (-), 15:03, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Если у тебя нездоровые дёрги, то частота тут не причём.
Не у меня а у системы. Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.
| | |
| |
| 5.127, Аноним (-), 15:36, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
>Не у меня а у системы.
Я понял. что не у тебя.
>Которая лагает и дергается на таких вещах. И когда это превышает порог заметности для человека - это отстойный user experience.
В глюках твоего компа частота таймер не играет никакого значения.
| | |
| |
| 6.151, Аноним (-), 20:10, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> В глюках твоего компа частота таймер не играет никакого значения.
Эффекты от конечности кванта времени - глюками не являются, для начала. Если уж хочется казаться умным - неплохо бы понять хотя-бы вот это.
| | |
|
|
|
| 3.89, Андрей (??), 08:16, 14/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +2 +/– |
Только "лаптоп"(лапаный топ?) будет работать меньше от аккума, а пресловутая "латенси" не будет сильно заметна глазу, что собственно и по бенчмаркам заметно, где прирост есть, но всего 5-10% и нигде не указан расход энергии, ибо если +5-10% по скорости и -20% автономности ноутов, то тут ещё стоит подумать.
| | |
| |
| 4.96, Оно ним (?), 09:36, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Вообще-то прямо здесь в статье указан расход, если вы посмотрите буквально следующий абзац. Видно, что среднее и максимальное энергопотребление не отличаются, только минимальное на 250 Гц ниже. Из чего можно сделать вывод, что на 1000Гц слегка сократится работа в режиме простоя, и то вряд ли значительно.
| | |
|
|
| 2.101, _kp (ok), 11:00, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [↑] [к модератору]
| +1 +/– |
 Я с 2011 года использую 1000Гц, и всё хорошо, никаких противопоказаний, одни плюсы.
Странно что до сих под воду в ступе толкут.
| | |
| 2.174, Аноним (174), 13:55, 16/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
как то на хабре видел пример того что 300 хорошо делится сразу и на 50 (25) и на 60 (30) - отсюда более оптимальная работа графики с частотой дискретизыции, соответственно, на мониорах/телевизорах в том числе при воспроизведении видео и частично борется с тирингом
| | |
|
| 1.3, Аноним (3), 18:51, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –16 +/– |
Теперь понятно почему люди с высокими герцами у моника топили за то, что оно не хуже и даже лучше обычных 60. Оно работало на тех же 60.)
| | |
| |
| 2.16, Oe (?), 19:26, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –8 +/– |
Лучше бы сделали синхронизацию таймера с частотой монитора, непонятно почему это до сих пор не сделано, а сейчас уже не нужно ибо freesync. Интересно, сколько еще времени пройдет пока компьютер начнет работать с временем нормально? Видео только на аппаратных плеерах нормально можно смотреть, на компьютерах сплошной джиттер кадров.
| | |
| |
| |
| 4.84, Смузихлеб забывший пароль (?), 07:34, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
Но ведь гении от разработки видеокарт ещё недавно хотели увязать те же движения мыши с изменением кадра на монике( сдвиг/обрезка ) практически без участия ЦП. Типо, для улучшения визуального ощущения быстрой отрисовки. Хотя, вроде бы, системы тоже разные и не очень-то зависимые
В крайнем случае, можно делать просто множитель кратно частоте экрана. Например, 4-6
Но переделывать придётся много
| | |
| |
| |
| 6.178, Смузихлеб забывший пароль (?), 13:48, 17/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
У многих железок установлена микросхема, в которой определены многие параметры. Вплоть до планок ОЗУ. И ничего, не померли.
По сути, изначально требуется чтобы при начальной загрузке системы подтягивались данные в т.ч из моника и на основе них выставлялись некоторые множители. Они и так выставляются на основе иных параметров, просто именно монитор до последнего не учитывали
| | |
|
|
|
|
|
| |
| 2.52, Аноним (52), 21:16, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Передрались.
"Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера."
| | |
|
| 1.7, Совершенно другой аноним (?), 19:02, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| –2 +/– |
Странно, что никто не сказал, что увеличение частоты повысит накладные расходы, т.к. прерывание предполагает переход из режима пользователя в режим ядра, сохранение регистров, вызов обработчика прерывания, восстановление регистров, а затем возвращение в режим пользователя.
| | |
| |
| |
| 3.14, Совершенно другой аноним (?), 19:20, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
>> "так повышение частот генерации прерываний таймера может привести к повышению энергопотребления"
это немного не то. Вопрос не про увеличение потребления энергии, а про потерю производительности. В то время, пока процессор бегает по прерыванию он, очевидно, не выполняет какую-либо полезную работу.
| | |
| 3.102, _kp (ok), 11:04, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Светлая тема на Олед дисплее увеличит энергопотребление на порядкИ больше, чам частота таймера.
Напомнило экономию на спичках.
| | |
|
| |
| 3.51, Аноним (51), 21:12, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +3 +/– | |
> Фороникс говорит, что не всё так однозначно!
Фороникс говрит, судя по опыту, что неоднозначность там спичечная и для адекватных людей очевидно, что движняка такого не стоит.
| | |
|
|
| |
| |
| 3.59, Ivan_83 (ok), 22:01, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
 Это не совсем оно.
Частота о которой идёт речь она про переключение потоков планировщиком, особенно когда потоков больше чем ядер (те почти всегда и особенно под нагрузкой).
| | |
| 3.75, Аноним (75), 01:48, 14/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
>cat /boot/config-6.12.13-amd64 | grep CONFIG_NO_HZ_FULL
>CONFIG_NO_HZ_FULL=y
В общем - не понятно, о чём буря в стакане.
| | |
|
|
| 1.11, Аноним (11), 19:17, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +4 +/– |
А они замеряли потерю производительности на коде, который не спамит потоками потому что по другому никто и не пытался программировать?
| | |
| |
| 2.61, Ivan_83 (ok), 22:06, 13/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
И чо?
Во фре сколько себя помню HZ=1000.
Помню игрался давно уже на арме с этим и уменьшение до 250 давало хороший буст, ниже уже разницы не было так заметно.
Но и терминал начинал немного подлагивать.
| | |
| |
| 3.74, Аноним (74), 00:54, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном ядре. Если не нравится настройка по умолчанию.
Не ясно что мешает в Линуксе сделать так же. Если вдруг кому дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только пересборка.
| | |
| |
| 4.129, Аноним (129), 15:45, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
> Кстати во фре оно при загрузке может задаваться (в loader.conf).. на ванильном
> ядре. Если не нравится настройка по умолчанию.
> Не ясно что мешает в Линуксе сделать так же. Если вдруг кому
> дефолтные тики "жмут", grub.conf поправил и перегрузился. но нет. нельзя. только
> пересборка.
Вероятно с статиченым указанием этого - получается более хорощая оптимизация кода. При wakeup проца до 1000 раз в секунду - это некий аргумент.
Если вы будете будить проц 1000 раз в секунду, без оптимизаций, батарейка скиснет значительно быстрее чем того могло бы хотеться. Возможно 1 из секретов почему в фри так голимо с управлением питанием. У фряхи с управлением питанием и оптимизацией потребления очень голимо все.
| | |
| |
| 5.173, Аноним (173), 04:21, 16/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> секретов почему в фри так голимо с управлением питанием. У фряхи
> с управлением питанием и оптимизацией потребления очень голимо все.
Голимо ты man'ы читаешь, это точно. УМВР более семи часов, при чём видео безпрерывно стримится. По сравнению с GNU/Linux разница есть, но вообще не большая.
Рекоммендую pkg install powerdxx && man -k dev
| | |
|
|
|
|
| |
| 2.29, Аноним (-), 19:54, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– | |
> Юзаю 100Hz уже 7+ лет и комп не парится.
Комп то не парится. А вот его владельца будет ожидать отстойный и дерганый experience, ибо решение о том какую задачу вообще пускать - принимается раз в 10 мс. Что довольно дофига, учитывая многопотосночть и вообще число программ и результирующее число претендентов на квант времени. Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.
В общем 100Гц ядра - только для махровых вебсерверов, замурованных в стену. Где никто не заметит +/- 100 мс.
| | |
| |
| 3.62, Аноним (15), 22:12, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– |
Чем больше ядер - тем менее актуален планировщик.
Для игорей можно выделить ядра, которые будут сидеть на процессе. Если процессу хватает ядер, то таймер не нужен (tickless), а увеличение его частоты даст обратный эффект по производительности.
| | |
| |
| 4.130, Аноним (129), 15:48, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> Чем больше ядер - тем менее актуален планировщик.
Не, ну если у вас последний EPYC с 192 ядрами, есть шансы что все треды ядра и треды программ конечно найдут свои ядра и будут довольны по уши :). Иначе - это ну вот не факт, их видите ли развелось довольно много.
Просто сделайте ps с выводом по тредам - и посмтрите, есть у вас столько ядер или где? Не забудьте ядерные треды, коих нынче дофига. А что, раз ядер более 1 то и ядро совсем не против threaded стать в таком случае.
| | |
|
| 3.180, roman (??), 22:23, 17/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– | |
>Учитывая что при этом заранее неизвестно что претендент поработает не 10 мс а например 5 и отвалит, шедулинг получается весьма компромиссный.
Если софт умер за 5мс то планировщик просто возьмет следующий из очереди, не дожидаясь прерывания, потом сделает его по расписанию еще раз, то есть может быть ситуация что первый отработает 9мс а второй 1мс.
| | |
|
|
| |
| 2.49, Аноним (-), 20:52, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +2 +/– |
Мог бы.
Но зачем? Проще использовать готовый труд сообщества.
Главное направлять его, аки пастух стадо баранов, в нужном направлении.
| | |
| 2.66, Шарп (ok), 22:47, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
 > Google уже давно мог бы написать собстенную ОС под свои задачи.
А он не может. С чего ты решил, что гугл всемогущий. Например это гугловские бойцы придумали архитектуру трансформер, на которой сейчас всякие чат-гпт работают, но они не лидеры в нейросетках.
| | |
| |
| 3.166, Онанимб (?), 17:43, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
Ну они изначально позиционировали Фуксию как экспериментальную ОС. Ни о каком захвате мира речи не было, всю эту тему раздули блохеры и журнашлюхи.
| | |
| |
| 4.172, Аноним (172), 23:36, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Всю эту тему раздули на опеннете, нигде за пределами оного никто и не писал, что дескать все, линукс выкинут и будет Фучия
Это реально было просто местечковым бредом
| | |
|
|
| 2.170, name (??), 19:48, 15/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
К сожалению, чтобы написать ОС надо обладать какими-то навыками и опытом кроме верчения деревьев на питоне. А индусы-олимпиадники ничего другого не умеють.
| | |
|
| 1.36, Аноним (36), 20:27, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +1 +/– |
Вопрос на опережение: возможно ли это будет как-то отключить и вернуть назад? (да, кора дуба и квадратный монитор из 2004, но это не ваше дело)
| | |
| |
| 2.54, Аноним (54), 21:21, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +2 +/– | |
Там нечего возвращать, буквально лишь поменяли 1 число в конфиге по-умолчанию. Это ни на ком вообще не отразится, так как дистрибутивы в любом случае свои конфиги используют. И да, многие уже давным-давно 1000 HZ используют.
А Core2Duo кстати достаточно современный процессор. Для него таймер этот капля в море, увеличение частоты только приведет к улучшению отзывчивости системы.
Разницу в нагрузке цпу между разными значениями таймера могут увидеть разве что владельцы каких-нибудь совсем музейных 386-ых или embedded кофеварок.
| | |
| |
| |
| 4.169, Аноним (-), 19:05, 15/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> Сижу на 300 и никаких жутчайших лагов и проблем о которых тут
> пишут нету. ЧЯДНТ?
Систему плотно подгрузить не пробовал чтобы шедулинг стал актуален. Если шедулить нечего - то и проблем с этим нет :)
| | |
|
|
| 2.57, Аноним (172), 21:54, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Сейчас ты можешь поставить HZ_1000, просто в дефолтном конфиге стоит HZ_250
И в мэйнстримных дистрибах мэйнтейнеры ставят HZ_1000
Если ты не на Генту или ЛФС, то скорее всего у тебя и так стоит уже 1000
Если же ты собираешь ядро сам(судя по вопросу нет), то просто сможешь переключить и все
| | |
|
| 1.37, Аноним (37), 20:28, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– | |
> При использовании дисплеев с частотой обновления 120Hz, типичных для современных [...] мобильных устройств
Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.
| | |
| |
| 2.41, Аноним (36), 20:32, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– | |
> Сейчас даже 90 герц далеко не на всех, да и то оно по умолчанию выключено, ибо выжирает и без того немощные батареи.
Даже на тех где есть стоит динамическая частота обновления. Но в целом да, 60 это стандарт и будет им ещё не один десяток лет. Даже в айфонах не спешат с этим.
| | |
| |
| 3.53, Аноним (53), 21:16, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
> 60 это стандарт и будет им ещё не один десяток лет
Откройте для себя хотя бы среднебюджетные телефоны. Хотя уже и на самом дешмане часто 90 Гц бывает.
> Даже в айфонах не спешат с этим
«Даже»… в айфонах много с чем не спешат.
| | |
|
| 2.44, Аноним (-), 20:41, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +3 +/– |
> Уоу, с каких это пор 120 герц типичны для мобил? Сейчас даже
> 90 герц далеко не на всех, да и то оно по
> умолчанию выключено, ибо выжирает и без того немощные батареи.
Немощные батаереи нынче так то - во всю крышку, если вы не заметили. И емкостью под 6 амперчасов. От этого скоро авто можно будет прикуривать! Выжирает их - таки - блевота на электроне, когда кирпич норовит сварить яйца лежа в кармане. Или просто кач гигазов рекламы этим барахлом.
| | |
| |
| 3.80, Русская ядерка (-), 05:16, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– | |
> И емкостью под 6 амперчасов.
Был смартфон в 2011, кажется самсунг гэлэкси 2. Не знаю какая там батарея была, но явно меньше. И хватало его дня на 3, при том, что я с него сидел часами в приложении в контакте, слушал музыку, сёрфал вэб и играл в казуальные игрульки типа энгри бёрдс. Современные телефоны дай бог чтобы до вечера хватило зарядки.
| | |
|
| 2.71, Аноним (69), 23:56, 13/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +1 +/– |
С разморозкой. В смартах уже пару лет как 120 есть, даже в мидле.
И, ты только не падай!, есть экраны с динамической герцовкой 1-144.
| | |
| 2.97, Оно ним (?), 09:42, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Пару месяцев назад купил бюджетный самсунг с 90 Гц - и ничего не выжирает. Спокойно держит сутки, а если игры не гонять, то и двое.
| | |
| 2.163, Аноним (172), 10:41, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Poco X3 NFC — среднебюджетник 2021 года, из коробки 120 Hz обновление экрана
Poco M6 Pro — low-бюджетник 2024 года, из коробки 120 Hz обновление экрана
Или ты про совсем какую-то дичь разговор ведешь? У Сяоми вон на миддл-бренде 120 это норма
| | |
|
| 1.39, Аноним (39), 20:30, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– | |
> Конфигурация с 1000Hz оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart
Что? Опенсорс копирка марио карт теперь является тестом?
| | |
| 1.42, Аноним (42), 20:38, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –1 +/– |
А че не 1024? Там жеж, насколько я знаю, еще во времена каменного века на PC AT (на XT RTC был не обязательной железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче. Все работало. Не тормозило.
| | |
| |
| 2.48, Аноним (-), 20:51, 13/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –2 +/– |
> А че не 1024? Там жеж, насколько я знаю, еще во времена
> каменного века на PC AT (на XT RTC был не обязательной
> железкой), RTC генерил IRQ 8 1024 раза в секунду и ниче.
> Все работало. Не тормозило.
А сейчас это делается чем-то другим, типа HPET или TSC (на x86-64). Они намного более шустрые и потому точные. У других платформ тоже - как правило скоростные, перепрограммируемые таймеры есть.
| | |
| |
| 3.60, Ivan_83 (ok), 22:04, 13/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– |
HPET как раз не оч любят, типа оно на PCI шине и оверхэд большой, вот TSC типа где то прямо в проце без лишних шин посредине.
| | |
| |
| 4.103, Аноним (103), 11:04, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
Казалось бы, кто мешает аппаратные таймеры юзать, на ходу меняя умножители как на том же STM8?
Или слишком монолитно?
Когда жалуются на оверхед переключения, вспоминаю ту же BeOS где всё на eventloop которые внутри других eventloop и при этом всё нативное ПО, написанное с учётом этого подхода летает и не заикается вообще никогда.
| | |
| 4.131, Аноним (129), 15:53, 14/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
> HPET как раз не оч любят, типа оно на PCI шине и
> оверхэд большой, вот TSC типа где то прямо в проце без
> лишних шин посредине.
Так оно вроде TSC и юзает - если это получилось - в порядке приоритета. На некоторых системах однако я встречал ор что мол "clock source unstable" - и тогда fallback на HPET по моему. Но это относительно экзотичный сценарий. Чаще всего и правда TSC.
| | |
|
| 3.106, Аноним (91), 11:30, 14/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
HPET - давно превратился в рудименты. И все потому, что достаточно медленный. Проблема усугубляется, когда ядер в процессоре больше двух - тут производительность падает просто катастрофически.
| | |
|
|
| 1.58, Ivan_83 (ok), 21:59, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +2 +/– | |
Фиговые инженегры у гугла, всякую чушь пишут.
Никто не написал что при частом переключении контекстов повышается отзывчивость всяких десктопов/интерактивов но при этом же увеличивается вымывание кешей из за более меньшего кванта времени работы одной задачи на одном ядре - те жручие задачи начинают медленее работать.
Частота влияет на планировщик задач, поэтому per process оно не полуится сделать, по крайней мере без переделок шедуллера и прочих соседних внутренностей ядра.
| | |
| |
| 2.87, n00by (ok), 08:06, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
Что бы повысить отзывчивость, достаточно уменьшать квант для "интерактивных потоков". Что делается в Виндос, а потому об этом говорить как бы неприлично. :)
| | |
| |
| 3.98, Ivan_83 (ok), 09:48, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
А ты пойди найди на линухе такие процессы :)
Это в венде с геум втащенным в ядро есть за что зацепится при поиске интерактивных.
И насколько я понимаю там не уменьшение кванта времени а повышение приоритета.
| | |
| |
| 4.104, Аноним (103), 11:08, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +1 +/– |
Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших традициях всё упирается в кривизну прикладного ПО.
Причём после ухода Балмера даже родные тулзы делаются абы как и без учёта всего этого.
| | |
| |
| 5.133, Аноним (-), 16:00, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
> Виндовый планировщик и в QoS умеет, чего уж там. Только в лучших
> традициях всё упирается в кривизну прикладного ПО.
> Причём после ухода Балмера даже родные тулзы делаются абы как и без
> учёта всего этого.
Учитывая что там часть от большого ума стала на дотнете - ЭТОМУ блоатваре никакие планировщики не помогут! Обречено умереть тормозным дерганым лаговищем.
| | |
|
| 4.125, n00by (ok), 15:29, 14/02/2025 [^] [^^] [^^^] [ответить] [↑] [к модератору]
| +/– |
Да, там реализовано временным повышением приоритета. А как иначе? Два таймера - по каждому на свой тип потоков? Если правильно помню, выделялось по три кванта на поток, но повышенный динамический приоритет позволял влезть меж этими квантами вне очереди.
| | |
|
|
|
| 1.64, Аноним (64), 22:32, 13/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]
| –1 +/– |
А ведь это всё из-за Gnome, который лагает как какой нибудь смартфон Lenovo со вторым андроидом, не нужны нам эти "улучшения" на Openbox, тут и так всё работает отлично.
| | |
| |
| 2.161, Аноним (172), 09:48, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| –1 +/– |
Хочу тебя расстроить, но «работает — не трогай» это очень плохой девиз придуманный в 90ые, когда для многих что-то настроенное было почти магией
Если что-то работает, но можно улучшить, тем более если это что-то работает как сейчас просто в силу исторических причин, то можно и нужно менять
Тем более, что по факту в дистрибах и так 1000, а тут просто хотят сменить дефолтное значение. То есть тебя это вообще не коснется никак. Тем более под твоей виндой
| | |
| |
| 3.177, Аноним (177), 08:54, 17/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> очень плохой девиз придуманный в 90ые
Видимо ваш девиз больше глючности, изменения всего подряд на совершенно другое, каждое обновление.
| | |
|
|
| 1.77, Балагур (?), 03:06, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [к модератору]
| +/– |
Инженеров linux у нас не осталось, судя по комментариям и самому посту. У нас уже тысячу лет в ядре вытесняющая многозадачность, а не кооперативная, да ещё и умная. Если процесс в течении своего тика делает sched_yield, а чаще всего он это делает, потому что 1/250 или даже 1/100 процессорного времени какого-нибудь i5 13500 - это слишком много тактов, то скидулер пускает следующий процесс.
| | |
| |
| 2.88, n00by (ok), 08:10, 14/02/2025 [^] [^^] [^^^] [ответить] [↓] [к модератору]
| +/– | |
"Чаще всего делает" это из разряда "но у меня на виртуалке всё работает!"
Инженер умеет делить и умножать, а потому считает вероятность "всего лишь 1 из миллиона" неприемлемой, учитывая общее количество систем.
| | |
| |
| 3.107, Балагур (?), 12:01, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Чаще всего делает, именно так, даже если ожидает I/O, то тоже делает, но косвенно. А приложения с бесконечным циклом мы в расчет не берём, все тяжёлые вычисления или на GPU, или распараллеливания, и в принципе, тяжёлые вычисления не критичны к тику, они критичны ко времени CPU.
| | |
| |
| 4.126, n00by (ok), 15:33, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
Вспомнил, Минобразования рекламировал новую корочку диплома, там появилось "инженер". Надеюсь, им преподают теорвер и закон больших чисел в частности, а не только "циклы".
| | |
| 4.150, Аноним (-), 19:17, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> все тяжёлые вычисления [...] не критичны к тику
А остальные приложения, которые крутятся параллельно этим тяжёлым вычислениям? Это ведь может в рамках одного процесса происходит, это вполне себе паттерн программирования, выкидывать "тяжёлые" вычисления в отдельный поток, так же как в отдельный ядерный поток уходят все блокирующие операции, для того, чтобы основной поток не блокировался бы ни на вводе/выводе, ни на вычислениях, чтобы он мог быстро отреагировать на ввод пользователя или на пакет прилетевший в сетевую карту.
| | |
|
|
|
| |
| 2.134, Аноним (-), 16:02, 14/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– | |
> А если собрать с HZ_10?
Kernel slowpoke edition - для самых отборных тормозов и слоупоков, чтобы им обидно не было - так и они смогут насладиться тормозами компьютеров наконец.
| | |
|
| 1.137, Аноним (137), 16:46, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| +/– |
Да сделайте уже частоту таймера динамической, пусть автоматически подстраивается под любую систему и её текущее состояние.
Как и всё остальное, но это уже позже и железо поновее будет и технологии.
| | |
| |
| 2.176, Аноним (-), 23:19, 16/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
А ты 600 Hz (50*120)/10 ей выставить пробовал? Сюрпризы были? (не думаю что будут - я в далёком прошлом выставлял 120 с поллингом, и всё работало - это то-ли семёрка была, то-ли предрелизная бэта восьмёрки...)
| | |
|
| 1.152, Аноним (152), 21:30, 14/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [к модератору]
| –2 +/– |
Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS, iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару гуглоидов будут до посинения меряться патчами в рассылке
| | |
| |
| 2.158, Аноним (-), 08:51, 15/02/2025 [^] [^^] [^^^] [ответить] [к модератору]
| +1 +/– |
> Все ж просто: посмотрите как сделано в нормальных юниксах современных - MacOS,
> iOS, iPadOS, tvOS - и сделайте так же. Но нет, пару
> гуглоидов будут до посинения меряться патчами в рассылке
И какой процент например серверов на этом? Ах, примерно нулевой?... Понятия о нормальном - достаточно растяжимое понятие.
| | |
|
| 1.153, Аноним (153), 02:59, 15/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [↑] [к модератору]
| +1 +/– |
А если в системе 32 потока? 32 задачи одновременно могут вообще ни с кем не бороться за ресурсы. Но опять же, если работающих задач в момент времени больше чем кол-во хардварных потоков, то оверхед гораздо меньше так как вычислительных ресурсов достаточно, чтобы это покрывать. По идее, если процесс все ещё требует ресурсов по окончанию кванта времени и при этом ещё есть свободные ресурсы для других задач - ему выделится сразу же следующий квант времени без переключения контекста, но, его выполнение будет прерываться чаще на 1000 "попросту", чем на тех же 250/300. Конечно, если запустить компиляцию в 32 потока, то скорей всего, десктоп на 1000hz будет более отзывчив, но не на столько, чтобы терять в производительности долгоиграющих задач.
| | |
| 1.175, Аноним (175), 20:12, 16/02/2025 [ответить] [﹢﹢﹢] [ · · · ] [к модератору]
| +/– |
По идее, нужно посмотреть как меняется оптимальный интервал на каждом тике. Если он около такой же, то вполне можно предсказывать оптимальный интервал для следующего тика на каждом тике, а не лепить фиксированное значение.
| | |
|
