| Компьютер | Отклик (мс) |
Год | Тактовая частота |
Кол-во транзисторов |
|---|---|---|---|---|
| Apple 2e | 30 | 1983 | 1 МГц | 3,5 тыс. |
| TI 99/4A | 40 | 1981 | 3 МГц | 8 тыс. |
| Haswell-E 165 Гц | 50 | 2014 | 3,5 ГГц | 2 млрд |
| Commodore Pet 4016 | 60 | 1977 | 1 МГц | 3,5 тыс. |
| SGI Indy | 60 | 1993 | 0,1 ГГц | 1,2 млн |
| Haswell-E 120 Гц | 60 | 2014 | 3,5 ГГц | 2 млрд |
| ThinkPad 13 ChromeOS | 70 | 2017 | 2,3 ГГц | 1 млрд |
| iMac G4 OS 9 | 70 | 2002 | 0,8 ГГц | 11 млн |
| Haswell-E 60 Гц | 80 | 2014 | 3,5 ГГц | 2 млрд |
| Mac Color Classic | 90 | 1993 | 16 МГц | 273 тыс. |
| PowerSpec G405 Linux 60 Гц | 90 | 2017 | 4,2 ГГц | 2 млрд |
| MacBook Pro 2014 | 100 | 2014 | 2,6 ГГц | 700 млн |
| ThinkPad 13 Linux chroot | 100 | 2017 | 2,3 ГГц | 1 млрд |
| Lenovo X1 Carbon 4G Linux | 110 | 2016 | 2,6 ГГц | 1 млрд |
| iMac G4 OS X | 120 | 2002 | 0,8 ГГц | 11 млн |
| Haswell-E 24 Гц | 140 | 2014 | 3,5 ГГц | 2 млрд |
| Lenovo X1 Carbon 4G Win | 150 | 2016 | 2,6 ГГц | 1 млрд |
| Next Cube | 150 | 1988 | 25 МГц | 1,2 млн |
| PowerSpec G405 Linux | 170 | 2017 | 4,2 ГГц | 2 млрд |
| Пакет вокруг света | 190 | |||
| PowerSpec G405 Win | 200 | 2017 | 4,2 ГГц | 2 млрд |
| Symbolics 3620 | 300 | 1986 | 5 МГц | 390 тыс. |
Две последние колонки показывают тактовую частоту и количество транзисторов на процессоре.
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.
Если посмотреть на результаты в целом, то самые быстрые — это древние машины. Более новые компьютеры встречаются во всех частях таблицы. Замысловатые современные игровые конфигурации с необычно высокой частотой обновления экрана почти могут составить конкуренцию машинам конца 70-х и начала 80-х, но «обычные» современные компьютеры не способны конкурировать с компьютерами 30-40-летней давности.
Можно ещё посмотреть на мобильные устройства. В этом случае замерим отклик прокрутки в браузере:
| Устройство | Отклик (мс) | Год |
|---|---|---|
| iPad Pro 10,5" Pencil | 30 | 2017 |
| iPad Pro 10,5" | 70 | 2017 |
| iPhone 4S | 70 | 2011 |
| iPhone 6S | 70 | 2015 |
| iPhone 3GS | 70 | 2009 |
| iPhone X | 80 | 2017 |
| iPhone 7 | 80 | 2017 |
| iPhone 6 | 80 | 2014 |
| Gameboy Color | 80 | 1989 |
| iPhone 5 | 90 | 2012 |
| BlackBerry Q10 | 100 | 2013 |
| Huawei Honor 8 | 110 | 2016 |
| Google Pixel 2 XL | 110 | 2017 |
| Galaxy S7 | 120 | 2016 |
| Galaxy Note 3 | 120 | 2016 |
| Nexus 5X | 120 | 2015 |
| OnePlus 3T | 130 | 2016 |
| BlackBerry Key One | 130 | 2017 |
| Moto E (2G) | 140 | 2015 |
| Moto G4 Play | 140 | 2017 |
| Moto G4 Plus | 140 | 2016 |
| Google Pixel | 140 | 2016 |
| Samsung Galaxy Avant | 150 | 2014 |
| Asus Zenfone3 Max | 150 | 2016 |
| Sony Xperia Z5 Compact | 150 | 2015 |
| HTC One M4 | 160 | 2013 |
| Galaxy S4 Mini | 170 | 2013 |
| LG K4 | 180 | 2016 |
| Пакет | 190 | |
| HTC Rezound | 240 | 2011 |
| Palm Pilot 1000 | 490 | 1996 |
| Kindle Paperwhite 3 | 630 | 2015 |
| Kindle 4 | 860 | 2011 |
Как и раньше, результаты отсортированы по времени отклика от самых быстрых к самым медленным.
Если исключить 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 до фреймворка ввода-вывода мы наращиваем сложность, львиную долю которой можно устранить, если сегодня сесть и переписать все системы и их интерфейсы. Но слишком неудобно заново изобретать Вселенную для снижения сложности, а рост экономики даёт прибыль, так что мы живём с тем что имеем.
По этим и другим причинам на практике проблема снижения производительности, которая возникла из-за «излишней» сложности, часто решается ещё бoльшим усложнением системы. В частности, те достижения, которые позволили нам приблизиться к самым быстрым машинам 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
Комментарии (123)
Cheater
26.12.2017 14:23Очень странный подход. Вы выносите итоговые результаты в таблицу под названием «время отклика устройств», а потом сами же и пишете в статье, что замеряете на самом деле время отклика самого устройства (железа) + время отклика эмулятора терминала (или простигосподи браузера), и сами же демонстрируете, что:
— второе значительно больше первого — железо откликается за время порядка <=10 мс, а софт от 30 до 100+ мс;
— браузер и эмулятор терминала, работающий напрямую с фреймбуфером, отличаются по скорости в разы (сюрприз).
Зачем тогда вообще сравнивать тёплое с мягким?
Ndochp
26.12.2017 15:21+1Так сравнивается же пользовательская характеристика: время отклика настольного компьютера. А что у него под капотом — дело десятое.
Cheater
26.12.2017 16:10Сравнивать её разными приложениями — некорректно. Более честно было бы, например, брать на каждом устройстве отклик самого быстрой виртуальной консоли из известных (/dev/tty думаю хорошо так обгонит lxterm), и то её быстродействие зависит от конфига ядра.
andreymal
26.12.2017 16:25По-моему как раз наиболее корректно сравнивать с тем, чем человек пользуется в повседневной работе. Лично я не сижу в /dev/tty и поэтому сравнение с ним для меня ничего не будет значить :) (Хотя, конечно, увидеть измерения /dev/tty в табличке всё равно будет любопытно)
Segmentq
27.12.2017 12:59Тогда надо было выводить одинаковый объем информации, а не символ. В данном случае раз проверка велась в консоли, то и логичнее было бы современные системы грузить с чистой консолью без всей лабуды (мы ведь сравниваем навороченность железа и время отклика?) А если речь о выводе пользовательской информации, то старые системы проигрывают хотя бы при выводе картинки. Учитываем что старые системы в связке железо — пользователь имели минимальное расстояние, а сейчас? фреймворк на фреймоворке, виртуальные машины в виртуальных машинах, там до железа… Так что все эти сравнения — полная чепуха.
andreymal
27.12.2017 13:04(мы ведь сравниваем навороченность железа и время отклика?)
Нет, мы сравниваем задержку, которую видит обычный пользователь на обычном (или почти обычном) компьютере в обычном для рассматриваемого компьютера окружении. Сравнивать голое железо нет никакого практического смысла, потому что голым железом никто (или почти никто) не пользуется. Вы же сами пишете этот комментарий через виртуальную машину в песочнице в фреймворке в нескольких абстракциях от железа, не так ли? :)
Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно
Segmentq
27.12.2017 13:12Так, об этом и речь, что основная задача старых систем и старого железа — был ввод информации от пользователя и вывод ее на экран, а современные помимо вышеописанной задачи в извращенной форме, занимаются еще тысячами других операций. Поэтому суммарный объем информации выводимый новым железом в стони раз превышает объем информации обрабатываемый и выводимый старым железом. Нет чистоты эксперимента. Там одна операция, а тут десятки и сотни тысяч, за то же время. Автор же строит таблицу и ведет к тому, что старые системы быстрее новых, но это сравнение в корне некорректно. Еще раз для пользователя: старое железо — один символ информации, новое железо — очень много информации.
И пишу тут комментарий, при этом работает проверка синтаксиса, всякие пунтосвитчеры, пишу не в консоли, а в браузере и т.п.andreymal
27.12.2017 13:19Ещё раз, в «чистоте эксперимента» нет никакого практического смысла, потому что никто не пользуется голым железом. Ещё раз, цель сабжа — измерение задержки, которую видит обычный пользователь в обычном окружении. Когда вы поставите «чистый эксперимент», это будет уже не обычное окружение.
Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?
Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
saboteur_kiev
26.12.2017 19:51+1А как насчет уточнить и сравнить скорость отклика у PS/2 и USB клавиатур отдельно?
MagisterLudi
26.12.2017 16:19Подозревать я стал год назад.
Я это «по-чувс-тво-вал».
Уже месяц я делюсь своими догадками с собеседниками. А вот теперь бесспорные доказательства:
==Современные компы тормозят сильнее старых.==
Особенно в «микротранзакциях».
Беда в том, что я заметил, что это отражается и на скорости мышления. «Думаю об компьютер».
Я купил себе 386-й.
Летает.
vin2809
26.12.2017 18:13А Вы MS DOS поставьте, так чтобы не улетел, будете якорь привязывать…
В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.
Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
MacIn
27.12.2017 04:42Как раз недавно запустил старый 233Мгц с MS-DOS/Win98, был удивлен тем, как тормозит ввод в консоли по сравнению с Core2. Понятно, что железо старое, но это было настолько явно видно, что удивило.
Dimezis
26.12.2017 17:01Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц
Понимаю, что это перевод, но чисто для уточнения:
есть много клавиатур, у которых частота опроса 1000Гц. Еще некоторое время назад читал статью, в которой тестировали Apple Magic Keyboard, и оказалось, что у них отклик быстрее чем у большинства разрекламированных механических клавиатур.
Так что справедливости ради, надо бы взять нормальную клавиатуру для теста.
AntonSor
26.12.2017 17:48Но… но… но как же? Получается, новые компы более тормозные, чем какой-то Apple 2 на проце 6502?
Cheater
26.12.2017 18:53Время отклика на нажатие клавиши — это лишь часть расплывчатой характеристики «быстродействие». В быстродействие ещё входит скорость обработки данных, скорость передачи данных (RAM, диск итд) и ещё куча всего.
Чудес не бывает, старые машины по производительности значительно слабее современных.
«Медленность» нового железа в статье на поверку оказалась медленностью софта и современных графических оболочек. Если портировать например ChromeOS и LXDE на Apple II, то lxterm там будет демонстрировать ровно такую же «медленность». Обратно, если на современном ПК нажать клавишу в голой консоли (tty), то подозреваю, что время отклика будет ровно такое же, как и в нативной консоли apple 2 — пара десятков мс.
khim
26.12.2017 22:48Они не более «тормозные». Они менее юркие. То же самое как с машинами.
Веспа полувековой давности с двигателеми в 100 кубов по параметру «время разворота» легко уделывает БелАЗ-75710 — несмотря на разницу в мощности в 1000 c лишним раз.
То же самое — и с компьютерами…
Costic
26.12.2017 17:48Я не вижу результатов работы системы ввода/вывода MS-DOS, зато вижу много рекламы надкусанного яблока. Ещё я не вижу FreeBSD. Лет 25 я бы уверенно сказал время отклика, т.к. его можно было посчитать. Средства MS-DOS медленно опрашивали клаву, поэтому для скорости напрямую работали с контроллером клавиатуры, там же таймер и пищалка были.
sshmakov
27.12.2017 09:03Средства MS-DOS не опрашивали клаву, в MS-DOS прилетало аппаратное прерывание от клавиатуры INT 09h (IRQ 1) по каждому нажатию и отпусканию клавиши.
maslyaev
26.12.2017 18:34+4Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов. Помню как в начале 1997-го года в фирму купили новейшее чудо техники Pentium 133, но котором Word к всеобщему восхищению открывался примерно за секунду. Сейчас на своём Core i7 померил ради интереса — 9 секунд. Только не говорите про возросшую функциональность. Она примерно такая же.
DistortNeo
26.12.2017 19:14Сейчас на своём Core i7 померил ради интереса — 9 секунд
У меня Word 2016 открывается за секунду. Комп собирал в начале 2011 года.
Только не говорите про возросшую функциональность. Она примерно такая же.
Различия в мелочах. Если перейти на MS Office 97, то окажется, что того нету, это неудобно, здесь от вообще падает и т.д.
maslyaev
27.12.2017 01:08Да всё есть и ничего не падает. Впрочем, риббона нет и после Ctrl-V мерзкая плашка "Ctrl" не повисает поверх текста.
То, чего не хватало в 97-м ворде, не хватает и сейчас.DistortNeo
27.12.2017 01:42Это мерзкой плашкой я пользуюсь постоянно — очень удобно.
А Office 97 падал значительно чаще.
creker
27.12.2017 02:19В какой-то момент надо переставать выдумывать «мерзости» и пробовать пользоваться.
Оно всегда так, привычка и нежелание менять уклад, даже если новое лучше по всем параметрам. Плашка эта очень удобная, т.к. содержит необходимые инструменты прямо рядом с курсором. Выделил текст — у тебя сразу все форматирование основное. Вставку сделал — сразу дается выбор удалить ненужное порой форматирование исходного текста.maslyaev
27.12.2017 10:38Вставку сделал — сразу хочу увидеть текст, который получился в результате. А тут какая-то левая фигня перед глазами болтается, перекрывая обзор.
Да, там есть одна полезная опция удаления ненужного форматирования. Вообще, в некоторых программах для этой цели сделано Ctrl+Shift+V. Дёшево и сердито. Без повисания на экране кусочка дерьма.
Кроме ухудшений и бессмыслицы, за прошедшие 20 лет, конечно, добавился некоторый набор мелких улучшайзингов. Глупо спорить. Но имейте в виду, что размер дистрибутива вырос более чем в 10 раз (прописью: десять грёбаных раз). Те улучшения, которые мы с трудом можем вспомнить, точно не стоят этого.ClearAirTurbulence
27.12.2017 13:07-1Так не обновляйтесь.
maslyaev
27.12.2017 13:13+1Бесконечные обновления всего и вся по большей части уже давно перестали быть добровольным делом.
sumanai
27.12.2017 16:17Ну вот, а когда я пишу, что сижу на XP x64, мне предгалают обновить ОС на «по современнее».
DistortNeo
27.12.2017 16:26Пишите, что сидите на Windows Server 2003.
sumanai
27.12.2017 16:30У меня от неё обновления стоят, но и те уже закончились. Или серверность ОС даёт +10 к очкам популярности у гиков? Так как эти ОС братья близнецы.
DistortNeo
27.12.2017 16:41+1Нет, просто Windows XP 64 bit имеет с Windows XP столько же общего, сколько, скажем, Windows 7 — с Windows Vista.
sumanai
27.12.2017 17:05Про близнецов я имел в виду ХР х64 и 2003 сервер. Хотя версия ядра ХР х64 (5.2) и ХР х86 (5.1) явно намекают на их тесное родство, ровно так же в случае семёрки (6.1) и висты (6.0).
nikolayv81
27.12.2017 20:59Интересная идея, тут нужно было поставить vs 2017 на комп на котором нет интернета, оказывается имея поставку в 20+Гб это невозможно сделать без сети, да в теории это сделать можно для этого нужно сделать несколько нетривиальных действий (конечно не в gui) на компе с инетом, потом перенести данный архив на нужное место и уже потом запустить специальным образом. Это я к тому что даже в enterprise версиях всё сделано так чтобы было крайне неудобно обновляться.
khim
27.12.2017 22:14Почему «в теории»? У меня была поставка на 34Gb и она отлично ставилась без сети.
philosophocat
26.12.2017 22:11В порядке предположений: возросла длина цепочки обратной совместимости, добавился отвечающий за работоспособность на разных платформах код, появилась проверка/отсылка чего-то в интернет при запуске…
maslyaev
27.12.2017 01:12У нас, человеков, лучше всего получается придумывать объяснения и оправдания. Да, если весь софт по мере взросления становится тормозным и глючным, то Ворд, надо признать, ещё неплохо держится.
ValdikSS
28.12.2017 02:24Для меня каноничным примером является программа для записи образов дисков Etcher. Она написана на Javascript (Electron) и мало того, что ее размер 60 МБ, она отправляет метрику об использовании.
Десктопная программа для записи дисков. И отправляет метрику об использовании (телеметрию). И, конечно же, проверяет обновления при каждом запуске, как же без этого.
github.com/resin-io/etcher/issues/1878
github.com/resin-io/etcher/issues/1772
Из-за того, что используется достаточно сильное, но не быстрое сжатие LZMA для портативной Linux-версии (appimage), программа стартует достаточно длительное время, примерно 4 секунды на моем компьютере, и использует 88 МБ RAM сразу после запуска.
Вот и получается, что у нас быстрые компьютеры, но реальные задачи выполняются очень не быстро, из-за неподходящих инструментов разработки (Javascript и Electron с chromium и ffmpeg — неподходящий инструмент разработки программ для компьютера!) и накладных расходов.ValdikSS
28.12.2017 02:36И, стоит заметить, я понимаю, почему разработчики выбирают Electron — у нас просто нет нормальных средств разработки кроссплатформенных графических программ для компьютера.
Программа будет либо выглядеть некрасиво или вовсе уродско (Java с JavaFx), либо придется писать GUI с учетом конкретных фреймворков в каждой системе (Mono c Windows Forms, GTK# и MonoMac соответственно), либо писать на интерпретируемых или небезопасных языках, со своими сложностями обработки графических событий (Qt и байндинги к нему).
musicriffstudio
28.12.2017 09:32у нас просто нет нормальных средств разработки кроссплатформенных графических программ для компьютера
скорей нет дешёвых специалистов по ЮИ, а программисты сами рисовать не умеют поэтому вынуждены использовать только готовые компоненты (да и тут у них с красивыи ГУИ как-то не очень).
sumanai
28.12.2017 16:56А какой смысл использовать подобного монстра? Я лет десять диски не писал, но в своё время юзал программы на пару мегабайт весом.
ValdikSS
28.12.2017 17:08Эта программа для записи образов HDD на флешки или HDD. Что-то вроде dd с gui, и возможностью записи сжатых образов без предварительной распаковки.
eps
29.12.2017 07:21Не было программы, которая бы просто и хорошо работала в любой ОС.
Here at resin.io we have thousands of users working through our getting started process and until recently we were embarassed about the steps that involved burning an SD card. There was a separate track for each Mac/Windows/Linux and several manual and error-prone steps along the way.
To our surprise there was nothing out there that fitted our needs. So we built Etcher, a SD card burner app that is simple for end users, extensible for developers, and works on any platform.
eps
29.12.2017 07:28Особенно впечатляет etcher-cli, у которого даже GUI нет, но она всё равно весит 68 МБ (Windows AMD64) или даже все 78 МБ (Linux AMD64).
Клон dd — в 2400 раз больше оригинала! И во много раз тормознее, скорее всего
censor2005
26.12.2017 22:50Кстати я тоже заметил такое. В колледже, в 2004 у нас стояли машины с 256Мб памяти и Office то ли XP то ли 2000. Word открывался субъективно за секунду. Сейчас померил скорость открытия Word 2013 (Core i3, Windows 10, SSD) — открылся за 5-6 секунд.
arheops
27.12.2017 03:29Тогда ворд запускал «preloader» как стандарт. Сейчас он этого не делает. И правильно.
arheops
27.12.2017 03:39У вас чтото не то.
x230, i7-3520M, на минимальной частоте 2.9, word 2013,samsung 850 evo — меньше секунды. засекать не получается.
то же самое в режиме energy saver(отключение ssd, все шины на миниуме, от батареи) — от 1.5 до 3.5 секунд
x220 i5 2520M, samsung 850 evo, 1.5-2.5 секунды.
вот вам кстати, разница в кеше которая «не важна».
khim
26.12.2017 22:50Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов.
Закон Вирта?
creker
26.12.2017 22:53Сейчас на своём Core i7 померил ради интереса — 9 секунд
У меня ворд 2013 открывается за секунду на i5 4670. Таки SSD поставить стоит. Ворд не столько кода выполняет много, сколько обращений к диску.
Только не говорите про возросшую функциональность. Она примерно такая же.
Т.е. номер версии просто так менялся все эти десятилетия? Функционала там вагоны нового. Для вас оно примерно так же, потому что вы используете его скорее всего как Wordpad какой-нить. Конечно с тех времен ничего не удаляли, а только прибавляли.MacIn
27.12.2017 04:48Таки SSD поставить стоит.
Да, I/O значит очень много.
Действительно, во времена 97 офиса на 98 винде Word открывался быстрее, чем на моем Core2 сейчас (5-15 с в зависимости от размера документа). В моем случае все «потуги» вызваны глючными драйверами Lenovo, которые неправильно отрабатывают Hibernate. Хотя жить от этого знания не легче.
niko1aev
26.12.2017 22:59Проверил запуск на MacBook
MS Word — 1.83s
Pages — 0.75s
Данные усреднены по 3-м попыткам.
Время засекалось кустарно, секундомером на iPhone. Стоп нажимал после того как увидел открывшееся приложение.
К сравнению, самое быстрое двойное нажатие, которое я смог сделать на секундомере это 0.08 секунд. 0,10 получилось сделать раза два, остально 0,12 +
Уж не знаю, где там Word открывается 9 секунд.
А вот то, что меня расстроило, так это то, что новая вкладка в терминале с ZSH открывается 1.15 секунды. Открывал новую вкладку как только видел строку ввода, 20 раз, получил 23 секунды. Закрыл 40 штук за 11 секунд, или 0,28 на вкладку. Значит думает комп как минимум 0,87c. Над новой вкладкой. Карл!
За это время мое приложение успевает сбегать 2 раза в базу, выгрузить 2000 сущностей, посчитать рейтинг, и все это 145 раз! (6ms на итерацию). Хммммммммм… интересноcreker
26.12.2017 23:04Тоже самое замечал со вкладками и тоже ZSH. Не засекал, но ощущалось это очень долго и точно счет на секунды идет. Скорее всего надо смотреть, чего там напихано в .zshrc. У меня установлен oh my zsh, и он периодически лезет проверять обновления на github
Quarc
27.12.2017 17:03Наверное стоит учитывать и время реакции, с момента когда увидели строку ввода до нажатия на Cmd+T, порядка 0.2 * 20 = 4 с.
AllexIn
26.12.2017 23:01Только не говорите про возросшую функциональность. Она примерно такая же.
Конечно. И у Visual Studio 2017 функциональность примерно такая же как у Visual Studio 6.
Но вообще-то нет.
Пользователь как правило не видит что что-то изменилось в лучшую сторону. Это воспринимается как само собой разумеющееся. Зато точно видит, что «раньше не тормозило».MacIn
27.12.2017 04:49Зато точно видит, что «раньше не тормозило».
Справедливости ради, в повседневной деятельности «чтобы не тормозило» может быть намного важнее нового функционала. Какой толк с нового функционала, например, если при «жизни по-новому» автодополнение в коде думает секунд 10? (Реальный случай).
aaalllsss
27.12.2017 17:27давайте вордами меряться, у меня rizen 1600 + ssd, ворд запустился за секунду
PavelBelyaev
28.12.2017 11:53Может быть, это объясняется тем, что HDD особенно не ускорились 80-100 Мб/сек, при этом нагрузка на дисковую систему со стороны ОС и другого ПО сильно возросла и объемы загружаемого ПО тоже выше. А так, на хорошем SSD (особенно PCI-e) всё за секунду открывается, даже Photoshop.
maslyaev
28.12.2017 12:02Да, именно этим и объясняется. Но в сухом остатке мы имеем то, что сумасшедший прогресс не отменяет существенное ухудшение пользовательских характеристик.
KirEv
26.12.2017 23:09Простите, накипелоПрогресс на лицо *sarcasm enabled*
Из нового ПО, которое использую на компе (ос windows): VM Ware, IDE (php, go). — все, за 10 лет нового не добавилось… фотошоп, ворд, и т.п. чем пользовался ранее…
Но если раньше, мой первый комп с 16+32 мб ОЗУ, веником 1.2Гб, цпу пень 166ммх — справлялся с своей работой — то сейчас просто пипец…
На компе 8гб озу — достаточно хром два дня не закрывать — жрет 3-4гб, куда — не ясно, несколько вкладок, даже ютуба нет… другие программы — тоже прожорливые… пока не купил ssd — лагов было больше чем хотелось…
На ноуте 16гб озу — тоже часто под завязку память забита…
купил топовый дорогущий ноут, 32гб озу, i7 последний, крутая видяха и большой sdd — скорость работы приложений если и изменилась — то не существенно, так как запуская теже IDE что на компе 5ти летней давности, что на ноуте топовом 2017г выпуска — ни визуально ни по ощущениям не изменилась…
Раньше память была дорогая, сейчас доступно много и дешево, если считать дешевой цену за планку в 8гб от 100у.е…
Похоже мало кто беспокоится о производительности, лично видел и **уевал, когда чел запилил обработку данных: вытащить все-все из БД в массив, и NxN раз проходил по огромному массиву что-бы там чтото выудить… вместо написания алгоритма, который в 1 проход сделает нужно задачу + sql-запрос соответствующий.
Оно конечно круто, камень over 4Ghz, для ДОМАШНИХ пк, по цене over $1k, но, простите, для каких таких домашних задач нужен проц за 1к у.е.?
Иногда кажется, а может и не кажется, но нас маркетологи где-то на*бывают.
t13s
27.12.2017 10:38Так а вы зачем тогда, простите, новыми версиями софта пользуетесь? Работайте с тем, с чем справлялся ваш первый комп, и будет счастье. Раз, как вы говорите, не меняется ничего.
maslyaev
27.12.2017 11:01В старых версиях браузеров, например, новые сайты не работают. Office 97, например, не открывает xlsx. От нового монструозного, тормозного и глючного софта никуда не деться. Мы вынуждены его использовать.
Одна радость души моей — 5-й WinAmp 2007-го года выпуска…t13s
27.12.2017 11:34Для 2000 офиса, который от 97 недалеко ушел, есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться.
Ну и новые сайты не работают не по причине какого-то сговора сайтостроителей, а потому что за прошедшее время появилась куча всяких свистелок в веб-стандартах, которым, сюрприз, нужны ресурсы.
А потому немножко некорректно говорить, что софт становится тормознее без каких-то функциональных изменений.maslyaev
27.12.2017 13:01есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться
Я не знаком ни с кем, кто горел бы желанием пользоваться этим самым Compatibility Pack. Но что-то подсказывает мне, что это не потому, что все влюбились в риббон.
куча всяких свистелок в веб-стандартах
Там вообще адъt13s
27.12.2017 13:20Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то? Или все-таки будем честны и скажем, что работает в них не всё, и не так, как того хочется? И, полагаю, проблема не в том, что на фоне идеального 2000-го офиса Compatibility Pack (и только Compatibility Pack) оказался кривой поделкой?
(Риббоны в офисе — это вообще офигенная штука, и как раз из-за них в свое время переходил на новую версию. Ну и из-за смарт-артов ещё.)
В вебе адищще, соглашусь. Но проблема тут не в браузерах как таковых, а в JS-ных поделиях по большей части, из-за чего браузерам пришлось как-то выкручиваться, чтобы всю эту хрень корректно и не очень медленно отображать. Полагаю, что если в новых браузерах открывать странички производства девяностых-двухтысячных годов, то и на старом железе тормозов не будет.khim
27.12.2017 13:33Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то?
В старых офисах всё хорошо, за исключением одной проблемы: совместимости с новыми. И поскольку люди этими новыми фичами реально пользуются, то деваться некуда — приходится «жрать кактус».
Вот с текстовыми редакторами подобной проблемы не случается — и там таки да, вполне можно пользоваться VIM'ом и Emacs'ом хоть 30-летней давности… впрочем современные версии ничуть не тормознее, так что смысла выискивать старые версии нет…
И, полагаю, проблема не в том, что на фоне идеального 2000-го офиса Compatibility Pack (и только Compatibility Pack) оказался кривой поделкой?
Не знаю кто или что там кривое, но в 2000м офисе .xlsx-документы очень часто неправильно отображаются. Может быть проблемой Compatibility Pack'а, MS Office 2016 (который автоматически использует какие-то фичи, отсутствующие в MS Office 2000 без ведома авторов), но это точно не проблема MS Office 2000 — он сам про .xlsx ничего не знает.
А так — до выхода и широкого распространения MS Office 2013/MS Office 2016 я только MS Office 2000 и пользовался…
vlivyur
28.12.2017 15:38Риббоны в офисе — недоведённая до ума офигенная штука. Если раньше что-то было в один клик доступно, то сейчас в 3-4 — офигеть удобство. Если раньше был нормальный пункт меню, то сейчас поле 15x15 пикселей — ты сможешь! я в тебя верю!
maslyaev
27.12.2017 11:27Маркетологи, конечно, тоже руку приложили, но зло не только в них. Проблема, мать её, сложности. Технологии таковы, что с ростом функциональности сложность растёт сильно нелинейно. Каждая софтина дорастает до состояния, когда каждая новая фичечка реализуется только через чудовищно неприемлемое усложнение.
Для меня эталоном сложностного тупика в своё время стала айбиэмовская вебсфера. Задача, которую она решает, проста и примитивна. Менеджер очередей сообщений. По сути, система почтовых ящиков. Неплохая тема для дипломного проекта в каком-нибудь ВУЗе средней руки. Как-то в цейтноте и безвыходняке я нечто подобное в наколеночном варианте набросал за вечер. Но… размер дистрибутива под 500МБ, и ресурсы жрёт так, будто исходит из предположения, что комп, на который оно установлено, больше ни для чего, кроме решения этой мелкой сугубо технической задачи, использоваться не будет. Когда-то оно наверняка тоже было маленьким и шустрым, а потом кабанело, кабанело и окончательно закабанело.
BosonBeard
27.12.2017 00:59Может быть это глупый ночной вопрос, но что такое «Пакет вокруг света» в первой таблице? (статью прочитал по диагонали может быть не нашел).
А в остальном спасибо, очень любопытное исследование!khim
27.12.2017 02:42Из статьи:
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.
А вообще статьи пишут, чтобы их читали… Но видимо так — уже не модно.BosonBeard
27.12.2017 14:40Во-первых, несмотря на то, что статья любопытная, она все же не входит напрямую в сферу моих личных или профессиональных интересов, поэтому, как было сказано выше, я прочитал ее «по диагонали». Если вы привыкли всё что попадает в поле вашего зрения читать «от корки до корки» это ваше право я на него не претендую.
Во-вторых, спасибо за приведенную выше цитату, я её действительно не разглядел. Думаю, если бы автор изложил ее в следующем виде:
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон. (п. табл. «Пакет вокруг света»)
то у меня бы вообще вопросов не возникло.
P.S. У людей может быть разное восприятие мира. Например, у меня в голове в час ночи фраза: «Пакет вокруг света» выглядит следующим образом.
DarkTiger
27.12.2017 01:14События поступают в ядро через прошивку
Немного аккуратнее надо переводить :) Понятно, что кратко этот процесс описать нельзя, но…
Можно оригинал статьи посмотреть? Линк только на homepage сайта
Dee3
27.12.2017 01:18Помоему очень важная тема затронута в статье: сейчас выходит все именно так, что у нас есть все возможности и технологии делать быстрые интерфейсы, но в общем то индустрия занимается ерундой, а потребителям оно вообще не надо.
В пользу этой версии говорят чуть ли нее все автомобильные интерфейсы ( а там это еще и безопасность) и вообще весь рынок смартфонов на Andoroid. (я лично протестировав кучу флагманов за последние три года так и не смог найти хотя бы одного с отзывчивостью хотя бы iPhone 4)
Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.creker
27.12.2017 01:24iPhone 4? Он давно перестал быть отзывчивым, 2 или 3 версии iOS назад как. А отзывчивый андроид легко найти — любой современный топовый девайс можно взять.
MacIn
27.12.2017 04:52А что такого случилось 2 или 3 версии назад, что 4ка перестала быть отзывчивой?
batyrmastyr
27.12.2017 09:52Вышла iOS 8 — эпичный тормоз, да и 10 с 11 скоростью не радуют, 9 ещё куда ни шло, но тоже сильно отставала от 7-й по отзывчивости. Это из личного опыта на 5s, а так владельцы 4s жаловались на тормоза при смене 6 iOS на 7.
Dee3
27.12.2017 10:12Говоря про отзывчивость я имею ввиду отклик на простейшие действия (нажатия, свайпы) Разница в этих действиях между версиями iOS даже на старых девайсах минимальна.
А вот со скоростью загрузки приложений тут да, ничего не попишешь.
Речь то была все таки про отклик, и про то что большинству оно в общем то и не нужно, либо не замечают. А при попытке продемонстрировать это, пользователи медленных девайсов включают защитную реакцию. Вон посмотрите на минусованый комментарий ниже.
khim
27.12.2017 02:48Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
Замечают. Но тот 1% пользователей, кто на это обращает внимание до покупки, а не после — давно сидят на iPhone'ах, а учитывая их количество — воевать за них бессмысленно.
JTG
27.12.2017 02:56Джон Кармак в своём твиттере спрашивает:
«Отправить IP-пакет до Европы можно быстрее, чем вывести пиксель на экран. Какого х*ра?».
И, собственно, объясняет: superuser.com/a/419167
quwy
27.12.2017 03:22Да везде тормоза: банкоматы, терминалы самообслуживания, меню телевизоров/мониторов, телефоны. И ладно бы там графика была хоть какая-то, но нет же, примитив полный, а тормозит так, как будто в Китае на дохлом сервере производителя рендерится и ползет до экрана несжатым битмапом по GPRS через их китайский фаерволл.
ИМХО проблема в том, что уже даже в ембед проник этот чертов web-стек. Не удивлюсь, если окажется что даже меню телевизора — это результат выполнения js-говнокода.
nuclight
27.12.2017 17:31Банкомат — это очень тупая железка, он почти полностью управляется хостом. Для тех операций, которые делаются локально, я тормозов не замечал. А когда уходит запрос в процессинговый центр, так оно там не только делает свои запросы, но еще и может перенаправить запрос в МПС, если карта чужая.
nikolayv81
28.12.2017 08:31Если вы нажали кнопку и у вас вместо не произошло ничего (не появились песочные часики, не побежала полоса загрузки и т.п., да просто не посерела кнопка) то это на стороне банкомата.
Dimano
27.12.2017 04:10+1Больше всего выбешивает переключение языка ввода, если быстро переключить язык и сразу начать набирать, то сюрприз, язык не переключится… Раньше такого не было.
p.s. Windows 7sumanai
27.12.2017 16:26Кажется наоборот, в XP такое наблюдаю, а в 10 починили. Хотя говорят, что задержку как раз в XP и добавили, в 2000 был другой, более нативный переключатель клавиатуры, который ломался установкой 97 офиса и ctfmon, который и вносит тормоза.
ValdikSS
28.12.2017 02:55У меня два кнопочных (условно говоря) смартфона: Blackberry Q10 (2013 год) и HTC Herald (2006 год). На Blackberry часто бывает так, что инпут лаг клавиатуры составляет секунды, особенно в Android-программах, особенно при переключении раскладки. Переключение раскладки сделано, вроде бы, нормально, но оно, по какой-то причине, настолько тормозное, что если нажать комбинацию переключения, некоторое время используется старая раскладка, хотя анимация переключения давно закончилась. Это невероятно бесит, и просто не позволяет набирать текст на нескольких языках быстро, постоянно приходится проверять, исправлять.
На HTC Herald, под управлением Windows Mobile 6.5, все наоборот: программы запускаются довольно медленно, сам коммуникатор не был быстрым даже в свое время (200 мГц процессор и 64 МБ оперативной памяти), зато любой ввод обрабатывается молниеносно. Переключения языка выполняется отдельной кнопкой, и никогда не сбоит. Буквы на экране появляются сразу после нажатия кнопки. Писать на нем тексты — сплошное удовольствие.
nikolayv81
28.12.2017 08:34После alt-tab-а может вообще не сработать.
А всякие rdp это просто "сказка"
vbif
28.12.2017 19:35Ставьте что-нибудь типо ReCaps и вешайте переключение на CapsLock — проблемы с переключением языка сразу куда-то уходят. Зато если садишься за чужой компьютер — сразу встают в полный рост.
vikarti
27.12.2017 06:32Кстати еще заметно… MacMini 2012 c 2,3 GHz Intel Core i7 и 16 Gb RAM / Fusion Drive.
Периодически хром впадает в ступор (например при открытии окна с другим профилем), да — у меня достаточно много вкладок и главный процесс хрома 2.85 Gb жрет.
Но вот только когда он впадает в ступор — иногда замирает вся система, музыка в iTunes (играемая с локальной медиатеки а не стримингом Apple Music) рывками идет и это слышно.
А с другой стороны как программист — планирую следующий мобильный проект и он видимо будет на JavaScript полностью или частично (правда на ReactNative а не Web-стеке). Потому что критически нужные библиотеки — только так подключить (все альтернативы не подходят либо по лицензии либо по функционалу, а бонусом рассчитываю что ReactNative даст возможность еще и UWP и macOS Desktop приложения сделать очень малой ценой).
ITMatika
27.12.2017 07:23В 80-е годы была проблема интерфейсов: пользователи долго и упорно с клавиатуры вводили исходные данные, нажимали на кнопку Ввод и компьютер моментально печатал на экране ответ и OK — ожидание следующего ввода. Пользователей такая мгновенная реакция компьютера раздражала, выдвигались предложения затормозить интерфейс для большего комфорта пользователей.
Я сам из того поколения, которое привыкло получать мгновенный отклик. Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.ValdikSS
28.12.2017 02:58Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
Меня больше всего раздражают неподгрузившееся картинки в вебе. Нажимаешь на какую-нибудь кнопку, начинает показываться анимация, и на момент вы видите иконку незагрузившейся картинки, а потом она уже появляется.nikolayv81
28.12.2017 08:39Web весёлая штука, мобильная страница инстаграма с телефона после сброса к заводским настройкам через хром(т.е. это стартовая страница с предложением регистрации/логина) несколько секунд при этом мобильная версия интерфакса почти мгновенно.
iSergios
27.12.2017 07:46Говоря об эмпирическом опыте. Коллекционирую старые ПК и их комплектующие более 10 лет и являюсь счастливым обладателем практически всей линейки IBM-совместимых ПК от 8086 до PIII.
И вот что я заметил: если собрать ПК на базе PentiumMMX 200MHz с 32Mb RAM и IDE-Flash вместо традиционного HDD, накатить на него Windows 98 и MS Office95, то такая сборка будет работать заметно быстрее и плавнее, чем мой рабочий ПК с i3-4130, 4Gb RAM и SSD-диском в MS Office365 под управлением Win7. Что реально доставляет, так это то, что основная задача офисного пакета с 1995 года не изменилась никак, базовый набор предлагаемых им плюшек тоже не претерпел видимых изменений, как и набор тех инструментов, которым пользуется рядовой офисный пользователь. Как печатали текстики, так и печатают. Как форматировали, так и форматируют. Но памяти свежезапущенный Word365 жрет больше в 70 раз, а еще умудряется и тормозить, и зависать в работе. Да, у 365 добавилось облако. Но при сравнении функционал, с ним связанный, не использовался.
И вот, что еще интересно. Если мы возьмем 486-й ПК на базе какого-нибудь 486DX4-100 (по сути, не самая топовая 486-я комплектация) с 16Mb RAM, и накинем на него Windows95 + Office95 (опять же, воспользуемся читом в виде IDE-Flash). То эмпирически получим примерно ту же отзывчивость, которую имеем на моем достаточно современном компе с самым современным офисом. По базовому функционалу — ну разве что облака не будет :)
Interreto
27.12.2017 09:26Во всем виноваты свисто-перделки, анимация и т.п., если под андроидом зайти в дев. режим и отключить анимацию, время отклика увеличится, но вам будет не комфортно
F376
27.12.2017 09:26У Dan Luu довольно спорный метод измерения latency. «Custom Haswell» или «MacBook» — это очень произвольные обобщения. На современных компьютерах latency очень сильно зависит от software и от режима его работы. Например, для компьютера под управлением windows следует a) Использовать DirectInput (причем устройство устройству, разумеется, рознь — скажем, джойстик на игровом порте будет иметь минимальный лаг). б) Использовать exclusive экранный вывод средствами DirectX — это даст минимальный latency даже под Windows. Разумеется, если загрузить машину даже не под реалтайм-операционкой, а всего-то под старым, добрым DOS, наваяв собственный exe/com — это даст минимальный Latency, но я хочу объяснить почему метод выбранный Dan Luu не очень хорош.
- Первое, от чего зависит Latency вывода на экран, это частота кадровой развертки видеосигнала. При частоте кадров 60Hz имеем возможный latency от начала к концу кадра 1/60=16мс. При частоте кадров 120Hz он уменьшается до 8мс.
- Внутренний буфер кадра ЖК-монитора запросто может дать еще задержку на кадр, что даст еще 1/60 = 16мс. Поэтому измерять задержку видео-камерой то еще занятие.
- В случае windows источником задержки служит дополнительный буфер композиции у менеджера композиции десктопа (dwm.exe). Aero даст большую задержку, нежели чем его отсутствие — весь вывод через Aero принудительно буферизуется во избежание tearing.
- DoubleBuffering или Page Flipping видеокарты даст 1/60 = 16мс.
И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.andreymal
27.12.2017 11:33А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?
Впрочем, об этом даже в самой статье написано:
… измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д.
F376
29.12.2017 01:20Вы совершенно правы в своем замечании. Вероятно, я не вполне ясно выразился. У автора прослеживается следующая мысль: «современные системы содержат очень много транзисторов, очень быстры, но всё равно имеют большой лаг по сравнению с 8-bit компьютером». Моя мысль: «современные системы быстры, всё это верно. Но в них существует пара-тройка буферов связанных с видео-выводом и задерживающих картинку минимум на 2-3 кадра, что даёт встроенный лаг, который портит впечатление при подобном тестировании этих систем по сравнению с 8-bit машиной». Также я хотел сообщить, что это лишь отчасти недоинжиниринг и разрастание функциональности, эти системы обеспечивают по-умолчанию luxury (прозрачность, отсутствие tearing итд). При соответствующей настройке software и hardware можно получать лаг меньше.
Viacheslav01
27.12.2017 14:20Не понятно, почему даблбуферинг дает еще одну задержку в кадр?
Кадр может быть отрисован в буфер очень быстро, дальше просто перенаправление выборки на новый адрес, в случае синхронизации да даст задержку до кадра, в случае без синхронизации задержки не будет.
justified
27.12.2017 09:26Попробовал провести подобный опыт на своем компьютере. Моя камера позволяет записывать только со скоростью 60 кадров в секунду, то есть разрешение выходит примерно 16 миллисекунд.
С Windows 10 время отклика получается в среднем около 100 мс, на Linux Lite — 50.
Вот видео, если кому любопытно (замедлено в четыре раза): youtu.be/u2OBKcLRFxkF376
29.12.2017 01:24Прекрасная работа!
Почему-то после просмотра пришла мысль. Насколько в мире велик рынок сбыта маленьких микро-пылесосиков для программистов и вообще, IT-люда.
quartz64
27.12.2017 10:07Не знаю, что я делаю не так, но что дома, что на работе Word 2013 стартует за секунду. Конфигурация 2012 года (Sandy Bridge, 8/16 ГБ памяти, но главное — SSD, хоть и не самый свежий). TeXstudio стартует за 3–4 с. Якобы недостаточная скорость сканирования клавиатурной матрицы в Ergodox ни на что не влияет, задержка мозга и пальцев выше на порядок.
quartz64
27.12.2017 10:14P.S. Меж тем более древняя конфигурация (компьютер отца, 2-ядерный Pentium E5300 под LGA775, 2 ГБ памяти и обычный HDD) с 2009 года постепенно превратился в тыкву. Windows 7 после установки обновлений для использования непригодна, пришлось Lubuntu поставить.
ValdikSS
28.12.2017 03:07Купите Xeon E5450 или E5440, если мат. плата позволяет, и доставьте оперативной памяти. Моему компьютеру почти 10 лет, и все еще достаточно быстр в типичных задачах.
Rudechamp
27.12.2017 11:54Intel® Core(TM) i3-7100 CPU @ 3.90GHz + SSD WDC WDS120G1G0A-00SS50 + 8GB RAM время запуска Word 1секунда
Viacheslav01
27.12.2017 14:14Странно, как можно заметить задержку в 2 мс, при наличии буфера в мозгу на 200 мс?
Viacheslav01
27.12.2017 18:11А прокоментировать?
DistortNeo
27.12.2017 18:31А что комментировать? Там статья по ссылке, где всё написано: и методология, и результаты. Если вам английский не знаком, то поясняю, как я понимаю эту работу:
Человек двигает стилусом квадратик на экране (или пишет текст). Дополнительная задержка приводит к тому, что объект смещается чуть позже. В статике эти миллисекунды, понятное дело, не заметны, но в динамике, когда человек следит глазами за движением, это можно увидеть.
Судя по работе, получается, что разница в 5 миллисекунд при быстром движении стилуса оказывается вполне заметной. Если двигать стилус со скоростью 200 уэе* в секунду, то лаг в 5 мс приведёт к отставанию объекта от стилуса на 1 уэе. Если перемещается объект размера 5х5 уэе, то это может быть заметно.
* условная экранная единица
Но работа, конечно, мутновата: как можно заметить разницу между 1 мс и 2 мс, используя 480 fps камеру, мне не понятно.nikolayv81
28.12.2017 08:53Мозг синхронизирует (приводит все события к единому timeflow) на самом деле там даже не 0.2 секунды а может быть и более.
Просто "мозг" обрабатывает картинку с экрана и движение пальцев в едином потоке.
А так мозг к примеру быстрее воспринимает боль чем звук а звук чем картинку...
Desavian
28.12.2017 11:47Если бы в мозгу у всех действительно был буфер в 200 мс, я бы не смог выдавать стабильную скорость реакции в 150-180мс. А задержка замечается в сравнении, что наш мозг делает уже самостоятельно, без внешнего лага и значительно быстрее.
Viacheslav01
28.12.2017 11:58Буфер работает не на задержку, а на синхронизацию. Т.е. он никак не мешает иметь реакцию, короче этого буфера, но зато отлично сливает воедино события одного потока действия разнесенные во времени.
Т.е. например, если реакция в боевых искуствах, ввы можете среагирповать на удар заблокировать его, быстрее чем 200 мс. Но эта реакция будет раньше вашего осознания происходящего, потом мозг склеит все в буфере и отдаст как одно событие увидел-принял действие-заблокировал-увидел результат.
Да можно заметить эти самые 2 мс, но только если они на границе, т.е. если есть предположим задержка в 200 мс и мы на нее не реагируем, т.к. она попадает в буфер. Но уже 202 мс, дадут ощущение запаздывания.
Самый простой эксперимент, который очень любит мой сын, можно найти растояние при котором хлопок и звук от него будут восприниматься одновременно, но буквально через метр, уже будет ясно различимая задержка.
В общем саму по себе задержку в 2 мс, человек не осознает (фиг знает может есть мутанты без буыера).
ZiggiPop
>У нас недостаточно данных, чтобы объяснить такую необычно высокую скорость BlackBerry Q10 для не-Apple устройств, но есть правдоподобная догадка, что это объясняется наличием физических кнопок — для них легче реализовать быстрый отклик, чем для тачскрина и виртуальной клавиатуры
А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?
Ipeacocks
> А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?
Так в Эпла же не RTOS и время отклика ниже, а в Пикселя на 10 больше, что не значительно выше, но и Андроид не RTOS. Так что, думаю, вы нашли закономерность там, где ее нет.
lorc
Почему-то у всех RTOS ассоциируется со скоростью, что в корне не верно. Единственная задача RTOS — обеспечить гарантированное время реакции на событие. При чем время реакции не обязано быть маленьким. Оно может составлять секунды.
Для каждой задачи (процесса, потока) указывается максимальное время реакции на событие. Задача шедуллера RTOS — удовлетворить все эти ограничения. И все.
Более, того, существует теорема, которая говорит что для того что-бы Rate-monotonic scheduler смог удовлетворить все заявки, средняя нагрузка процессора должна быть не более чем 69.32% (при количестве задач, стремящимся к бесконечности). Т.е. процессор будет простаивать 30% процентов времени. Для алгоритмов с динамическим изменением приоритетов нет столь жутких ограничений, но все равно, 100% загрузки процессора можно будет достичь только в идеальном случае.
Конечно, возможно разработчики BlackBerry оттюнили приоритеты задач таким образом, чтобы реакция на нажатия кнопки была быстрой, но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. <sarcasm>Все равно пользователь ничего не заметит</sarcasm>
khim
Система не встаёт колом ни при каких самых кривых программах, впрочем, потому что наивысший приоритет имеет один поток — а ядер в современных телефонах и планшетах гораздо больше одного…
lorc
Ну да, винда тоже повышает приоритет тому процессу, у которого окно находится в фокусе.
Я скорее говорил про всякие встраиваемые системы, где в основном и используются RTOS. Там UI не в приоритете. Но, с другой стороны там UI сам по себе не очень сложный, поэтому пользователь все равно не замечает задержек.
anger32
Все верно, только Вы забыли следующие моменты: