В Windows всегда был встроенный портал в недавнее прошлое: индикатор загрузки ЦП в Диспетчере задач.
Диспетчер задач в Windows XP
«Число ЦП в Диспетчере задач — это своего рода движущийся некролог недавнего прошлого, — объяснил бывший инженер Microsoft Дэйв Пламмер, — а не то, что происходило в тот самый момент, когда вы посмотрели на строку».
Пламмер написал оригинальную версию Диспетчера задач, когда это была лаконичная и эффективная машина для завершения процессов, а не нынешний значительно более громоздкий и дружелюбный инструмент. С тех пор он провел пользователей через экскурсию по исходному коду, признавшись по пути, что оставил свой номер телефона в комментариях, когда искал странный баг в том, как сообщались данные о загрузке ЦП. Этот баг и стал предметом его последнего объяснения.
Так как же Диспетчер задач сообщал процент загрузки ЦП? Ответ сложен. В Windows не было некоего волшебного значения загрузки ЦП, готового к считыванию. Вместо этого Диспетчер задач Пламмера работал на основе таймера. Каждый раз, когда срабатывал таймер, код запрашивал у ядра накопительное время выполнения и сравнивал его с предыдущим образцом.
«Для отдельного процесса расчет, по сути, таков: накопительное текущее время ЦП минус предыдущее накопительное время ЦП. И это дает вам, сколько ЦП было потреблено этим процессом в интервале между выборками», — сказал он.
«Процент для каждого процесса — это просто дельта этого процесса, деленная на общую дельту».
«Теперь, — продолжил ветеран-инженер, — если это выглядит как то, что вы пишете, когда слишком долго заперты в офисе с копией книги Петцольда и большим количеством кофе, то это потому, что так оно и есть».
Под «Петцольдом» имеются в виду книги Чарльза Петцольда, которые были незаменимым подспорьем для программистов Windows в 1990-х годах, а также в 2000-х и далее. У многих инженеров с большим стажем на полках наверняка до сих пор хранятся зачитанные до дыр экземпляры.
При всей элегантности решения, у него были свои сложности. Периодические сбои в отчетности ядра Windows могли приводить к тому, что проценты не складывались в 100%, что вызывало обилие проверок (asserts) в коде — и просьбу связаться с Пламмером напрямую, если загрузка ЦП когда-либо превышала эту цифру.
А затем есть проблема современного оборудования. Пламмер сказал: «В те дни учет времени планировщиком и фактическая пропускная способность процессора были гораздо теснее связаны, потому что тактовые частоты ЦП были относительно статичными. Однако на современных ЦП оборудование постоянно меняет режимы работы.
«Почти простаивающее ядро может быть понижено в частоте, заблокировано или переведено в спящий режим, потребляя энергию через соломинку, а затем, как только появляется реальная работа, оно может перейти на гораздо более высокую частоту или даже превысить номинальную тактовую частоту в режиме турбо».
Поскольку учет в Диспетчере задач был по сути основан на времени, объем работы, выполненной за любой заданный интервал, сильно варьировался в зависимости от того, на какой частоте работала кремниевая подложка.
«Счетчик не ошибается, но он измеряет скорее занятость, чем производительность». Он был создан для более простой эпохи, до того как масштабирование частоты ЦП и троттлинг стали нормой.
«Когда цифры [сегодня] кажутся немного скользкими, это не потому, что инструмент сломан, а потому, что оборудование перестало быть достаточно простым, чтобы один процент мог рассказать всю историю».
Пламмер рассказал The Register: «Моим главным побуждением было учесть каждый такт, убедиться, что каждый из них правильно отнесен к соответствующему «центру затрат», а затем определить, какой объем реальной работы был выполнен в этом временном окне. Это кажется довольно точным, и, я полагаю, что более важно, это «ощущалось» мной правильным с точки зрения того, что делала машина».
Он не смог прокомментировать, как современная итерация Диспетчера задач справляется с этой задачей, сказав нам: «Я знаю, как бы я это сделал, но не хочу предполагать!» ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Richard Speed
