Время отклика компьютеров: 1977−2017

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

Это результаты замера отклика между нажатием клавиши и отображением символа в консоли (см. приложение для дополнительной информации). Результаты отсортированы от самых быстрых к самым медленным. При тестировании нескольких ОС на одном компьютере ОС выделена жирным. При тестировании разных частот обновления на одном компьютере они выделены курсивом.

Две последние колонки показывают тактовую частоту и количество транзисторов на процессоре.

Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.

Если посмотреть на результаты в целом, то самые быстрые — это древние машины. Более новые компьютеры встречаются во всех частях таблицы. Замысловатые современные игровые конфигурации с необычно высокой частотой обновления экрана почти могут составить конкуренцию машинам конца 70-х и начала 80-х, но «обычные» современные компьютеры не способны конкурировать с компьютерами 30-40-летней давности.

Можно ещё посмотреть на мобильные устройства. В этом случае замерим отклик прокрутки в браузере:

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

Если исключить Gameboy Color, который представляет собой иной класс устройств, то все самые быстрые устройства — это телефоны или планшеты Apple. Далее по времени отклика следует BlackBerry Q10. У нас недостаточно данных, чтобы объяснить такую необычно высокую скорость BlackBerry Q10 для не-Apple устройств, но есть правдоподобная догадка, что это объясняется наличием физических кнопок — для них легче реализовать быстрый отклик, чем для тачскрина и виртуальной клавиатуры. Два других устройства с физическими кнопками — Gameboy Color и Kindle 4.

После «айфонов» и устройств с кнопками в таблице представлены разнообразные устройства Android различных годов. В самом низу древний Palm Pilot 1000 и пара электронных книг. Заторможенность Palm объясняется тачскрином и дисплеем из эпохи, когда технология тачскринов обеспечивала гораздо меньшую скорость. Электронные книги Kindle работают на электронных чернилах e-ink, которые гораздо медленнее дисплеев в современных телефонах, так что их отставание неудивительно.

Почему Apple 2e настолько быстр?

Система Apple 2 значительно выигрывает у современных компьютеров (кроме iPad Pro) по скорости ввода и вывода, поскольку Apple 2 не имеет дела с переключением контекстов, буферами при переключении разных процессов и т.д.

Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц (например, Ergodox заявляет о частоте 167 Гц). Для сравнения, Apple 2e эффективно сканирует ввод на частоте 556 Гц. См. приложение с дополнительной информацией.

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

На 144 Гц каждый кадр занимает 7 мс. Изменение картинки на экране вызывает дополнительную задержку от 0 мс до 7 мс из-за ожидания границы следующего кадра перед его отрисовкой (в среднем мы ожидаем половины максимальной задержки, то есть 3,5 мс). Кроме того, даже хотя мой домашний дисплей заявляет о скорости переключения 1 мс, ему в реальности требуется 10 мс для полного изменения цвета с момента начала этого процесса. Если сложить задержку от ожидания следующего кадра с задержкой реального изменения цвета, то мы получим ожидаемую задержку 7/2 + 10 = 13,5 мс.

На старых ЭЛТ-мониторах Apple 2e мы ожидаем задержку в половину от частоты обновления 60 Гц (16,7 мс / 2), то есть 8,3 мс. Сегодня такой результат трудно превзойти: самый лучший «игровой монитор» способен уменьшить задержку примерно до таких значений, но с точки зрения рыночной доли такие дисплеи установлены на очень небольшом количестве систем, и даже мониторы, которые рекламируются как быстрые, на самом деле не всегда являются таковыми.

Конвейер рендеринга iOS

Если посмотреть на все процессы между вводом и выводом, то для перечисления различий Apple 2e с современными компьютерами придётся написать целую книгу. Чтобы получить картину происходящего на современных машинах, вот высокоуровневый набросок того, что происходит на iOS, от инженера iOS/UIKit Энди Матущака, хотя он называет это описание «своими устаревшими воспоминаниями устаревшей информации»:

