Comments 139
А может правдоподобнее то, что в основе BlackBerry OS лежит QNX, которая RTOS, и на время отклика не влияют никакие внешние причины?
Так в Эпла же не RTOS и время отклика ниже, а в Пикселя на 10 больше, что не значительно выше, но и Андроид не RTOS. Так что, думаю, вы нашли закономерность там, где ее нет.
Вы немного не понимаете сути RTOS. Дело не в том, что у RTOS время отклика выше или ниже. Дело в том, что у RTOS время отклика гарантировано. На время отклика (как и на любую другую операцию) выделяется определенное время и на это время не влияет общая загрузка системы, а значит, если при проектировке системы было оговорено комфортное время отрисовки, то вне зависимости от железа и установленного софта система будет отрисовывать интерфейс одинаково комфортно.
Для каждой задачи (процесса, потока) указывается максимальное время реакции на событие. Задача шедуллера RTOS — удовлетворить все эти ограничения. И все.
Более, того, существует теорема, которая говорит что для того что-бы Rate-monotonic scheduler смог удовлетворить все заявки, средняя нагрузка процессора должна быть не более чем 69.32% (при количестве задач, стремящимся к бесконечности). Т.е. процессор будет простаивать 30% процентов времени. Для алгоритмов с динамическим изменением приоритетов нет столь жутких ограничений, но все равно, 100% загрузки процессора можно будет достичь только в идеальном случае.
Конечно, возможно разработчики BlackBerry оттюнили приоритеты задач таким образом, чтобы реакция на нажатия кнопки была быстрой, но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. <sarcasm>Все равно пользователь ничего не заметит</sarcasm>
но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов. Все равно пользователь ничего не заметитСтранно. В iOS и Android UI-поток имеет наивысший приоритет.
Система не встаёт колом ни при каких самых кривых программах, впрочем, потому что наивысший приоритет имеет один поток — а ядер в современных телефонах и планшетах гораздо больше одного…
Я скорее говорил про всякие встраиваемые системы, где в основном и используются RTOS. Там UI не в приоритете. Но, с другой стороны там UI сам по себе не очень сложный, поэтому пользователь все равно не замечает задержек.
Все верно, только Вы забыли следующие моменты:
- классический RMS/RMA рассчитан на uniprocessor, SMP расширения имеют другой теоретический предел;
- более современные практики ориентируются на response time analysis (RTA); справедливости ради, смысл у этого термина иной, нежели у автора статьи;
- в промышленных ОСРВ нет динамического планирования ни в одной из трактовок этого термина;
- в QNX планировщик не оперирует dedaline-ами задач.
Разве я где-то упомянул скорость? Я только указал на независимость скорости UI от внешних причин.
но по опыту могу сказать что обычно всему что связанно с UI отдается один из самых низких приоритетов
но если у не-RTOS время выполнения низкоприоритетной операции может растянуться на необозримый срок, то в RTOS-системах в случае, если время выполнения растянется на срок, больший оговоренного (то есть того, который в случае UI принят разработчиками как комфортный) — это будет считаться ошибкой.
— второе значительно больше первого — железо откликается за время порядка <=10 мс, а софт от 30 до 100+ мс;
— браузер и эмулятор терминала, работающий напрямую с фреймбуфером, отличаются по скорости в разы (сюрприз).
Зачем тогда вообще сравнивать тёплое с мягким?
(мы ведь сравниваем навороченность железа и время отклика?)
Нет, мы сравниваем задержку, которую видит обычный пользователь на обычном (или почти обычном) компьютере в обычном для рассматриваемого компьютера окружении. Сравнивать голое железо нет никакого практического смысла, потому что голым железом никто (или почти никто) не пользуется. Вы же сами пишете этот комментарий через виртуальную машину в песочнице в фреймворке в нескольких абстракциях от железа, не так ли? :)
Насчёт одного символа — я как-то слабо представляю, как сравнивать не один символ, если обычные клавиатуры позволяют вводить текст только посимвольно
И пишу тут комментарий, при этом работает проверка синтаксиса, всякие пунтосвитчеры, пишу не в консоли, а в браузере и т.п.
Мне глубоко плевать, если мой ноутбук на Core i5 вдруг уделает Apple 2e покажет задержку в десять миллисекунд на каком-нибудь FreeDOS. Какое мне дело до FreeDOS, если я в повседневной жизни использую какой-нибудь gnome-terminal с композитным оконным менеджером, с которыми задержка, к примеру, сотня миллисекунд?
Сравнить «навороченность железа и время отклика» в принципе можно, но, ещё раз, у автора такой цели не было. И я тоже не вижу в этом смысла.
Я это «по-чувс-тво-вал».
Уже месяц я делюсь своими догадками с собеседниками. А вот теперь бесспорные доказательства:
==Современные компы тормозят сильнее старых.==
Особенно в «микротранзакциях».
Беда в том, что я заметил, что это отражается и на скорости мышления. «Думаю об компьютер».
Я купил себе 386-й.
Летает.
В статье сравнивается отклик нажатия на клавиатуру через обработку ОС и выводного приложения, которые на каждом аппаратном решении будут разные.
Но это неверно, чтобы отбросить влияние этого «мусора», создайте приложение, которое само управляет I/O и скомпилируйте его на Assembler. Мне кажется, что так были бы более сопоставимые результаты.
Если посмотреть на современные клавиатуры, то обычно ввод данных сканируется с частотой от 100 Гц до 200 Гц
Понимаю, что это перевод, но чисто для уточнения:
есть много клавиатур, у которых частота опроса 1000Гц. Еще некоторое время назад читал статью, в которой тестировали Apple Magic Keyboard, и оказалось, что у них отклик быстрее чем у большинства разрекламированных механических клавиатур.
Так что справедливости ради, надо бы взять нормальную клавиатуру для теста.
Чудес не бывает, старые машины по производительности значительно слабее современных.
«Медленность» нового железа в статье на поверку оказалась медленностью софта и современных графических оболочек. Если портировать например ChromeOS и LXDE на Apple II, то lxterm там будет демонстрировать ровно такую же «медленность». Обратно, если на современном ПК нажать клавишу в голой консоли (tty), то подозреваю, что время отклика будет ровно такое же, как и в нативной консоли apple 2 — пара десятков мс.
Веспа полувековой давности с двигателеми в 100 кубов по параметру «время разворота» легко уделывает БелАЗ-75710 — несмотря на разницу в мощности в 1000 c лишним раз.
То же самое — и с компьютерами…
Сейчас на своём Core i7 померил ради интереса — 9 секунд
У меня Word 2016 открывается за секунду. Комп собирал в начале 2011 года.
Только не говорите про возросшую функциональность. Она примерно такая же.
Различия в мелочах. Если перейти на MS Office 97, то окажется, что того нету, это неудобно, здесь от вообще падает и т.д.
Да всё есть и ничего не падает. Впрочем, риббона нет и после Ctrl-V мерзкая плашка "Ctrl" не повисает поверх текста.
То, чего не хватало в 97-м ворде, не хватает и сейчас.
А Office 97 падал значительно чаще.
Оно всегда так, привычка и нежелание менять уклад, даже если новое лучше по всем параметрам. Плашка эта очень удобная, т.к. содержит необходимые инструменты прямо рядом с курсором. Выделил текст — у тебя сразу все форматирование основное. Вставку сделал — сразу дается выбор удалить ненужное порой форматирование исходного текста.
Да, там есть одна полезная опция удаления ненужного форматирования. Вообще, в некоторых программах для этой цели сделано Ctrl+Shift+V. Дёшево и сердито. Без повисания на экране кусочка дерьма.
Кроме ухудшений и бессмыслицы, за прошедшие 20 лет, конечно, добавился некоторый набор мелких улучшайзингов. Глупо спорить. Но имейте в виду, что размер дистрибутива вырос более чем в 10 раз (прописью: десять грёбаных раз). Те улучшения, которые мы с трудом можем вспомнить, точно не стоят этого.
Интересная идея, тут нужно было поставить vs 2017 на комп на котором нет интернета, оказывается имея поставку в 20+Гб это невозможно сделать без сети, да в теории это сделать можно для этого нужно сделать несколько нетривиальных действий (конечно не в gui) на компе с инетом, потом перенести данный архив на нужное место и уже потом запустить специальным образом. Это я к тому что даже в enterprise версиях всё сделано так чтобы было крайне неудобно обновляться.
У нас, человеков, лучше всего получается придумывать объяснения и оправдания. Да, если весь софт по мере взросления становится тормозным и глючным, то Ворд, надо признать, ещё неплохо держится.
Десктопная программа для записи дисков. И отправляет метрику об использовании (телеметрию). И, конечно же, проверяет обновления при каждом запуске, как же без этого.
github.com/resin-io/etcher/issues/1878
github.com/resin-io/etcher/issues/1772
Из-за того, что используется достаточно сильное, но не быстрое сжатие LZMA для портативной Linux-версии (appimage), программа стартует достаточно длительное время, примерно 4 секунды на моем компьютере, и использует 88 МБ RAM сразу после запуска.
Вот и получается, что у нас быстрые компьютеры, но реальные задачи выполняются очень не быстро, из-за неподходящих инструментов разработки (Javascript и Electron с chromium и ffmpeg — неподходящий инструмент разработки программ для компьютера!) и накладных расходов.
Программа будет либо выглядеть некрасиво или вовсе уродско (Java с JavaFx), либо придется писать GUI с учетом конкретных фреймворков в каждой системе (Mono c Windows Forms, GTK# и MonoMac соответственно), либо писать на интерпретируемых или небезопасных языках, со своими сложностями обработки графических событий (Qt и байндинги к нему).
Не было программы, которая бы просто и хорошо работала в любой ОС.
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.
Особенно впечатляет etcher-cli, у которого даже GUI нет, но она всё равно весит 68 МБ (Windows AMD64) или даже все 78 МБ (Linux AMD64).
Клон dd — в 2400 раз больше оригинала! И во много раз тормознее, скорее всего
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 секунды.
вот вам кстати, разница в кеше которая «не важна».
Шутки шутками, но пора в дополнение к закону Мура придумывать закон кого-нибудь ещё (только, пожалуйста, не меня) об экспоненциальном возрастании тормозов.Закон Вирта?
Сейчас на своём Core i7 померил ради интереса — 9 секунд
У меня ворд 2013 открывается за секунду на i5 4670. Таки SSD поставить стоит. Ворд не столько кода выполняет много, сколько обращений к диску.
Только не говорите про возросшую функциональность. Она примерно такая же.
Т.е. номер версии просто так менялся все эти десятилетия? Функционала там вагоны нового. Для вас оно примерно так же, потому что вы используете его скорее всего как Wordpad какой-нить. Конечно с тех времен ничего не удаляли, а только прибавляли.
Таки SSD поставить стоит.
Да, I/O значит очень много.
Действительно, во времена 97 офиса на 98 винде Word открывался быстрее, чем на моем Core2 сейчас (5-15 с в зависимости от размера документа). В моем случае все «потуги» вызваны глючными драйверами Lenovo, которые неправильно отрабатывают Hibernate. Хотя жить от этого знания не легче.
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 на итерацию). Хммммммммм… интересно
Только не говорите про возросшую функциональность. Она примерно такая же.
Конечно. И у Visual Studio 2017 функциональность примерно такая же как у Visual Studio 6.
Но вообще-то нет.
Пользователь как правило не видит что что-то изменилось в лучшую сторону. Это воспринимается как само собой разумеющееся. Зато точно видит, что «раньше не тормозило».
Из нового ПО, которое использую на компе (ос 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к у.е.?
Иногда кажется, а может и не кажется, но нас маркетологи где-то на*бывают.
Одна радость души моей — 5-й WinAmp 2007-го года выпуска…
Ну и новые сайты не работают не по причине какого-то сговора сайтостроителей, а потому что за прошедшее время появилась куча всяких свистелок в веб-стандартах, которым, сюрприз, нужны ресурсы.
А потому немножко некорректно говорить, что софт становится тормознее без каких-то функциональных изменений.
есть Compatibility Pack для поддержки новых форматов, но, полагаю, не горите вы желанием им пользоватьсяЯ не знаком ни с кем, кто горел бы желанием пользоваться этим самым Compatibility Pack. Но что-то подсказывает мне, что это не потому, что все влюбились в риббон.
куча всяких свистелок в веб-стандартахТам вообще адъ
(Риббоны в офисе — это вообще офигенная штука, и как раз из-за них в свое время переходил на новую версию. Ну и из-за смарт-артов ещё.)
В вебе адищще, соглашусь. Но проблема тут не в браузерах как таковых, а в JS-ных поделиях по большей части, из-за чего браузерам пришлось как-то выкручиваться, чтобы всю эту хрень корректно и не очень медленно отображать. Полагаю, что если в новых браузерах открывать странички производства девяностых-двухтысячных годов, то и на старом железе тормозов не будет.
Так если вы говорите, что в старых офисах все было хорошо, чего не пользоваться-то?В старых офисах всё хорошо, за исключением одной проблемы: совместимости с новыми. И поскольку люди этими новыми фичами реально пользуются, то деваться некуда — приходится «жрать кактус».
Вот с текстовыми редакторами подобной проблемы не случается — и там таки да, вполне можно пользоваться 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 и пользовался…
Для меня эталоном сложностного тупика в своё время стала айбиэмовская вебсфера. Задача, которую она решает, проста и примитивна. Менеджер очередей сообщений. По сути, система почтовых ящиков. Неплохая тема для дипломного проекта в каком-нибудь ВУЗе средней руки. Как-то в цейтноте и безвыходняке я нечто подобное в наколеночном варианте набросал за вечер. Но… размер дистрибутива под 500МБ, и ресурсы жрёт так, будто исходит из предположения, что комп, на который оно установлено, больше ни для чего, кроме решения этой мелкой сугубо технической задачи, использоваться не будет. Когда-то оно наверняка тоже было маленьким и шустрым, а потом кабанело, кабанело и окончательно закабанело.
А в остальном спасибо, очень любопытное исследование!
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон.А вообще статьи пишут, чтобы их читали… Но видимо так — уже не модно.
Так где оно приведено? В статье нет этой информации
Во-вторых, спасибо за приведенную выше цитату, я её действительно не разглядел. Думаю, если бы автор изложил ее в следующем виде:
Для справки приведено время передачи пакета через весь земной шар по оптоволокну из Нью-Йорка в Нью-Йорк через Токио и Лондон. (п. табл. «Пакет вокруг света»)
то у меня бы вообще вопросов не возникло.
P.S. У людей может быть разное восприятие мира. Например, у меня в голове в час ночи фраза: «Пакет вокруг света» выглядит следующим образом.
События поступают в ядро через прошивку
Немного аккуратнее надо переводить :) Понятно, что кратко этот процесс описать нельзя, но…
Можно оригинал статьи посмотреть? Линк только на homepage сайта
В пользу этой версии говорят чуть ли нее все автомобильные интерфейсы ( а там это еще и безопасность) и вообще весь рынок смартфонов на Andoroid. (я лично протестировав кучу флагманов за последние три года так и не смог найти хотя бы одного с отзывчивостью хотя бы iPhone 4)
Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.
А вот со скоростью загрузки приложений тут да, ничего не попишешь.
Речь то была все таки про отклик, и про то что большинству оно в общем то и не нужно, либо не замечают. А при попытке продемонстрировать это, пользователи медленных девайсов включают защитную реакцию. Вон посмотрите на минусованый комментарий ниже.
Мне это не очень понятно, но похоже что для людями нравятся эти тупняки, или они их не замечают.Замечают. Но тот 1% пользователей, кто на это обращает внимание до покупки, а не после — давно сидят на iPhone'ах, а учитывая их количество — воевать за них бессмысленно.
«Отправить IP-пакет до Европы можно быстрее, чем вывести пиксель на экран. Какого х*ра?».
И, собственно, объясняет: superuser.com/a/419167
В smart TV от LG все так и есть
Если вы нажали кнопку и у вас вместо не произошло ничего (не появились песочные часики, не побежала полоса загрузки и т.п., да просто не посерела кнопка) то это на стороне банкомата.
Больше всего выбешивает переключение языка ввода, если быстро переключить язык и сразу начать набирать, то сюрприз, язык не переключится… Раньше такого не было.
p.s. Windows 7
На HTC Herald, под управлением Windows Mobile 6.5, все наоборот: программы запускаются довольно медленно, сам коммуникатор не был быстрым даже в свое время (200 мГц процессор и 64 МБ оперативной памяти), зато любой ввод обрабатывается молниеносно. Переключения языка выполняется отдельной кнопкой, и никогда не сбоит. Буквы на экране появляются сразу после нажатия кнопки. Писать на нем тексты — сплошное удовольствие.
После alt-tab-а может вообще не сработать.
А всякие rdp это просто "сказка"
Периодически хром впадает в ступор (например при открытии окна с другим профилем), да — у меня достаточно много вкладок и главный процесс хрома 2.85 Gb жрет.
Но вот только когда он впадает в ступор — иногда замирает вся система, музыка в iTunes (играемая с локальной медиатеки а не стримингом Apple Music) рывками идет и это слышно.
А с другой стороны как программист — планирую следующий мобильный проект и он видимо будет на JavaScript полностью или частично (правда на ReactNative а не Web-стеке). Потому что критически нужные библиотеки — только так подключить (все альтернативы не подходят либо по лицензии либо по функционалу, а бонусом рассчитываю что ReactNative даст возможность еще и UWP и macOS Desktop приложения сделать очень малой ценой).
Я сам из того поколения, которое привыкло получать мгновенный отклик. Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.
Сейчас же, когда я кликаю мышкой в тормозном интерфейсе очередной мега-IDE (как пример) и до её реакции успеваю произнести про себя слово «блин», а то и не раз, то меня это жутко раздражает.Меня больше всего раздражают неподгрузившееся картинки в вебе. Нажимаешь на какую-нибудь кнопку, начинает показываться анимация, и на момент вы видите иконку незагрузившейся картинки, а потом она уже появляется.
И вот что я заметил: если собрать ПК на базе 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). То эмпирически получим примерно ту же отзывчивость, которую имеем на моем достаточно современном компе с самым современным офисом. По базовому функционалу — ну разве что облака не будет :)
Во всем виноваты свисто-перделки, анимация и т.п., если под андроидом зайти в дев. режим и отключить анимацию, время отклика увеличится, но вам будет не комфортно
- Первое, от чего зависит Latency вывода на экран, это частота кадровой развертки видеосигнала. При частоте кадров 60Hz имеем возможный latency от начала к концу кадра 1/60=16мс. При частоте кадров 120Hz он уменьшается до 8мс.
- Внутренний буфер кадра ЖК-монитора запросто может дать еще задержку на кадр, что даст еще 1/60 = 16мс. Поэтому измерять задержку видео-камерой то еще занятие.
- В случае windows источником задержки служит дополнительный буфер композиции у менеджера композиции десктопа (dwm.exe). Aero даст большую задержку, нежели чем его отсутствие — весь вывод через Aero принудительно буферизуется во избежание tearing.
- DoubleBuffering или Page Flipping видеокарты даст 1/60 = 16мс.
И это только вывод. Если вся система так или иначе буферизует 3 кадра (скажем, 1 кадр монитор, 1 кадр page flipping видеокарты, 1 кадр Desktop Composite Manager), то одно только это уже дает 1/60*3=50мс.
Это далеко не единственный источник задержки в системе. Конечно, существуют переключения контекста операционной системы, прерывания, буферы драйверов, итд, итп — все это отдельный разговор. Моя задача была показать что способ измерения latency посредством съемки на камеру не очень подходящая метода для того чтобы делать далеко идущие выводы о latency обновления экрана современных устройств. Необходимо знать о внутренних буферах, о их необходимости, и о режимах работы в которых задержка минимальна.
А какой смысл во всём этом, если простой пользователь всё равно не будет проводить все эти манипуляции и у него в итоге все эти задержки всё равно будут? Как я уже отмечал выше, измерения в сферических условиях в вакууме не столь интересны. Таких условий всё равно ни у кого нет. Так-то можно на современный комп воткнуть какой-нибудь FreeDOS и получить офигенную скорость отклика, но зачем?
Впрочем, об этом даже в самой статье написано:
… измерения произведены с настройками, максимально близкими к настройкам ОС по умолчанию, поскольку примерно 0% пользователей меняют настройки дисплея для уменьшения буферизации, отключения компоновщика и т.д.
Кадр может быть отрисован в буфер очень быстро, дальше просто перенаправление выборки на новый адрес, в случае синхронизации да даст задержку до кадра, в случае без синхронизации задержки не будет.
С Windows 10 время отклика получается в среднем около 100 мс, на Linux Lite — 50.
Вот видео, если кому любопытно (замедлено в четыре раза): youtu.be/u2OBKcLRFxk
Человек двигает стилусом квадратик на экране (или пишет текст). Дополнительная задержка приводит к тому, что объект смещается чуть позже. В статике эти миллисекунды, понятное дело, не заметны, но в динамике, когда человек следит глазами за движением, это можно увидеть.
Судя по работе, получается, что разница в 5 миллисекунд при быстром движении стилуса оказывается вполне заметной. Если двигать стилус со скоростью 200 уэе* в секунду, то лаг в 5 мс приведёт к отставанию объекта от стилуса на 1 уэе. Если перемещается объект размера 5х5 уэе, то это может быть заметно.
* условная экранная единица
Но работа, конечно, мутновата: как можно заметить разницу между 1 мс и 2 мс, используя 480 fps камеру, мне не понятно.
Т.е. например, если реакция в боевых искуствах, ввы можете среагирповать на удар заблокировать его, быстрее чем 200 мс. Но эта реакция будет раньше вашего осознания происходящего, потом мозг склеит все в буфере и отдаст как одно событие увидел-принял действие-заблокировал-увидел результат.
Да можно заметить эти самые 2 мс, но только если они на границе, т.е. если есть предположим задержка в 200 мс и мы на нее не реагируем, т.к. она попадает в буфер. Но уже 202 мс, дадут ощущение запаздывания.
Самый простой эксперимент, который очень любит мой сын, можно найти растояние при котором хлопок и звук от него будут восприниматься одновременно, но буквально через метр, уже будет ясно различимая задержка.
В общем саму по себе задержку в 2 мс, человек не осознает (фиг знает может есть мутанты без буыера).
P.S. а что за Linux chroot среди ОС?
Повторю мысль, пришедшую мне в голову месяц назад:
Кажется один из факторов — культурный. В информационном поле почти отсутствует мысль о важности отзывчивости и легковесности. Вот сколько я встречал списков сравнения best N apps for task X — не припомню, чтобы хотя бы в одном из них был замер использованного процессорного времени и памяти на выполнение аналогичных действий, примерно как я искал себе быстрый просмотрщик изображений. Вот в качестве пруфа можно погуглить "image viewers performance comparison" — очень мало ожидаемых результатов, всего ~3 в первой десятке! А для запроса "bittorrent clients performance comparison" в первой десятке только одна релевантная ссылка аж от 2010 года (ну и для справедливости ещё одна работа со сравнением скорости скачивания двух клиентов).
В идеальном мире в сравнительных обзорах были бы сравнения производительности с замерами, что давало бы разработчикам соревновательный стимул к оптимизации. Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.
Да, premature optimization — зло, но если ты вообще не прогонял свою программу через профайлер, то ты редиска.Почему? Если пользователям пофиг?
Но так ведь не бывает — если вы затратите ресурсов на пристальное изучение программы под профайлером, то затраты на неё возрастут, а знать — возрастёт и цена.
И если смотреть на продажи iPhone'ов — то хорошо видно, что, люди вполне готовы терпеть тормоза, чтобы получить не такую и большую экономию в цене (я специально взял для оценки iPhone, которые, как известно считаются фанатами всего самого нового, самого крутого, самого быстрого… думаю среди покупателей других телефоном таких будет ещё меньше).
Почему вы считаете, что ситуация с софтом должна быть иной?
Для начала эту ветку комментариев я начал с введения тезиса, что отчасти медленная отзывчивость и общая тормознутость наших компьютеров вызвана недостаточным присутствием в культуре убеждения о важности отзывчивости и легковесности (что в разной степени присуще пользователям, авторам обзоров, производителям софта и железа). И дальнейшая дискуссия мне интересна как обсуждение этого тезиса.
Пользователям не "пофиг" в смысле отзывчивость приложений существенно влияет на комфортность их использования, о чём говорят например исследования влияния скорости загрузки сайтов на поведение пользователей и сам Dan Luu приводит в статье некоторые размышления. Но частично важность отзывчивости не осознаётся самими пользователями, что является частью моего исходного тезиса.
Теперь как можно трактовать статистику активаций ифонов. Во-первых, самые популярные модели по этой статистике стоят от трети до половины дешевле топовых. Разве это небольшая экономия в цене? Да пользователю вообще может быть выгоднее купить модель на 300$ дешевле, а потом потратить на 100$ больше на покупку софта под свои задачи, выбирая более дорогие вылизанные программы. Собственно мне кажется, что есть множество классов программ (какие-нибудь приложения аптек например), где на оптимизацию тратят ресурсов примерно 0, если там заложить под оптимизацию хотя бы 5% бюджета, ускорение может быть в разы.
Исторический экскурс в 1987 год:
"Операционные системы: зачем они инженеру"
Время отклика компьютеров: 1977−2017