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

https://danluu.com/input-lag/
  • Перевод
У меня гнетущее чувство, что современные компьютеры по ощущениям медленнее, чем те компьютеры, которые я использовал в детстве. Я не доверяю такого рода ощущениям, потому что человеческое восприятие доказало свою ненадёжность в эмпирических исследованиях, так что я взял высокоскоростную камеру и измерил время отклика устройств, которые попали ко мне за последние несколько месяцев. Вот результаты:

Компьютер Отклик
(мс)
Год Тактовая
частота
Кол-во
транзисторов
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 до фреймворка ввода-вывода мы наращиваем сложность, львиную долю которой можно устранить, если сегодня сесть и переписать все системы и их интерфейсы. Но слишком неудобно заново изобретать Вселенную для снижения сложности, а рост экономики даёт прибыль, так что мы живём с тем что имеем.

По этим и другим причинам на практике проблема снижения производительности, которая возникла из-за «излишней» сложности, часто решается ещё бóльшим усложнением системы. В частности, те достижения, которые позволили нам приблизиться к самым быстрым машинам 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 опустились до нормальных цен — это не идёт ни в какое сравнение с коммерческими ЭЛТ-мониторами. Не знаю, произойдёт ли такой же прогресс со временем отклика, но будем надеяться на это.

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



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


Отклик очень важен! В очень простых задачах люди способны различать отклик до 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
Поделиться публикацией
Ой, у вас баннер убежал!

Ну, и что?
Реклама
Комментарии 139
  • +14
    >У нас недостаточно данных, чтобы объяснить такую необычно высокую скорость BlackBerry Q10 для не-Apple устройств, но есть правдоподобная догадка, что это объясняется наличием физических кнопок — для них легче реализовать быстрый отклик, чем для тачскрина и виртуальной клавиатуры

    А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?
    • +2
      > А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?

      Так в Эпла же не RTOS и время отклика ниже, а в Пикселя на 10 больше, что не значительно выше, но и Андроид не RTOS. Так что, думаю, вы нашли закономерность там, где ее нет.
      • 0

        Вы немного не понимаете сути RTOS. Дело не в том, что у RTOS время отклика выше или ниже. Дело в том, что у RTOS время отклика гарантировано. На время отклика (как и на любую другую операцию) выделяется определенное время и на это время не влияет общая загрузка системы, а значит, если при проектировке системы было оговорено комфортное время отрисовки, то вне зависимости от железа и установленного софта система будет отрисовывать интерфейс одинаково комфортно.

      • +13
        Почему-то у всех RTOS ассоциируется со скоростью, что в корне не верно. Единственная задача RTOS — обеспечить гарантированное время реакции на событие. При чем время реакции не обязано быть маленьким. Оно может составлять секунды.
        Для каждой задачи (процесса, потока) указывается максимальное время реакции на событие. Задача шедуллера RTOS — удовлетворить все эти ограничения. И все.
        Более, того, существует теорема, которая говорит что для того что-бы Rate-monotonic scheduler смог удовлетворить все заявки, средняя нагрузка процессора должна быть не более чем 69.32% (при количестве задач, стремящимся к бесконечности). Т.е. процессор будет простаивать 30% процентов времени. Для алгоритмов с динамическим изменением приоритетов нет столь жутких ограничений, но все равно, 100% загрузки процессора можно будет достичь только в идеальном случае.

        Конечно, возможно разработчики BlackBerry оттюнили приоритеты задач таким образом, чтобы реакция на нажатия кнопки была быстрой, но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. <sarcasm>Все равно пользователь ничего не заметит</sarcasm>
        • –2
          но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. Все равно пользователь ничего не заметит
          Странно. В iOS и Android UI-поток имеет наивысший приоритет.

          Система не встаёт колом ни при каких самых кривых программах, впрочем, потому что наивысший приоритет имеет один поток — а ядер в современных телефонах и планшетах гораздо больше одного…
          • +1
            Ну да, винда тоже повышает приоритет тому процессу, у которого окно находится в фокусе.

            Я скорее говорил про всякие встраиваемые системы, где в основном и используются RTOS. Там UI не в приоритете. Но, с другой стороны там UI сам по себе не очень сложный, поэтому пользователь все равно не замечает задержек.
          • +2

            Все верно, только Вы забыли следующие моменты:


            • классический RMS/RMA рассчитан на uniprocessor, SMP расширения имеют другой теоретический предел;
            • более современные практики ориентируются на response time analysis (RTA); справедливости ради, смысл у этого термина иной, нежели у автора статьи;
            • в промышленных ОСРВ нет динамического планирования ни в одной из трактовок этого термина;
            • в QNX планировщик не оперирует dedaline-ами задач.
            • 0

              Разве я где-то упомянул скорость? Я только указал на независимость скорости UI от внешних причин.


              но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов

              но если у не-RTOS время выполнения низкоприоритетной операции может растянуться на необозримый срок, то в RTOS-системах в случае, если время выполнения растянется на срок, больший оговоренного (то есть того, который в случае UI принят разработчиками как комфортный) — это будет считаться ошибкой.

          • +7
            Очень странный подход. Вы выносите итоговые результаты в таблицу под названием «время отклика устройств», а потом сами же и пишете в статье, что замеряете на самом деле время отклика самого устройства (железа) + время отклика эмулятора терминала (или простигосподи браузера), и сами же демонстрируете, что:

            — второе значительно больше первого — железо откликается за время порядка <=10 мс, а софт от 30 до 100+ мс;
            — браузер и эмулятор терминала, работающий напрямую с фреймбуфером, отличаются по скорости в разы (сюрприз).

            Зачем тогда вообще сравнивать тёплое с мягким?
            • +16
              Так сравнивается же пользовательская характеристика: время отклика настольного компьютера. А что у него под капотом — дело десятое.
              • –1
                Сравнивать её разными приложениями — некорректно. Более честно было бы, например, брать на каждом устройстве отклик самого быстрой виртуальной консоли из известных (/dev/tty думаю хорошо так обгонит lxterm), и то её быстродействие зависит от конфига ядра.
                • +8
                  По-моему как раз наиболее корректно сравнивать с тем, чем человек пользуется в повседневной работе. Лично я не сижу в /dev/tty и поэтому сравнение с ним для меня ничего не будет значить :) (Хотя, конечно, увидеть измерения /dev/tty в табличке всё равно будет любопытно)
                  • –1
                    Тогда надо было выводить одинаковый объем информации, а не символ. В данном случае раз проверка велась в консоли, то и логичнее было бы современные системы грузить с чистой консолью без всей лабуды (мы ведь сравниваем навороченность железа и время отклика?) А если речь о выводе пользовательской информации, то старые системы проигрывают хотя бы при выводе картинки. Учитываем что старые системы в связке железо — пользователь имели минимальное расстояние, а сейчас? фреймворк на фреймоворке, виртуальные машины в виртуальных машинах, там до железа… Так что все эти сравнения — полная чепуха.
                    • +1
                      (мы ведь сравниваем навороченность железа и время отклика?)

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


                      Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно

                      • 0
                        Так, об этом и речь, что основная задача старых систем и старого железа — был ввод информации от пользователя и вывод ее на экран, а современные помимо вышеописанной задачи в извращенной форме, занимаются еще тысячами других операций. Поэтому суммарный объем информации выводимый новым железом в стони раз превышает объем информации обрабатываемый и выводимый старым железом. Нет чистоты эксперимента. Там одна операция, а тут десятки и сотни тысяч, за то же время. Автор же строит таблицу и ведет к тому, что старые системы быстрее новых, но это сравнение в корне некорректно. Еще раз для пользователя: старое железо — один символ информации, новое железо — очень много информации.

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

                          Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?

                          Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
                • +2
                  А как насчет уточнить и сравнить скорость отклика у PS/2 и USB клавиатур отдельно?
              • +17
                Ох уж эти сферические кони в вакууме…
                • 0
                  Подозревать я стал год назад.
                  Я это «по-чувс-тво-вал».

                  Уже месяц я делюсь своими догадками с собеседниками. А вот теперь бесспорные доказательства:

                  ==Современные компы тормозят сильнее старых.==

                  Особенно в «микротранзакциях».

                  Беда в том, что я заметил, что это отражается и на скорости мышления. «Думаю об компьютер».

                  Я купил себе 386-й.
                  Летает.
                  • +2
                    А Вы MS DOS поставьте, так чтобы не улетел, будете якорь привязывать…

                    В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.

                    Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
                    • 0
                      Как раз недавно запустил старый 233Мгц с MS-DOS/Win98, был удивлен тем, как тормозит ввод в консоли по сравнению с Core2. Понятно, что железо старое, но это было настолько явно видно, что удивило.
                    • 0
                      Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц

                      Понимаю, что это перевод, но чисто для уточнения:
                      есть много клавиатур, у которых частота опроса 1000Гц. Еще некоторое время назад читал статью, в которой тестировали Apple Magic Keyboard, и оказалось, что у них отклик быстрее чем у большинства разрекламированных механических клавиатур.

                      Так что справедливости ради, надо бы взять нормальную клавиатуру для теста.
                      • 0
                        Но… но… но как же? Получается, новые компы более тормозные, чем какой-то Apple 2 на проце 6502?
                        • +3
                          Время отклика на нажатие клавиши — это лишь часть расплывчатой характеристики «быстродействие». В быстродействие ещё входит скорость обработки данных, скорость передачи данных (RAM, диск итд) и ещё куча всего.

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

                          «Медленность» нового железа в статье на поверку оказалась медленностью софта и современных графических оболочек. Если портировать например ChromeOS и LXDE на Apple II, то lxterm там будет демонстрировать ровно такую же «медленность». Обратно, если на современном ПК нажать клавишу в голой консоли (tty), то подозреваю, что время отклика будет ровно такое же, как и в нативной консоли apple 2 — пара десятков мс.
                          • 0
                            Они не более «тормозные». Они менее юркие. То же самое как с машинами.

                            Веспа полувековой давности с двигателеми в 100 кубов по параметру «время разворота» легко уделывает БелАЗ-75710 — несмотря на разницу в мощности в 1000 c лишним раз.

                            То же самое — и с компьютерами…
                          • +3
                            Я не вижу результатов работы системы ввода/вывода MS-DOS, зато вижу много рекламы надкусанного яблока. Ещё я не вижу FreeBSD. Лет 25 я бы уверенно сказал время отклика, т.к. его можно было посчитать. Средства MS-DOS медленно опрашивали клаву, поэтому для скорости напрямую работали с контроллером клавиатуры, там же таймер и пищалка были.
                            • +2
                              Средства MS-DOS не опрашивали клаву, в MS-DOS прилетало аппаратное прерывание от клавиатуры INT 09h (IRQ 1) по каждому нажатию и отпусканию клавиши.
                            • +4
                              Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов. Помню как в начале 1997-го года в фирму купили новейшее чудо техники Pentium 133, но котором Word к всеобщему восхищению открывался примерно за секунду. Сейчас на своём Core i7 померил ради интереса — 9 секунд. Только не говорите про возросшую функциональность. Она примерно такая же.
                              • 0
                                Сейчас на своём Core i7 померил ради интереса — 9 секунд

                                У меня Word 2016 открывается за секунду. Комп собирал в начале 2011 года.


                                Только не говорите про возросшую функциональность. Она примерно такая же.

                                Различия в мелочах. Если перейти на MS Office 97, то окажется, что того нету, это неудобно, здесь от вообще падает и т.д.

                                • 0

                                  Да всё есть и ничего не падает. Впрочем, риббона нет и после Ctrl-V мерзкая плашка "Ctrl" не повисает поверх текста.
                                  То, чего не хватало в 97-м ворде, не хватает и сейчас.

                                  • +2
                                    Это мерзкой плашкой я пользуюсь постоянно — очень удобно.
                                    А Office 97 падал значительно чаще.
                                    • 0
                                      В какой-то момент надо переставать выдумывать «мерзости» и пробовать пользоваться.
                                      Оно всегда так, привычка и нежелание менять уклад, даже если новое лучше по всем параметрам. Плашка эта очень удобная, т.к. содержит необходимые инструменты прямо рядом с курсором. Выделил текст — у тебя сразу все форматирование основное. Вставку сделал — сразу дается выбор удалить ненужное порой форматирование исходного текста.
                                      • 0
                                        нет. Просто нет.
                                        • +6
                                          Вставку сделал — сразу хочу увидеть текст, который получился в результате. А тут какая-то левая фигня перед глазами болтается, перекрывая обзор.
                                          Да, там есть одна полезная опция удаления ненужного форматирования. Вообще, в некоторых программах для этой цели сделано Ctrl+Shift+V. Дёшево и сердито. Без повисания на экране кусочка дерьма.

                                          Кроме ухудшений и бессмыслицы, за прошедшие 20 лет, конечно, добавился некоторый набор мелких улучшайзингов. Глупо спорить. Но имейте в виду, что размер дистрибутива вырос более чем в 10 раз (прописью: десять грёбаных раз). Те улучшения, которые мы с трудом можем вспомнить, точно не стоят этого.
                                          • –1
                                            Так не обновляйтесь.
                                            • +2
                                              Бесконечные обновления всего и вся по большей части уже давно перестали быть добровольным делом.
                                              • 0
                                                Ну вот, а когда я пишу, что сижу на XP x64, мне предгалают обновить ОС на «по современнее».
                                                • 0
                                                  Пишите, что сидите на Windows Server 2003.
                                                  • 0
                                                    У меня от неё обновления стоят, но и те уже закончились. Или серверность ОС даёт +10 к очкам популярности у гиков? Так как эти ОС братья близнецы.
                                                    • +1
                                                      Нет, просто Windows XP 64 bit имеет с Windows XP столько же общего, сколько, скажем, Windows 7 — с Windows Vista.
                                                      • 0
                                                        Про близнецов я имел в виду ХР х64 и 2003 сервер. Хотя версия ядра ХР х64 (5.2) и ХР х86 (5.1) явно намекают на их тесное родство, ровно так же в случае семёрки (6.1) и висты (6.0).
                                                • 0

                                                  Интересная идея, тут нужно было поставить vs 2017 на комп на котором нет интернета, оказывается имея поставку в 20+Гб это невозможно сделать без сети, да в теории это сделать можно для этого нужно сделать несколько нетривиальных действий (конечно не в gui) на компе с инетом, потом перенести данный архив на нужное место и уже потом запустить специальным образом. Это я к тому что даже в enterprise версиях всё сделано так чтобы было крайне неудобно обновляться.

                                                  • 0
                                                    Почему «в теории»? У меня была поставка на 34Gb и она отлично ставилась без сети.
                                        • +1
                                          В порядке предположений: возросла длина цепочки обратной совместимости, добавился отвечающий за работоспособность на разных платформах код, появилась проверка/отсылка чего-то в интернет при запуске…
                                          • +1

                                            У нас, человеков, лучше всего получается придумывать объяснения и оправдания. Да, если весь софт по мере взросления становится тормозным и глючным, то Ворд, надо признать, ещё неплохо держится.

                                            • +5
                                              Для меня каноничным примером является программа для записи образов дисков 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 — неподходящий инструмент разработки программ для компьютера!) и накладных расходов.
                                              • +1
                                                И, стоит заметить, я понимаю, почему разработчики выбирают Electron — у нас просто нет нормальных средств разработки кроссплатформенных графических программ для компьютера.
                                                Программа будет либо выглядеть некрасиво или вовсе уродско (Java с JavaFx), либо придется писать GUI с учетом конкретных фреймворков в каждой системе (Mono c Windows Forms, GTK# и MonoMac соответственно), либо писать на интерпретируемых или небезопасных языках, со своими сложностями обработки графических событий (Qt и байндинги к нему).
                                                • 0
                                                  у нас просто нет нормальных средств разработки кроссплатформенных графических программ для компьютера


                                                  скорей нет дешёвых специалистов по ЮИ, а программисты сами рисовать не умеют поэтому вынуждены использовать только готовые компоненты (да и тут у них с красивыи ГУИ как-то не очень).
                                                • 0
                                                  А какой смысл использовать подобного монстра? Я лет десять диски не писал, но в своё время юзал программы на пару мегабайт весом.
                                                  • +1
                                                    Эта программа для записи образов HDD на флешки или HDD. Что-то вроде dd с gui, и возможностью записи сжатых образов без предварительной распаковки.
                                                    • 0

                                                      Не было программы, которая бы просто и хорошо работала в любой ОС.


                                                      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.
                                                    • +1

                                                      Особенно впечатляет etcher-cli, у которого даже GUI нет, но она всё равно весит 68 МБ (Windows AMD64) или даже все 78 МБ (Linux AMD64).


                                                      Клон dd — в 2400 раз больше оригинала! И во много раз тормознее, скорее всего

                                                  • 0
                                                    Кстати я тоже заметил такое. В колледже, в 2004 у нас стояли машины с 256Мб памяти и Office то ли XP то ли 2000. Word открывался субъективно за секунду. Сейчас померил скорость открытия Word 2013 (Core i3, Windows 10, SSD) — открылся за 5-6 секунд.
                                                    • +1
                                                      Тогда ворд запускал «preloader» как стандарт. Сейчас он этого не делает. И правильно.
                                                      • +1
                                                        У вас чтото не то.
                                                        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 секунды.

                                                        вот вам кстати, разница в кеше которая «не важна».

                                                      • +1
                                                        Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов.
                                                        Закон Вирта?
                                                      • +1
                                                        Сейчас на своём Core i7 померил ради интереса — 9 секунд

                                                        У меня ворд 2013 открывается за секунду на i5 4670. Таки SSD поставить стоит. Ворд не столько кода выполняет много, сколько обращений к диску.

                                                        Только не говорите про возросшую функциональность. Она примерно такая же.

                                                        Т.е. номер версии просто так менялся все эти десятилетия? Функционала там вагоны нового. Для вас оно примерно так же, потому что вы используете его скорее всего как Wordpad какой-нить. Конечно с тех времен ничего не удаляли, а только прибавляли.
                                                        • 0
                                                          Таки SSD поставить стоит.

                                                          Да, I/O значит очень много.
                                                          Действительно, во времена 97 офиса на 98 винде Word открывался быстрее, чем на моем Core2 сейчас (5-15 с в зависимости от размера документа). В моем случае все «потуги» вызваны глючными драйверами Lenovo, которые неправильно отрабатывают Hibernate. Хотя жить от этого знания не легче.
                                                        • 0
                                                          Проверил запуск на 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 на итерацию). Хммммммммм… интересно
                                                          • +2
                                                            Тоже самое замечал со вкладками и тоже ZSH. Не засекал, но ощущалось это очень долго и точно счет на секунды идет. Скорее всего надо смотреть, чего там напихано в .zshrc. У меня установлен oh my zsh, и он периодически лезет проверять обновления на github
                                                            • 0
                                                              Наверное стоит учитывать и время реакции, с момента когда увидели строку ввода до нажатия на Cmd+T, порядка 0.2 * 20 = 4 с.
                                                              • 0
                                                                Помниться я по молодости скорость бега тоже секундомером замерял.Но это плохой способ, слишком большая погрешность.Лучший через инжектор или дебагер замерять, так хоть точность приемлемая будет.
                                                              • +4
                                                                Только не говорите про возросшую функциональность. Она примерно такая же.

                                                                Конечно. И у Visual Studio 2017 функциональность примерно такая же как у Visual Studio 6.
                                                                Но вообще-то нет.
                                                                Пользователь как правило не видит что что-то изменилось в лучшую сторону. Это воспринимается как само собой разумеющееся. Зато точно видит, что «раньше не тормозило».
                                                                • +1
                                                                  Зато точно видит, что «раньше не тормозило».

                                                                  Справедливости ради, в повседневной деятельности «чтобы не тормозило» может быть намного важнее нового функционала. Какой толк с нового функционала, например, если при «жизни по-новому» автодополнение в коде думает секунд 10? (Реальный случай).
                                                                • 0
                                                                  Word 2016 на Core i5 2.4 GHz, SSD — меньше секунды на открытие пустого документа.
                                                                  • 0
                                                                    У меня на ноуте хоть и i7, но HDD весьма тормозной. В этом и причина.
                                                                  • 0
                                                                    давайте вордами меряться, у меня rizen 1600 + ssd, ворд запустился за секунду
                                                                    • 0
                                                                      Может быть, это объясняется тем, что HDD особенно не ускорились 80-100 Мб/сек, при этом нагрузка на дисковую систему со стороны ОС и другого ПО сильно возросла и объемы загружаемого ПО тоже выше. А так, на хорошем SSD (особенно PCI-e) всё за секунду открывается, даже Photoshop.
                                                                      • 0
                                                                        Да, именно этим и объясняется. Но в сухом остатке мы имеем то, что сумасшедший прогресс не отменяет существенное ухудшение пользовательских характеристик.
                                                                      • 0
                                                                        Core i5 второго поколения word 2010 на SSD винте открывается 25 сек до окна и еще 5 сек до полной функциональности.
                                                                      • 0
                                                                        iPhone 7 2016 года, а не 2017
                                                                        • +8
                                                                          Простите, накипело
                                                                          Прогресс на лицо *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к у.е.?

                                                                          Иногда кажется, а может и не кажется, но нас маркетологи где-то на*бывают.


                                                                          • 0
                                                                            Так а вы зачем тогда, простите, новыми версиями софта пользуетесь? Работайте с тем, с чем справлялся ваш первый комп, и будет счастье. Раз, как вы говорите, не меняется ничего.
                                                                            • 0
                                                                              В старых версиях браузеров, например, новые сайты не работают. Office 97, например, не открывает xlsx. От нового монструозного, тормозного и глючного софта никуда не деться. Мы вынуждены его использовать.
                                                                              Одна радость души моей — 5-й WinAmp 2007-го года выпуска…
                                                                              • –1
                                                                                Для 2000 офиса, который от 97 недалеко ушел, есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться.

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

                                                                                А потому немножко некорректно говорить, что софт становится тормознее без каких-то функциональных изменений.
                                                                                • 0
                                                                                  есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоваться
                                                                                  Я не знаком ни с кем, кто горел бы желанием пользоваться этим самым Compatibility Pack. Но что-то подсказывает мне, что это не потому, что все влюбились в риббон.

                                                                                  куча всяких свистелок в веб-стандартах
                                                                                  Там вообще адъ
                                                                                  • –1
                                                                                    Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то? Или все-таки будем честны и скажем, что работает в них не всё, и не так, как того хочется? И, полагаю, проблема не в том, что на фоне идеального 2000-го офиса Compatibility Pack (и только Compatibility Pack) оказался кривой поделкой?

                                                                                    (Риббоны в офисе — это вообще офигенная штука, и как раз из-за них в свое время переходил на новую версию. Ну и из-за смарт-артов ещё.)

                                                                                    В вебе адищще, соглашусь. Но проблема тут не в браузерах как таковых, а в JS-ных поделиях по большей части, из-за чего браузерам пришлось как-то выкручиваться, чтобы всю эту хрень корректно и не очень медленно отображать. Полагаю, что если в новых браузерах открывать странички производства девяностых-двухтысячных годов, то и на старом железе тормозов не будет.
                                                                                    • +1
                                                                                      Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то?
                                                                                      В старых офисах всё хорошо, за исключением одной проблемы: совместимости с новыми. И поскольку люди этими новыми фичами реально пользуются, то деваться некуда — приходится «жрать кактус».

                                                                                      Вот с текстовыми редакторами подобной проблемы не случается — и там таки да, вполне можно пользоваться 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 и пользовался…
                                                                                      • 0
                                                                                        Риббоны в офисе — недоведённая до ума офигенная штука. Если раньше что-то было в один клик доступно, то сейчас в 3-4 — офигеть удобство. Если раньше был нормальный пункт меню, то сейчас поле 15x15 пикселей — ты сможешь! я в тебя верю!
                                                                              • 0
                                                                                Маркетологи, конечно, тоже руку приложили, но зло не только в них. Проблема, мать её, сложности. Технологии таковы, что с ростом функциональности сложность растёт сильно нелинейно. Каждая софтина дорастает до состояния, когда каждая новая фичечка реализуется только через чудовищно неприемлемое усложнение.

                                                                                Для меня эталоном сложностного тупика в своё время стала айбиэмовская вебсфера. Задача, которую она решает, проста и примитивна. Менеджер очередей сообщений. По сути, система почтовых ящиков. Неплохая тема для дипломного проекта в каком-нибудь ВУЗе средней руки. Как-то в цейтноте и безвыходняке я нечто подобное в наколеночном варианте набросал за вечер. Но… размер дистрибутива под 500МБ, и ресурсы жрёт так, будто исходит из предположения, что комп, на который оно установлено, больше ни для чего, кроме решения этой мелкой сугубо технической задачи, использоваться не будет. Когда-то оно наверняка тоже было маленьким и шустрым, а потом кабанело, кабанело и окончательно закабанело.
                                                                              • –1
                                                                                Может быть это глупый ночной вопрос, но что такое «Пакет вокруг света» в первой таблице? (статью прочитал по диагонали может быть не нашел).
                                                                                А в остальном спасибо, очень любопытное исследование!
                                                                                • +1
                                                                                  Из статьи:
                                                                                  Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.
                                                                                  А вообще статьи пишут, чтобы их читали… Но видимо так — уже не модно.
                                                                                  • –1

                                                                                    Так где оно приведено? В статье нет этой информации

                                                                                  • 0
                                                                                    Во-первых, несмотря на то, что статья любопытная, она все же не входит напрямую в сферу моих личных или профессиональных интересов, поэтому, как было сказано выше, я прочитал ее «по диагонали». Если вы привыкли всё что попадает в поле вашего зрения читать «от корки до корки» это ваше право я на него не претендую.

                                                                                    Во-вторых, спасибо за приведенную выше цитату, я её действительно не разглядел. Думаю, если бы автор изложил ее в следующем виде:
                                                                                    Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон. (п. табл. «Пакет вокруг света»)

                                                                                    то у меня бы вообще вопросов не возникло.

                                                                                    P.S. У людей может быть разное восприятие мира. Например, у меня в голове в час ночи фраза: «Пакет вокруг света» выглядит следующим образом.

                                                                                • 0
                                                                                  События поступают в ядро через прошивку

                                                                                  Немного аккуратнее надо переводить :) Понятно, что кратко этот процесс описать нельзя, но…
                                                                                  Можно оригинал статьи посмотреть? Линк только на homepage сайта
                                                                                  • 0
                                                                                    Помоему очень важная тема затронута в статье: сейчас выходит все именно так, что у нас есть все возможности и технологии делать быстрые интерфейсы, но в общем то индустрия занимается ерундой, а потребителям оно вообще не надо.

                                                                                    В пользу этой версии говорят чуть ли нее все автомобильные интерфейсы ( а там это еще и безопасность) и вообще весь рынок смартфонов на Andoroid. (я лично протестировав кучу флагманов за последние три года так и не смог найти хотя бы одного с отзывчивостью хотя бы iPhone 4)

                                                                                    Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
                                                                                    • +1
                                                                                      iPhone 4? Он давно перестал быть отзывчивым, 2 или 3 версии iOS назад как. А отзывчивый андроид легко найти — любой современный топовый девайс можно взять.
                                                                                      • 0
                                                                                        А что такого случилось 2 или 3 версии назад, что 4ка перестала быть отзывчивой?
                                                                                        • 0
                                                                                          Вышла iOS 8 — эпичный тормоз, да и 10 с 11 скоростью не радуют, 9 ещё куда ни шло, но тоже сильно отставала от 7-й по отзывчивости. Это из личного опыта на 5s, а так владельцы 4s жаловались на тормоза при смене 6 iOS на 7.
                                                                                          • 0
                                                                                            Говоря про отзывчивость я имею ввиду отклик на простейшие действия (нажатия, свайпы) Разница в этих действиях между версиями iOS даже на старых девайсах минимальна.
                                                                                            А вот со скоростью загрузки приложений тут да, ничего не попишешь.
                                                                                            Речь то была все таки про отклик, и про то что большинству оно в общем то и не нужно, либо не замечают. А при попытке продемонстрировать это, пользователи медленных девайсов включают защитную реакцию. Вон посмотрите на минусованый комментарий ниже.

                                                                                      • –5
                                                                                        Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
                                                                                        Замечают. Но тот 1% пользователей, кто на это обращает внимание до покупки, а не после — давно сидят на iPhone'ах, а учитывая их количество — воевать за них бессмысленно.
                                                                                      • +1
                                                                                        Больше всего выбешивает, когда время реакции на воздействие ниже моей реакции как человека. Успеваешь понять, что реакции не последовало, и машинально повторить воздействие. Хорошо, если действие нереентабельно, но как правило нет же…
                                                                                        • 0
                                                                                          ЗАТО КРАСИВЕНЬКО!
                                                                                        • +2
                                                                                          Джон Кармак в своём твиттере спрашивает:
                                                                                          «Отправить IP-пакет до Европы можно быстрее, чем вывести пиксель на экран. Какого х*ра?».

                                                                                          И, собственно, объясняет: superuser.com/a/419167
                                                                                          • +7
                                                                                            Да везде тормоза: банкоматы, терминалы самообслуживания, меню телевизоров/мониторов, телефоны. И ладно бы там графика была хоть какая-то, но нет же, примитив полный, а тормозит так, как будто в Китае на дохлом сервере производителя рендерится и ползет до экрана несжатым битмапом по GPRS через их китайский фаерволл.

                                                                                            ИМХО проблема в том, что уже даже в ембед проник этот чертов web-стек. Не удивлюсь, если окажется что даже меню телевизора — это результат выполнения js-говнокода.
                                                                                            • +3

                                                                                              В smart TV от LG все так и есть

                                                                                              • 0
                                                                                                Банкомат — это очень тупая железка, он почти полностью управляется хостом. Для тех операций, которые делаются локально, я тормозов не замечал. А когда уходит запрос в процессинговый центр, так оно там не только делает свои запросы, но еще и может перенаправить запрос в МПС, если карта чужая.
                                                                                                • +2

                                                                                                  Если вы нажали кнопку и у вас вместо не произошло ничего (не появились песочные часики, не побежала полоса загрузки и т.п., да просто не посерела кнопка) то это на стороне банкомата.

                                                                                                  • 0
                                                                                                    Возможно, но есть нюанс. Возможно, это на стороне тех, кто прогружал в банкомат ресурсы (экраны). Рассказывали, что бывают такие случаи… Если это так, и банкомат всё время показывает одноцветный экран, таки можно снять деньги, пронажимав кнопки вслепую «по памяти» — на нужной последовательности будет сформирован запрос на хост, которому пофиг что рисуется, он реагирует на заполненный буфер нажатий.
                                                                                              • +4

                                                                                                Больше всего выбешивает переключение языка ввода, если быстро переключить язык и сразу начать набирать, то сюрприз, язык не переключится… Раньше такого не было.
                                                                                                p.s. Windows 7

                                                                                                • 0
                                                                                                  Кажется наоборот, в XP такое наблюдаю, а в 10 починили. Хотя говорят, что задержку как раз в XP и добавили, в 2000 был другой, более нативный переключатель клавиатуры, который ломался установкой 97 офиса и ctfmon, который и вносит тормоза.
                                                                                                  • 0
                                                                                                    У меня два кнопочных (условно говоря) смартфона: Blackberry Q10 (2013 год) и HTC Herald (2006 год). На Blackberry часто бывает так, что инпут лаг клавиатуры составляет секунды, особенно в Android-программах, особенно при переключении раскладки. Переключение раскладки сделано, вроде бы, нормально, но оно, по какой-то причине, настолько тормозное, что если нажать комбинацию переключения, некоторое время используется старая раскладка, хотя анимация переключения давно закончилась. Это невероятно бесит, и просто не позволяет набирать текст на нескольких языках быстро, постоянно приходится проверять, исправлять.

                                                                                                    На HTC Herald, под управлением Windows Mobile 6.5, все наоборот: программы запускаются довольно медленно, сам коммуникатор не был быстрым даже в свое время (200 мГц процессор и 64 МБ оперативной памяти), зато любой ввод обрабатывается молниеносно. Переключения языка выполняется отдельной кнопкой, и никогда не сбоит. Буквы на экране появляются сразу после нажатия кнопки. Писать на нем тексты — сплошное удовольствие.
                                                                                                    • +1

                                                                                                      После alt-tab-а может вообще не сработать.
                                                                                                      А всякие rdp это просто "сказка"

                                                                                                      • 0
                                                                                                        Ставьте что-нибудь типо ReCaps и вешайте переключение на CapsLock — проблемы с переключением языка сразу куда-то уходят. Зато если садишься за чужой компьютер — сразу встают в полный рост.
                                                                                                        • 0
                                                                                                          Скопировали с OSX не иначе. Раньше такого не замечал в винде, на макоси есть такой грешок
                                                                                                        • 0
                                                                                                          Кстати еще заметно… 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 приложения сделать очень малой ценой).
                                                                                                          • +1
                                                                                                            В 80-е годы была проблема интерфейсов: пользователи долго и упорно с клавиатуры вводили исходные данные, нажимали на кнопку Ввод и компьютер моментально печатал на экране ответ и OK — ожидание следующего ввода. Пользователей такая мгновенная реакция компьютера раздражала, выдвигались предложения затормозить интерфейс для большего комфорта пользователей.
                                                                                                            Я сам из того поколения, которое привыкло получать мгновенный отклик. Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
                                                                                                            • 0
                                                                                                              Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
                                                                                                              Меня больше всего раздражают неподгрузившееся картинки в вебе. Нажимаешь на какую-нибудь кнопку, начинает показываться анимация, и на момент вы видите иконку незагрузившейся картинки, а потом она уже появляется.
                                                                                                              • 0

                                                                                                                Web весёлая штука, мобильная страница инстаграма с телефона после сброса к заводским настройкам через хром(т.е. это стартовая страница с предложением регистрации/логина) несколько секунд при этом мобильная версия интерфакса почти мгновенно.

                                                                                                            • +2
                                                                                                              Говоря об эмпирическом опыте. Коллекционирую старые ПК и их комплектующие более 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). То эмпирически получим примерно ту же отзывчивость, которую имеем на моем достаточно современном компе с самым современным офисом. По базовому функционалу — ну разве что облака не будет :)
                                                                                                              • +1

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

                                                                                                                • 0
                                                                                                                  У Dan Luu довольно спорный метод измерения latency. «Custom Haswell» или «MacBook» — это очень произвольные обобщения. На современных компьютерах latency очень сильно зависит от software и от режима его работы. Например, для компьютера под управлением windows следует a) Использовать DirectInput (причем устройство устройству, разумеется, рознь — скажем, джойстик на игровом порте будет иметь минимальный лаг). б) Использовать exclusive экранный вывод средствами DirectX — это даст минимальный latency даже под Windows. Разумеется, если загрузить машину даже не под реалтайм-операционкой, а всего-то под старым, добрым DOS, наваяв собственный exe/com — это даст минимальный Latency, но я хочу объяснить почему метод выбранный Dan Luu не очень хорош.
                                                                                                                  1. Первое, от чего зависит Latency вывода на экран, это частота кадровой развертки видеосигнала. При частоте кадров 60Hz имеем возможный latency от начала к концу кадра 1/60=16мс. При частоте кадров 120Hz он уменьшается до 8мс.
                                                                                                                  2. Внутренний буфер кадра ЖК-монитора запросто может дать еще задержку на кадр, что даст еще 1/60 = 16мс. Поэтому измерять задержку видео-камерой то еще занятие.
                                                                                                                  3. В случае windows источником задержки служит дополнительный буфер композиции у менеджера композиции десктопа (dwm.exe). Aero даст большую задержку, нежели чем его отсутствие — весь вывод через Aero принудительно буферизуется во избежание tearing.
                                                                                                                  4. DoubleBuffering или Page Flipping видеокарты даст 1/60 = 16мс.

                                                                                                                  И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
                                                                                                                  Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.
                                                                                                                  • +2

                                                                                                                    А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?


                                                                                                                    Впрочем, об этом даже в самой статье написано:


                                                                                                                    … измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д.
                                                                                                                    • +1
                                                                                                                      Вы совершенно правы в своем замечании. Вероятно, я не вполне ясно выразился. У автора прослеживается следующая мысль: «современные системы содержат очень много транзисторов, очень быстры, но всё равно имеют большой лаг по сравнению с 8-bit компьютером». Моя мысль: «современные системы быстры, всё это верно. Но в них существует пара-тройка буферов связанных с видео-выводом и задерживающих картинку минимум на 2-3 кадра, что даёт встроенный лаг, который портит впечатление при подобном тестировании этих систем по сравнению с 8-bit машиной». Также я хотел сообщить, что это лишь отчасти недоинжиниринг и разрастание функциональности, эти системы обеспечивают по-умолчанию luxury (прозрачность, отсутствие tearing итд). При соответствующей настройке software и hardware можно получать лаг меньше.
                                                                                                                    • 0
                                                                                                                      Не понятно, почему даблбуферинг дает еще одну задержку в кадр?
                                                                                                                      Кадр может быть отрисован в буфер очень быстро, дальше просто перенаправление выборки на новый адрес, в случае синхронизации да даст задержку до кадра, в случае без синхронизации задержки не будет.
                                                                                                                    • +1
                                                                                                                      Попробовал провести подобный опыт на своем компьютере. Моя камера позволяет записывать только со скоростью 60 кадров в секунду, то есть разрешение выходит примерно 16 миллисекунд.

                                                                                                                      С Windows 10 время отклика получается в среднем около 100 мс, на Linux Lite — 50.

                                                                                                                      Вот видео, если кому любопытно (замедлено в четыре раза): youtu.be/u2OBKcLRFxk
                                                                                                                      • 0
                                                                                                                        Прекрасная работа!
                                                                                                                        Почему-то после просмотра пришла мысль. Насколько в мире велик рынок сбыта маленьких микро-пылесосиков для программистов и вообще, IT-люда.
                                                                                                                        • 0
                                                                                                                          Да есть у меня микротряпка для клавы. Вот только лень, к сожалению, не микро.
                                                                                                                      • 0
                                                                                                                        Не знаю, что я делаю не так, но что дома, что на работе Word 2013 стартует за секунду. Конфигурация 2012 года (Sandy Bridge, 8/16 ГБ памяти, но главное — SSD, хоть и не самый свежий). TeXstudio стартует за 3–4 с. Якобы недостаточная скорость сканирования клавиатурной матрицы в Ergodox ни на что не влияет, задержка мозга и пальцев выше на порядок.
                                                                                                                        • 0
                                                                                                                          P.S. Меж тем более древняя конфигурация (компьютер отца, 2-ядерный Pentium E5300 под LGA775, 2 ГБ памяти и обычный HDD) с 2009 года постепенно превратился в тыкву. Windows 7 после установки обновлений для использования непригодна, пришлось Lubuntu поставить.
                                                                                                                          • 0
                                                                                                                            Купите Xeon E5450 или E5440, если мат. плата позволяет, и доставьте оперативной памяти. Моему компьютеру почти 10 лет, и все еще достаточно быстр в типичных задачах.
                                                                                                                        • 0
                                                                                                                          Intel® Core(TM) i3-7100 CPU @ 3.90GHz + SSD WDC WDS120G1G0A-00SS50 + 8GB RAM время запуска Word 1секунда
                                                                                                                          • –1
                                                                                                                            Странно, как можно заметить задержку в 2 мс, при наличии буфера в мозгу на 200 мс?
                                                                                                                            • 0
                                                                                                                              А прокоментировать?
                                                                                                                              • +1
                                                                                                                                А что комментировать? Там статья по ссылке, где всё написано: и методология, и результаты. Если вам английский не знаком, то поясняю, как я понимаю эту работу:

                                                                                                                                Человек двигает стилусом квадратик на экране (или пишет текст). Дополнительная задержка приводит к тому, что объект смещается чуть позже. В статике эти миллисекунды, понятное дело, не заметны, но в динамике, когда человек следит глазами за движением, это можно увидеть.

                                                                                                                                Судя по работе, получается, что разница в 5 миллисекунд при быстром движении стилуса оказывается вполне заметной. Если двигать стилус со скоростью 200 уэе* в секунду, то лаг в 5 мс приведёт к отставанию объекта от стилуса на 1 уэе. Если перемещается объект размера 5х5 уэе, то это может быть заметно.
                                                                                                                                * условная экранная единица

                                                                                                                                Но работа, конечно, мутновата: как можно заметить разницу между 1 мс и 2 мс, используя 480 fps камеру, мне не понятно.
                                                                                                                                • 0

                                                                                                                                  Мозг синхронизирует (приводит все события к единому timeflow) на самом деле там даже не 0.2 секунды а может быть и более.
                                                                                                                                  Просто "мозг" обрабатывает картинку с экрана и движение пальцев в едином потоке.
                                                                                                                                  А так мозг к примеру быстрее воспринимает боль чем звук а звук чем картинку...

                                                                                                                              • 0
                                                                                                                                Если бы в мозгу у всех действительно был буфер в 200 мс, я бы не смог выдавать стабильную скорость реакции в 150-180мс. А задержка замечается в сравнении, что наш мозг делает уже самостоятельно, без внешнего лага и значительно быстрее.
                                                                                                                                • +1
                                                                                                                                  Буфер работает не на задержку, а на синхронизацию. Т.е. он никак не мешает иметь реакцию, короче этого буфера, но зато отлично сливает воедино события одного потока действия разнесенные во времени.

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

                                                                                                                                  Да можно заметить эти самые 2 мс, но только если они на границе, т.е. если есть предположим задержка в 200 мс и мы на нее не реагируем, т.к. она попадает в буфер. Но уже 202 мс, дадут ощущение запаздывания.

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

                                                                                                                                  В общем саму по себе задержку в 2 мс, человек не осознает (фиг знает может есть мутанты без буыера).
                                                                                                                              • 0
                                                                                                                                Статья, IMHO, в общем-то, о том, что велосипеды быстрее самолётов, поскольку на велосипеде можно добраться куда-нибудь за несколько секунд, а на самолёте — минимум за час
                                                                                                                                P.S. а что за Linux chroot среди ОС?
                                                                                                                                • 0
                                                                                                                                  Видимо, напрямую на ThinkPad 13 поставить его сложно, вот и воткнули в chroot на хромой ОС. Видел похожие решения на андроидах.
                                                                                                                                • 0

                                                                                                                                  Повторю мысль, пришедшую мне в голову месяц назад:


                                                                                                                                  Кажется один из факторов — культурный. В информационном поле почти отсутствует мысль о важности отзывчивости и легковесности. Вот сколько я встречал списков сравнения best N apps for task X — не припомню, чтобы хотя бы в одном из них был замер использованного процессорного времени и памяти на выполнение аналогичных действий, примерно как я искал себе быстрый просмотрщик изображений. Вот в качестве пруфа можно погуглить "image viewers performance comparison" — очень мало ожидаемых результатов, всего ~3 в первой десятке! А для запроса "bittorrent clients performance comparison" в первой десятке только одна релевантная ссылка аж от 2010 года (ну и для справедливости ещё одна работа со сравнением скорости скачивания двух клиентов).


                                                                                                                                  В идеальном мире в сравнительных обзорах были бы сравнения производительности с замерами, что давало бы разработчикам соревновательный стимул к оптимизации. Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.

                                                                                                                                  • –1
                                                                                                                                    Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.
                                                                                                                                    Почему? Если пользователям пофиг?
                                                                                                                                    • 0
                                                                                                                                      А разве им пофиг? Как это можно проверить?

                                                                                                                                      • –1
                                                                                                                                        По продажам, однако. Строго говоря, пользователи с большей вероятностью будут использовать продукт, который тормозит меньше и имеет ту же функциональность. Ну ещё бы! Лучше быть богатым и здоровым, чем бедным и больным.

                                                                                                                                        Но так ведь не бывает — если вы затратите ресурсов на пристальное изучение программы под профайлером, то затраты на неё возрастут, а знать — возрастёт и цена.

                                                                                                                                        И если смотреть на продажи iPhone'ов — то хорошо видно, что, люди вполне готовы терпеть тормоза, чтобы получить не такую и большую экономию в цене (я специально взял для оценки iPhone, которые, как известно считаются фанатами всего самого нового, самого крутого, самого быстрого… думаю среди покупателей других телефоном таких будет ещё меньше).

                                                                                                                                        Почему вы считаете, что ситуация с софтом должна быть иной?
                                                                                                                                        • 0

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


                                                                                                                                          Пользователям не "пофиг" в смысле отзывчивость приложений существенно влияет на комфортность их использования, о чём говорят например исследования влияния скорости загрузки сайтов на поведение пользователей и сам Dan Luu приводит в статье некоторые размышления. Но частично важность отзывчивости не осознаётся самими пользователями, что является частью моего исходного тезиса.


                                                                                                                                          Теперь как можно трактовать статистику активаций ифонов. Во-первых, самые популярные модели по этой статистике стоят от трети до половины дешевле топовых. Разве это небольшая экономия в цене? Да пользователю вообще может быть выгоднее купить модель на 300$ дешевле, а потом потратить на 100$ больше на покупку софта под свои задачи, выбирая более дорогие вылизанные программы. Собственно мне кажется, что есть множество классов программ (какие-нибудь приложения аптек например), где на оптимизацию тратят ресурсов примерно 0, если там заложить под оптимизацию хотя бы 5% бюджета, ускорение может быть в разы.