Самый быстрый терминал

А после ctrl-alt-f2 они что кажут?

Там использовалась программа на Java, Typometer, которая генерирует события ввода с клавиатуры и потом считывает с экрана, что на нём нарисовал терминал. Как ты такое сделаешь в консоле? Там, наверное, только камерой можно измерить задержку.

Занятно. Для 60 fps монитора между двумя кадрами аж 17 мс, но все равно может повлиять.

Там использовалась программа на Java

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

Равняйтесь на HFT, там счёт на наносекунды.

Но на кнопки ты нажимаешь не в начале фрейма, а когда угодно.

Но потом кто-то из ST подсуетился и улучшил среднее время отклика до 5-6 мсек

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

Штош.. Продолжим пользоваться gnome-terminal.

Штош.. Продолжим пользоваться konsole.

Поправил, не благодари.

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

В чем ужасен? Дефолт для меня это Yakuake.

Всякие китти и алакритти с OpenGL запускаешь что-то с мощным выводом в консоль и происходит прррррр-дрррррр лаги. Urxvt, konsole, gnome-terminal, xterm - полёт нормальный. Дрова на видео разумеется есть, игры выдают ~виндовый fps

Между tilix и alacritty «визуальной» разницы в наборе текста не заметил. И вот это, 2.8ms, это каждый вводимый символ столько отнимает времени? Некоторые команды сопоставимы по времени выполнения. Например clear в окне с одинаковой геометрией, 140х38, и заполненной символами одной страницей буфера:

tilix:     real	0m0.002s
alacritty: real	0m0.002s

foot ещё шустрый, странно, что его в список не добавили.

Штош.. Продолжим пользоваться rxvt.

Поправил, не благодари.

Пришлось поправить за тобой немного. Не за что.

Урааа, мой самый быстрый)

Так там небось этот жабий типа метер больше задержек давал.

терминал это не столь актуально. постоянно ведь не набиваются команды со страшной скоростью :-)

веселее должно быть с редакторами/ide, потому что даже без десятипальцевой печати - многие фичастые «со свистоперделками» выбешивают от того отклик нажал-увидел становится ощутим

В сентябре 2022г. играл в эту игру.

У меня этот typometer намерил (Avg, ms):
XTerm 9.1
Zutty 14.4
urxvt 24.9
Xfce-treminal 36.5
Alacritty 37.4

Лаг в alacritty. ЧЯДНТ? (комментарий)

xterm рулит уже много десятков лет

А ты относись к этому философски. Пока компьюхтэр считает тебе копейку продолжают платить.

РОФЛ, десятые миллисекунды он намерил. Какая герцовка у экрана?

постоянно ведь не набиваются команды со страшной скоростью

Не, суть-то не в скорости набивания команд, а в скорости вывода.

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

По крайней мере я с этой стороны заходил на эту игру.

А я не так уж и плох.

Не, суть-то не в скорости набивания команд, а в скорости вывода.

Разговор про скорость ввода с клавиатуры. Про задержку между нажатием клавиши и отрисовкой символа в терминале.

По моему один из самых честных тестов:

xterm:

$ time seq 1000000 
    0m17.36s real     0m01.39s user     0m02.30s system

urxvt

$ time seq 1000000
    0m03.42s real     0m01.11s user     0m02.14s system

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

Так это же оно и есть - скорость рисования символа.

Оно там что, биткойны майнит? У меня сайт за 0..1мс иные запросы обслуживает – и это Firefox показывает в F12 / Network.

Так это же оно и есть - скорость рисования символа.

Например, нажал символ a и ждешь пять единиц времени пока он отрисуется. А вывод того же символа с помощью echo мгновенный. Значит это не одно и тоже.

Что-то я не доверяю этим тестам.

терминал это не столь актуально. постоянно ведь не набиваются команды со страшной скоростью :-)

веселее должно быть с редакторами/ide, потому что даже без десятипальцевой печати - многие фичастые «со свистоперделками» выбешивают от того отклик нажал-увидел становится ощутим

Да, я поэтому Идею не смог использовать. Она слишком тормозит, особенно при печати это видно.

1000000 маловато, у меня за доли секунды идёт, погрешность великовата.

Потестил два своих основных терминала (нынешний и прошлый) таким образом.

hyperfine --show-output 'seq 10000000'

foot:

  Time (mean ± σ):      2.765 s ±  0.025 s    [User: 0.057 s, System: 2.702 s]
  Range (min … max):    2.733 s …  2.804 s    10 runs

urxvt:

  Time (mean ± σ):      3.277 s ±  0.037 s    [User: 0.063 s, System: 2.803 s]
  Range (min … max):    3.219 s …  3.327 s    10 runs

Ещё можно вот так. По-моему, честнее, если длинные строки:

dd if=/dev/urandom count=1000000 | base64 -w 0 > /tmp/testfile
# ^ один раз, чтоб честно одинаковый вывод был в разных терминалах
hyperfine --show-output 'cat /tmp/testfile'

foot:

Time (mean ± σ):      3.638 s ±  0.032 s    [User: 0.002 s, System: 1.603 s]
Range (min … max):    3.587 s …  3.688 s    10 runs

urxvt:

Time (mean ± σ):      7.536 s ±  0.082 s    [User: 0.003 s, System: 1.744 s]
Range (min … max):    7.409 s …  7.707 s    10 runs

xterm:

Time (mean ± σ):     11.063 s ±  0.058 s    [User: 0.001 s, System: 1.695 s]
Range (min … max):   10.972 s … 11.159 s    10 runs

А вот жабоподелие (и саму жабу…) ставить, чтобы измерить то, что намеряли в сабже, как-то лень. По ощущениям во всех трёх «мгновенно», при всём желании не могу увидеть разницу, и этого достаточно. Гораздо важнее именно скорость вывода больших объёмов данных, если что-то их генерирует.

Тут надо учитывать что time тут измеряет работу именно процесса seq, и seq буквы нигде не рисует - только шлёт их в stdout. Если из-за тормозов терминала он не успеет прочесть из пайпа и пайп переполнится - по идее это время seq проведёт в слипе и оно не должно отразиться на затраченном cpu time. А вот затраченное время на слип зависит от длины ipc-буфера. Поставишь в 10МБ его - выполнится как раз за user+system секунд, терминал уже потом будет всё рисовать, не торопясь разбирая буфер.

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

Почему отличается user и system - отдельный вопрос. Возможно urxvt читает из пайпа большими кусками, в результате чего большими может записывать и seq, что сокращает количество сисколлов.

Скорее всего мерилка на вялом не работает.

терминал это не столь актуально. постоянно ведь не набиваются команды со страшной скоростью :-)

А если вим или емакс в терминале? А если это еще и в ssh сессии до хоста с задержкой в 30мсек? Суммарный лаг может быстро перевалить за 50мсек, а это уже заметно.

Ты путаешь понятия latency и throughput. То, что терминал может показать 100МБ файл за 3 секунды не значит, что при вводе с клавиатуры один символ выводится за 30 наносекунд.

Этот мир заслуживает на измерения скоростей ... эмуляторов терминала.

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

Я не путаю, я как раз в конце своего поста чётко подытожил, что второе мне важнее, ежели latency укладывается в какие-то (не знаю, какие точно) значения, воспринимаемые юзером как «мгновенно». Да, если символ будет появляться через полсекунды, это будет доставлять дискомфорт. Но вот я сравнил xterm и urxvt (и foot заодно), и как не стараюсь, ну никак не могу увидеть разницы в latency между ними. По ощущениям и там и там символ на экране появляется в момент «щелчка» клавиши. Если юзер даже специально не может заметить разницу в 4 раза (не говоря уж о каких-то испытываемых неудобствах), значит, не имеет значения, какие именно там цифры, если это самое latency не выходит за некие рамки, за которыми оно становится заметным.

Если ты не путаешь, зачем меряешь throughput?

ШОК! СЕНСАЦИЯ! Терминал без нифига работает быстрее терминалов с дофига! И чем более дофига, тем медленнее работает терминал!

Я вот одного понять не могу: кто вы, инженеры-turned-машинистки? Вы там что, круды на скорость набираете или да?

Просто если я работаю со сложной кодовой базой (такой, на которой идея и «братья» начинают иметь смысл), то я 49.5% времени читаю существующий код, 49.5% времени думаю и 1% времени непосредственно печатаю. Скорость реакции среды на клавиши, все эти субмиллисекундные загоны, не парит от слова вообще (ладно, хорошо, начинает парить где-то с 150 мс задержки, но так не тормозит даже идея).

Чтобы определить, какой терминал действительно «самый быстрый». В том, что действительно важно и заметно юзеру, а не как в оригинальном посте.

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

Как раз таки юзеру заметно, когда он нажимает на кнопку, а терминал выводит символ с задержкой, а не то, что ты померял. Ты сам у себя не замечаешь задержки, потому что она меньше 50мсек. А как только ты из этого терминала зайдёшь на другую машину, до которой latency еще 20-30мсек, то здесь ты уже её заметишь, так как полная задержка превысит 50мсек. Поэтому и важно иметь терминал с минимальной задержкой, чтобы когда ты сложишь все остальные задержки, ты бы всё равно воспринимал свой терминал как отзывчивый.

А как только ты из этого терминала зайдёшь на другую машину, до которой latency еще 20-30мсек, то здесь ты уже её заметишь, так как полная задержка превысит 50мсек.

Такого у меня не случается. Думаю, у других тоже. Нет, бывает иногда, что через какие-нибудь VPN и далеко, так вообще под 200 мс. Но тут уже в любом случае медленно, хоть оно будет 205, хоть 220. Случай, где вот ровно эти 15 мс разницы играют роль — редкий и какой-то вымученный.

Другое дело, когда заметно, как терминал перерисовывается, или при выводе больших объёмов текста. Вот тут да, сразу же заметно, какой xterm тормозной по сравнению с остальными (st, кстати, на удивленее тоже).

В konsole:

real 0m0.859s
user 0m0.020s
sys  0m0.683s

Я вот одного понять не могу

Я вижу, что не можешь. На самом деле, проблемы две:

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

2. Мой комп без проблем рендерит сложнейшую 3D-графику в реальном времени. Хер-трейсинг в 60fps – пожалуйста. Так что если за 16.66666 миллисекунд комп может обсчитать 3D-сцену с кучей объектов, физикой и так далее в сраном куберпунке, и всё это учитывая ввод с клавиатуры и мышки, то какого же хера отрисовать-то буковку на экране за это же время такая проблема? Авторы редакторов – настолько конченые говнокодеры? Или что вообще происходит-то в этом вашем мире IT, что такое днище считается нормой? Вот поэтому и сидим на емаксе до сих пор, айтишники-линуксоеды блин редактор даже родить не могут :(

А если вим или емакс в терминале? А если это еще и в ssh сессии до хоста с задержкой в 30мсек? Суммарный лаг может быстро перевалить за 50мсек, а это уже заметно.

угу..kterm и в нём vim. по ssh :-)

терминал это не столь актуально. постоянно ведь не набиваются команды со страшной скоростью :-)

А если вим или емакс в терминале? А если это еще и в ssh сессии до хоста с задержкой в 30мсек? Суммарный лаг может быстро перевалить за 50мсек, а это уже заметно.

Я тут недавно vim с трёхсекундным лагом по SSH использовал. Очень интересные ощущения :)

редактор даже родить не могут

А емакс и вим разве не редакторы?

редактор даже родить не могут

А емакс и вим разве не редакторы?

Emacs и Vim появились задолго до Linux. Первые их версии к Linux/Unix даже близко отношения не имели. Emacs (не гнутый, до него) был под Multics и VMS изначально, Vim же писался под Амигу. Линуксовые сообщества из редакторов родили только GEdit и Kate, но кто ж ими пользуется-то? Я даже в KDE использую Emacs.

Ну и плюс, я бы не сказал, что Emacs или Vim – прямо такие скоростные редакторы. Во-первых, у них GTK вместо гуя у обоих. А во-вторых, до недавнего времени оба были однопоточны по самые гланды, и любой подвисший скрипт вешал интерфейс напрочь. Некоторые плагины до сих пор вешают. Асинхронные плагины в обоих редакторах появились вот буквально в последние лет 5-7. Vim для этого аж форкнуть пришлось в NeoVim, потому что разрабы оригинала были против подобного.