• У железа есть собственная частота сканирования (например, 120 Гц на последних тач-панелях), так что это добавляет задержку до 8 мс.
• События поступают в ядро через прошивку; это относительно быстрый процесс, но системный шедулинг может добавить здесь пару миллисекунд.
• Ядро направляет эти события привилегированным подписчикам (в данном случае backboardd) через порт Mach; здесь вероятны дополнительные потери на шедулинг.
• backboardd определяет, каким процессам следует доставить эти события; тут требуется блокировка по отношению к Window Server, который делится этой информацией (снова обращение к ядру, дополнительная задержка на шедулинг).
• backboardd отправляет событие нужному процессу; дополнительная задержка на шедулинг перед обработкой.
• События удаляются из очереди в основном потоке; а там может ещё что-то происходить (например, в результате сетевой активности или событий по таймеру), что может добавить задержку, в зависимости от активности.
• UIKit добавляет сверху 1-2 мс на обработку события, в зависимости от быстродействия процессора (CPU-bound).
• Приложение решает, что делать с поступившим событием; приложения написаны некачественно, так что обычно это занимает много миллисекунд, затем результаты компонуются в обновление (data-driven update) и отправляются на сервер рендеринга через IPC.
  • Если в результате обработки события приложению требуется новый видеобуфер в общей памяти, что происходит в любой нетривиальной ситуации, то происходит ещё один обмен данными по IPC с сервером рендеринга; это дополнительные задержки на шедулинг.
  • (Тривиальные вещи — это те, с которыми сервер рендеринга способен справиться самостоятельно, вроде изменений аффинного преобразования или изменения цвета слоёв; к нетривиальным относятся любые операции с текстом, большинство операций по растрированию и векторных операций).
  • Такого рода обновления часто создают тройной буфер: GPU может использовать один буфер для текущего рендеринга; сервер рендеринга — другой буфер для очереди на следующий фрейм; и третий для отрисовки. Здесь дополнительные блокировки (кросспроцессинг); дополнительные обмены данными с ядром.
• Сервер рендеринга добавляет поступившие обновления в дерево рендеринга (несколько миллисекунд)
• Каждые N Гц дерево рендеринга смывается в GPU, от которого требуется заполнить видеобуфер.
  • В реальности, впрочем, часто происходит тройная буферизация экранного буфера, по описанным выше причинам: отрисовка из GPU в одном буфере, а другой используется для чтения в подготовке следующего фрейма.
• Каждые N Гц этот видеобуфер заменяется на другой видеобуфер, и дисплей считывает напрямую из этой памяти.
  • (Эти N Гц не обязательно идеально сочетаются с N Гц на предыдущем шаге)

Энди говорит, что «объём работы здесь обычно довольно небольшой. Пару миллисекунд процессорного времени. Задержка после нажатия клавиш происходит по следующим причинам:»

• периодические сканирования (устройство ввода, сервер рендеринга, дисплей) неидеально сочетаются друг с другом
• многочисленные передачи через границы процессов, каждый раз с вероятностью задержки из-за обработки какого-нибудь постороннего события в очереди
• многочисленные блокировки, особенно на границах процессов, требуют обращения к ядру

Для сравнения, на Apple 2e нет практически никаких передач, блокировок и границ процессов. Работает очень простой код, который записывает результат в память дисплея, и тот автоматически отображается при следующем обновлении экрана.

Частота обновления и время отклика

Одна интересная вещь в тестировании времени отклика на компьютерах — это влияние частоты обновления экрана. При переходе с 24 Гц на 165 Гц мы ускоряемся на 90 мс. На 24 Гц отображение каждого кадра занимает 41,67 мс, а на 165 Гц — 6,061 мс. Как мы видели выше, без буферизации средняя задержка при обновлении фрейма составила бы 20,8 мс в первом случае и 3,03 мс во втором (поскольку мы ожидаем поступления кадра в случайной точке, а время ожидания случайно распределяется между 0 мс и максимальным временем ожидания), то есть разница составляет около 18 мс. Но в реальности разница 90 мс, что подразумевает задержку на (90 − 18) / (41,67 − 6,061) = 2 фрейма из буфера.

Если составить график результатов времени отклика с разной частотой обновления экрана на одной машине (здесь его не публикуем), то он примерно совпадает с кривой «наилучшего соответствия», если предположить, что при запуске PowerShell на этой машине задержка составляет 2,5 фрейма независимо от частоты обновления. Это позволяет оценить, какая получится задержка, если на игровой компьютер с малым временем отклика поставить дисплей с бесконечной частотой обновления — она ожидается в районе 140 − 2,5 * 41,67 = 36 мс, это почти так же быстро, как на компьютерах 70-х и 80-х.

Сложность

Почти каждый компьютер или мобильное устройство сегодня медленнее, чем типичные компьютеры 70-х и 80-х. Игровые десктопы с низким временем отклика и iPad Pro могут сравниться с быстрыми машинами 30-40-летней давности, но большинство коммерческих моделей даже близко не стоят.

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

К сожалению, намного труднее это сделать в реальности, чем заявить со сцены. Сложность зачастую даёт нам определённые выгоды прямо или косвенно. Когда мы сравниваем ввод данных с модной современной клавиатуры и с клавиатуры Apple 2, то видим лишние задержки на обработку данных с клавиатуры мощным и ресурсоёмким процессором, по сравнению со специализированными логическими схемами для клавиатуры, которые проще и дешевле. Но использование процессора даёт возможность легко настраивать клавиатуру, а также переносит проблему «программирования» клавиатуры с аппаратной части на софт, что снижает стоимость производства клавиатур. Более дорогой чип увеличивает стоимость производства, но с учётом всех расходов на дизайн этих полукустарных мелкосерийных клавиатур, в целом выглядит так, что экономия от простого программирования перевешивает дополнительные расходы.

Мы видим такого рода компромиссы на каждом этапе конвейера. Нагляднее всего сравнение ОС на современном десктопе с циклом на Apple 2. Современные ОС позволяют программистам писать стандартный код, который будет работать одновременно с другими программами на той же машине, с довольно разумной общей производительностью, но за это мы платим огромную цену в увеличении сложности, а вовлечённые в многозадачность процессы легко приводят к значительному увеличению времени отклика.

Значительную часть сложности можно назвать случайной сложностью, но она присутствует здесь тоже в основном из-за удобства. На каждом уровне от аппаратной архитектуры и интерфейса syscall до фреймворка ввода-вывода мы наращиваем сложность, львиную долю которой можно устранить, если сегодня сесть и переписать все системы и их интерфейсы. Но слишком неудобно заново изобретать Вселенную для снижения сложности, а рост экономики даёт прибыль, так что мы живём с тем что имеем.

По этим и другим причинам на практике проблема снижения производительности, которая возникла из-за «излишней» сложности, часто решается ещё бóльшим усложнением системы. В частности, те достижения, которые позволили нам приблизиться к самым быстрым машинам 30-40-летней давности, получены не благодаря следованию увещеваниям об уменьшении сложности, а именно от дополнительного усложнения систем.

iPad Pro — это подвиг современного инжиниринга, где разработчики увеличили частоту обновления на устройствах и ввода, и вывода, а также оптимизировали программный конвейер для устранения ненужной буферизации. Дизайн и производство экранов с высокой частотой обновления, которые уменьшают время отклика — это нетривиально более сложная задача во многих отношениях, которые были необязательны во времена архаичных стандартных дисплеев на 60 Гц.

В реальности это обычное дело при попытке уменьшить задержку. Самый популярный трюк для этого — добавить кеш, но добавление кеша в систему увеличивает её сложность. Для систем, которые генерируют новые данные и не допускают использования кеша, предлагаются ещё более сложные решения. В качестве примера можно привести крупномасштабные системы RoCE. Они способны сократить задержку доступа к удалённым данным с миллисекунд до микросекунд, что открывает двери для нового класса приложений. Но это сделано за счёт увеличения сложности. Разработка и грамотная оптимизация первых крупномасштабных систем RoCE занимала десятки человеко-лет и требовала огромных усилий операционной поддержки.

Заключение

Выглядит немного парадоксально, что современная игровая машина, которая работает в 4000 раз быстрее Apple 2, где на процессоре в 500 000 раз больше транзисторов (а в GPU — в 2 000 000 раз больше транзисторов) с трудом выдаёт такую же скорость отклика, как Apple 2 — и то лишь в аккуратно написанных приложениях и только на мониторе с трёхкратной частотой обновления по сравнению с Apple 2. Ещё более абсурдно, что в PowerSpec G405 с конфигурацией по умолчанию — самом быстром компьютере по однопоточным вычислениям до октября 2017 года — задержка от нажатия клавиши до вывода на экран (примерно один метр, может, три метра реального кабеля) превышает время передачи пакета вокруг земного шара (26 000 км от Нью-Йорка через Лондон до Токио и обратно в Нью-Йорк).

С другой стороны, мы явно выходим из тёмных времён огромных задержек — и сегодня уже можно собрать компьютер или купить планшет с временем отклика в том же диапазоне, что у стандартных машин в 70-е и 80-е. Это немного напоминает тёмные времена разрешений экранов и размера пикселей, когда ЭЛТ-мониторы 90-х годов до относительно недавнего времени имели лучшие характеристики, чем стандартные ЖК-дисплеи настольных компьютеров. Сейчас наконец-то стали обычными дисплеи 4k, а дисплеи 8k опустились до нормальных цен — это не идёт ни в какое сравнение с коммерческими ЭЛТ-мониторами. Не знаю, произойдёт ли такой же прогресс со временем отклика, но будем надеяться на это.

Другие статьи об измерении отклика

• Отклик консоли
• Отклик клавиатуры
• Отклик мыши против клавиатуры (человеческие факторы, не характеристики устройств)
• Отклик редактора (Павел Фатин)
• Задержка на компоновку в Windows 10 (Пекка Ваананен)
• Отклик AR/VR (Майкл Эбраш)
• Стратегии смягчения последствий задержки (Джон Кармак)

Приложение: зачем замерять время отклика?

Отклик очень важен! В очень простых задачах люди способны различать отклик до 2 мс или меньше. Более того, увеличение задержки не только заметно пользователям, но и является причиной менее точного выполнения простых задач. Если хотите наглядной демонстрации, как выглядит задержка, а у вас нет старого компьютера под рукой, вот демо MSR по задержке тачскрина.

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

Приложение: клавиатура Apple 2

Вместо программируемого микроконтроллера для считывания нажатий клавиш в Apple 2e используется гораздо более простой специализированный чип, спроектированный для считывания клавиатуры, AY 3600. В документации AY 3600 указано время сканирования (90 * 1/f), а время повторного нажатия клавиши указано как strobe_delay. Эти параметры задаются несколькими конденсаторами и резистором на 47 пФ, 100K Ом и на 0,022 мкФ. Если вставить эти параметры в формулу из документации AY3600, то получим f = 50 кГц, что даёт задержку сканирования 1,8 мс и задержку повторного нажатия клавиши 6,8 мс (конденсаторы могут деградировать со временем, так что на нашем старом Apple 2e реальные задержки могут быть меньше), что даёт задержку 8,6 мс для внутренней клавиатурной логики.

Если сравнить с клавиатурой на 167 Гц с двумя дополнительными проходами для определения повторных нажатий, эквивалентный параметр выходит 3 * 6 мс = 18 мс. С частотой сканирования 100 Гц получается 3 * 10 мс = 30 мс. Сканирование клавиатуры за 18-30 мс с дополнительной задержкой на повторное нажатие клавиш соответствует предварительным реальным измерениям времени отклика клавиатур.

Для справки, в клавиатуре Ergodox работает микроконтроллер на 16 МГц примерно с 80 тыс. транзисторов, а компьютере Apple 2e работает центральный процессор на 1 МГц с 3500 транзисторов.

Приложение: экспериментальная установка

Большинство измерений произведено на камеру 240 FPS (разрешение 4,167 мс). Устройства с временем отклика менее 40 мс были повторно измерены камерой на 1000 FPS (разрешение 1 мс). Результаты в таблицах являются результатом усреднения по итогу нескольких измерений и округлены до десяти, чтобы избежать впечатления ложной точности. Для настольных компьютеров время отклика соответствует времени от начала движения клавиши до окончания обновления экрана. Обратите внимание, что это отличается от большинства измерений key-to-screen-update, которые можно найти в интернете — в этих бенчмарках обычно используются установки, которые эффективно устраняют любую задержку клавиатуры. В качестве теста от начала до конца это реалистично только в том случае, если у вас установлена телепатическая связь с компьютером (хотя в таких измерениях тоже есть польза — если вам как программисту нужен воспроизводимый бенчмарк, то хорошо в тесте избавиться от факторов, которые находятся вне вашего контроля, но для конечных пользователей это не так).

Люди часто выступают за измерение одного из параметров: {нажатие клавиши до конца, срабатывание переключателя}. Кроме удобства, больше нет особых причин измерять что-либо из этого, но люди часто выдают эти результаты за «реальную» работу клавиатуры. Но они не зависят от реального времени срабатывания переключателя. Время между нажатием и активацией, также как время между ощущением отклика и активацией, произвольны и доступны для настройки. Когда тестер заявляет, что это «реальное» ощущение пользователя от срабатывания клавиатуры, это в общем означает, что пользователь не понимает принципов работы клавиатуры. Хотя такое возможно, я не вижу причин транслировать одно конкретное заблуждение о работе клавиатур в конкретную метрику, где люди яростно выступают за разные неверные убеждения. Более подробно о заблуждениях относительно клавиатур см. эту статью с измерениями времени отклика.

Ещё одно важное отличие — то, что измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д. Ожидание окончания обновления экрана тоже отличается от того, что измеряется в большинстве бенчмарков — большинство полагают, что обновление «закончено», когда регистрируется любое движение на экране. Ожидание завершения обновления аналогично времени «визуального завершения» в WebPagetest.

Результаты на компьютерах получены в консоли «по умолчанию» для данной системы (например, PowerShell на Windows, LXTerminal на Lubuntu), что легко может означать разницу в 20-30 мс между быстрой и медленной консолями. Между измерениями в консоли и измерением полного времени от начала до конца, результаты в этой статье должны быть медленнее, чем в других статьях на эту тему (где часто замеряется время до начала изменений на экране в играх).

Базовый результат PowerSpec G405 получен на встроенной графике (машина продаётся без видеокарты), а результат с 60 Гц — с дешёвой видеокартой.

Результаты для мобильных устройств получены в браузере по умолчанию после загрузки сайта https://danluu.com и замера задержки от движения пальца до первого перемещения картинки на экране, что сигнализирует о начале прокрутки. В тех случаях, когда такой тест не имел смысла (Kindle, Gameboy Color и др.), были сделаны другие осмысленные действия на этой платформе (перелистывание страницы на Kindle, нажатие джойстика в игре на Gameboy Color и т.д.). В отличие от измерений на десктопе или ноутбуке, эти измерения были до первого изменения на экране, чтобы избежать многих фреймов прокрутки. Для простоты измерений палец изначально касался экрана, а таймер включался, когда он начинал движение (чтобы избежать проблем с определением времени касания пальцем экрана).

В случае «равных» результатов порядок сортировки в таблице определялся по неокруглённому времени задержки, но это не следует считать важным фактором. Отличие на 10 мс тоже не следует считать значительным.

Машина на Haswell-E тестировалась и с включенной опцией G-Sync — заметной разницы не зафиксировано. Год выпуска для этого компьютера установлен в каком-то смысле произвольно, поскольку процессор 2014 года выпуска, а дисплей более новый (думаю, до 2015 года дисплеев на 165 Гц ещё не было).

Количество транзисторов на некоторых современных машинах приведено примерно, потому что точные цифры не разглашаются. Не стесняйтесь сообщить мне, если найдёте более точную оценку!

Все результаты под Linux сделаны на ядре до KPTI. Возможно, KPTI повлияет на задержку.

Работа ещё не закончена. Я собираюсь собрать бенчмарки с большего количества старых компьютеров во время следующего визита в Сиэтл. Если вы знаете о старых компьютерах, которые можно потестировать в районе Нью-Йорка (с оригинальными дисплеями или вроде того), дайте знать! Если у вас есть устройство, которое вы готовы пожертвовать для тестов, можете высылать на мой адрес:

Dan Luu
Recurse Center
455 Broadway, 2nd Floor
New York, NY 10013

Автор: m1rko

Источник