Quanto os terminais do GNOME 46 ficaram mais rápidos

 (bxt.rs)
3 pontos por GN⁺ 2024-04-09 | 1 comentários | Compartilhar no WhatsApp
  • No ciclo do GNOME 46, a latência de entrada dos terminais baseados em VTE caiu bastante, chegando muito perto do Alacritty, usado como referência rápida nos testes do Fedora 40
  • A medição foi feita com sensores de hardware para capturar a latência de entrada ponta a ponta, do pressionamento da tecla até a mudança de pixel na tela, refletindo junto os tempos de resposta do kernel, compositor, app e monitor
  • Tanto na entrada simples com cat > /dev/null quanto no scroll do neovim mais complexo, Console, VTE Test App e GNOME Terminal mostraram melhora clara em relação ao GNOME 45
  • A principal mudança provavelmente foi a troca no VTE do antigo temporizador de repaint de 40Hz por um redesenho a cada frame sincronizado com o monitor
  • Os terminais do GNOME 46 com VTE 0.76 têm latência perceptível menor, então até quem evitava terminais baseados em VTE por serem lentos pode querer testá-los de novo

O que mudou nos terminais baseados em VTE

  • VTE é a biblioteca Virtual TErminal que serve de base para vários emuladores de terminal do GNOME
  • Durante o ciclo do GNOME 46, o VTE recebeu muitas melhorias de desempenho, e a latência de entrada percebida de fato pelos usuários virou um dos principais pontos de verificação

Como a latência de entrada foi medida

  • Latência de entrada é o tempo entre apertar uma tecla no teclado e a mudança de cor de um pixel no monitor
    • Quanto menor a latência, mais imediato o app parece responder
    • A diferença fica mais evidente ao comparar alternadamente baixa e alta latência
  • Em vez de captura de tela por software, foi usado um testador de latência de entrada em hardware
    • Um sensor de luz foi conectado a uma placa Teensy, que por sua vez foi ligada ao computador via USB
    • O sensor observa uma pequena área da tela, como uma célula de caractere do terminal, cujo brilho muda com a entrada do teclado
    • A placa envia uma tecla como Space, detecta a mudança de luminosidade e depois usa uma segunda tecla como Backspace para voltar ao estado original
    • Entre as repetições, é adicionado um tempo de espera aleatório para evitar que a medição fique presa à taxa de atualização do monitor
  • Esse método mede a latência ponta a ponta, incluindo tempos de resposta do kernel, compositor, aplicação e monitor
    • A latência do firmware do teclado fica de fora
    • Com a placa e o firmware atuais, são registrados cerca de 35.500 valores do sensor de luz por segundo
  • Cada teste foi repetido 120 vezes
    • O formato esperado é uma distribuição de pontos espalhada de forma aproximadamente uniforme ao longo de um ciclo de atualização do monitor
    • Em um monitor de 144Hz, um ciclo de atualização dura cerca de 6,94ms, e os pontos dos gráficos de exemplo se espalham na faixa de 7–8ms
    • Outliers altos ou uma distribuição mais larga podem indicar latência maior ou processamento mais lento no app testado

Ambiente de teste e comparativos

  • O sistema de teste foi um notebook Lenovo Legion 7 Gen 7 AMD
    • CPU Ryzen 7 6800H
    • GPU Radeon RX 6700M dGPU, usando apenas a dGPU via chave MUX
    • Monitor Acer Nitro XV320QU, 2560×1440, 144Hz, escala de 100%
    • Host com Fedora 40 Silverblue Beta e Mesa 24.0.4
    • O compositor foi o raw Mutter 46.0
  • raw Mutter é um ambiente de teste simples em que só o Mutter roda, sem o GNOME Shell
    • Pode ser executado com um comando como mutter --display-server -- alacritty
    • É uma condição próxima do ideal, com quase nenhuma sobrecarga do GNOME Shell
  • Foram comparados quatro terminais
    • Alacritty: não é baseado em VTE e serve como referência por ser consistentemente rápido em testes anteriores
    • Console: terminal padrão do GNOME baseado em GTK 4
    • VTE Test App: terminal de teste em GTK 4 presente no repositório do VTE
    • GNOME Terminal: no GNOME 46, ainda é um app GTK 3 e vem por padrão em várias distribuições
  • Para comparar GNOME 45 e GNOME 46, foram usados contêineres toolbox do Fedora 39 e Fedora 40
    • Cada terminal foi instalado a partir dos pacotes padrão do Fedora e executado sem ajustes extras
    • As janelas foram posicionadas no canto superior esquerdo do monitor, e o cursor do mouse ficou fora da janela para que a lógica de detecção de links não distorcesse os resultados

Resultados com entrada simples e scroll no neovim

  • O primeiro teste executou cat > /dev/null e mediu quanto tempo levava para o cursor em bloco se mover uma posição para a direita após pressionar Space
    • É um cenário de sobrecarga mínima, sem processamento extra como readline
    • O Alacritty, como esperado, não mudou entre Fedora 39 e Fedora 40
    • Os terminais baseados em VTE melhoraram bastante no GNOME 46 em relação ao GNOME 45, chegando quase ao mesmo nível do Alacritty
    • Até o GNOME Terminal, baseado em GTK 3, apresentou resultado muito próximo
  • A principal causa da grande melhora provavelmente foi uma mudança no VTE feita por Christian Hergert
    • O VTE deixou para trás o antigo temporizador de repaint de 40Hz
    • Como uma widget GTK, passou a desenhar a cada frame em sincronia com o monitor
  • O Console teve alguns outliers, possivelmente por causa do rastreamento de processos
    • Isso não é um fenômeno novo
    • Fica como algo a observar no GNOME 47
  • O segundo teste usou uma configuração mais realista de neovim
    • Um snapshot da configuração do neovim abriu o README do Ptyxis, e parte do texto foi trocada por caracteres Unicode de bloco cheio para que o sensor óptico pudesse detectar a mudança
    • Ctrl+D e Ctrl+U foram repetidos para rolar o buffer de texto para baixo e para cima
    • O terminal precisava desenhar elementos de tela como sublinhado, undercurl, ícones da gutter e barra de status
  • A melhora dos terminais do GNOME 46 também ficou clara no teste com neovim
    • Os terminais baseados em VTE no GNOME 46 continuaram muito próximos do Alacritty
    • Considerando só os resultados do Fedora 40, o teste com neovim aumentou a latência em relação ao teste simples com cat, mas o aumento foi parecido em todos os terminais

As outras diferenças mostradas pelo vtebench

  • vtebench é um benchmark automatizado que mede desempenho de leitura e parsing de PTY, não latência de entrada
    • Como não trata de fatores importantes como frame rate ou latência, ele não basta para entender o desempenho geral de um terminal
    • Ele pressiona fortemente apenas a velocidade com que o terminal lê do PTY
  • O tempo de repaint também pode afetar os resultados do vtebench
    • Isso pode pesar especialmente em terminais como o VTE, em que leitura/parsing do PTY e lógica de repaint rodam na mesma thread
  • O VTE do GNOME 46 também melhorou no vtebench
    • O tamanho do ganho foi mais variado do que nos testes de latência de entrada
    • Ainda não alcança o nível do Alacritty, que faz leitura e parsing em threads separadas da renderização
    • Essa melhora parece vir de várias otimizações aplicadas ao VTE durante o ciclo do GNOME 46
  • Os benchmarks dense_cells e unicode foram excluídos do gráfico principal de resultados
    • Esses dois itens são os principais testes de estresse do vtebench
    • O VTE ainda mostra resultados muito instáveis neles, o que prejudica a legibilidade do gráfico
  • Pelos casos testados, a diferença restante está próxima de ser praticamente irrelevante
    • Parte dela pode ser explicada pelo trabalho extra que o VTE faz para acessibilidade, cálculo da barra de rolagem e outros recursos
    • A acessibilidade está ativada no GNOME Terminal e atualmente desativada nos terminais GTK 4
    • Com VTE 0.76, dá para obter o desempenho com as melhorias do GNOME 46

Leituras relacionadas

1 comentários

 
GN⁺ 2024-04-09
Comentários do Hacker News

  • Graças a essa mudança, a mediana de latência de entrada na configuração testada finalmente ficou abaixo da do Apple //e. O Console ficou em cerca de 12 ms, enquanto o Apple //e de 1983 era de 30 ms; levou 41 anos
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Dito isso, esse benchmark não usou o GNOME Shell, mas sim o compositor raw Mutter 46.0, e o raw Mutter é um ambiente muito básico, quase voltado a testes. Além disso, ele não inclui a latência do teclado, então também não é uma medição de ponta a ponta. Nesse teste, a placa envia a entrada de teclas via USB, mas só a latência interna do teclado pode chegar a 60 ms
    https://danluu.com/keyboard-latency/
    Eu queria muito saber os números reais de ponta a ponta da configuração padrão que realmente importa; teria sido bom se o artigo tivesse medido isso. O trabalho da equipe do GNOME e do autor do benchmark é excelente, mas a pergunta importante continua em aberto. O Apple //e usava aceleração por hardware e nem lidava com Unicode, então há muitas diferenças, mas ainda assim seria bom poder voltar à responsividade humana de uma máquina com mais de 41 anos

    • Na verdade, acho que o autor fez bem em excluir a latência do teclado. Cada pessoa usa teclados, interfaces USB, computadores e versões de sistema operacional diferentes, e ainda podem entrar hubs ou KVMs no meio
      Se a latência desses componentes variar muito durante o teste, fica difícil analisar o ponto central deste texto, que é a melhoria de latência no VTE. Mesmo que ela fosse perfeitamente constante, apenas seria somada ao valor absoluto como uma constante, sem mudar a conclusão. Por isso, não se deve expressar diferenças de latência em percentual. No conjunto de amostras há uma constante que pode ser normalizada, mas na população total de usuários há muitas constantes que não podem ser normalizadas. A parte do Mutter é interessante; como o GNOME roda sobre o Mutter, parece provável que a melhoria absoluta de latência apareça de forma parecida. Ainda assim, o GNOME também pode criar variações indesejadas, como a latência do teclado, então eu gostaria de ver isso verificado na prática
    • Então é só usar um Apple 2e e abrir mão dos recursos de conveniência de um sistema operacional moderno. É difícil aceitar isso quando soa como uma longa crítica depreciativa a desenvolvedores open source que estão se esforçando para oferecer algo de graça
    • Sempre me incomodou um pouco que a metodologia do artigo sobre latência de teclado linkado inclua até o tempo que a tecla leva para se mover fisicamente
    • Processar Unicode não é um problema tão difícil quanto as pessoas acreditam. Existem casos de borda estranhos, mas não são muitos e são fáceis de resolver
      O que realmente me incomodou neste texto foi que, antes da versão de teste mais recente, a taxa de redesenho no Gnome era fixa em 40 Hz. Quem diabos decidiu isso?
    • A afirmação de 60 ms no artigo sobre latência de teclado é suspeita. Se uma latência da tecla até o USB de 60 ms fosse comum em teclados, jogos de ritmo seriam literalmente impossíveis de jogar. E, no entanto, nunca tive esse problema com nenhum teclado que usei até hoje

  • Ótimo. Também gosto do fato de os desenvolvedores do VTE terem se concentrado em desempenho, e o processo de medição baseado em hardware do texto é impressionante
    O uso de um sensor óptico para medir latência me lembrou o produto de nome nada discreto “Xbox One Controller Monitor” [1], do Ben Heck. Ele lê diretamente o estado dos botões de um controle de console e o combina com um sensor óptico para ajudar desenvolvedores de jogos a manter a latência baixa. Parece bacana, mas custa 900 dólares
    [1]: https://www.benheck.com/xbox1monitor/

    • Esse foco em desempenho é algo recente. O VTE era bem lento originalmente
    • Curiosidade: com a sincronização vertical ativada, a latência depende de onde você coloca o sensor

  • Tanto este texto quanto o texto linkado colocam o sensor óptico mais ou menos no meio do monitor. Isso não é problema para comparar medições, mas em boa parte dos monitores comuns, a 60 Hz, colocar o sensor na parte de cima da tela mede cerca de 8 ms mais rápido, e colocá-lo na parte de baixo mede cerca de 8 ms mais lento. Isso acontece porque os pixels ou linhas são acionados de cima para baixo, basicamente como em um CRT
    Então, se for entrar nos detalhes, isso também deveria ser mencionado, assim como onde definir o limiar do sinal do sensor óptico para considerar que o pixel acendeu. Pelos números do texto, 8 ms é uma diferença bem grande. Da mesma forma, apenas dizer “o monitor X é 30 ms mais lento que o monitor Y” pode ser um exagero. O correto é entender como “foi isso que medi na minha configuração e com as configurações X, Y e Z”. É preciso verificar se o monitor está aplicando algum recurso de melhoria estranho que só adiciona latência e não tem efeito perceptível, e também se, ao trocar de monitor, a placa de vídeo ou o driver não resolveu “ajudar” e mudou sorrateiramente para algum perfil de correção, escalonamento ou melhoria. Esses dispositivos normalmente não avisam nada, e eu já vi alguns casos assim

    • Se eu estiver vendo a tela rolar em tempo real, é muito mais provável que eu olhe para o terço inferior da tela

  • É engraçado vivermos em um mundo capaz de renderizar cenas 3D surreais e jogos que pareciam impossíveis em hardware de consumo, e ao mesmo tempo ainda estarmos tentando aperfeiçoar a tarefa de imprimir texto em um terminal

    • Acho que parte disso pode ter surgido justamente por otimizar mais para gráficos. Há um compromisso entre as duas coisas, e conforme os gráficos melhoram, o texto pode tender a piorar. Terminais usam aceleração por GPU e compensam parte disso, mas ainda assim pagam o custo desse pipeline gráfico
    • Talvez antes isso simplesmente não importasse tanto. Era mais um “funciona”, e até pouco tempo atrás, em muitos usos de terminal, havia uma latência de rede grande a resolver

  • Não tem relação com velocidade, mas fiquei curioso se existe no Linux um terminal que, como o Terminal do Mac OSX, restaura todas as abas, o histórico de comandos de cada aba e o scrollback ao fechar e abrir de novo. No Mac, isso é tratado configurando um arquivo de histórico do bash diferente para cada aba
    Para esse uso, prefiro um terminal com GUI

    • É um assunto um pouco diferente, mas acabei de descobrir, há 1 hora, que o iterm2 do Mac pode se integrar ao tmux. Se você executar o tmux com o argumento -CC, a sessão do tmux é mapeada para as janelas e abas da GUI do iterm2, e isso também funciona usando o tmux de uma máquina remota via ssh
      Eu sempre esqueço os atalhos e comandos de controle do tmux, então estou bem animado com esse recurso
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Fico curioso sobre o que acontece se você fechar todas as abas e depois abrir uma nova. Será que o histórico por aba é mesclado de volta no arquivo de histórico comum ao fechar, para que esses comandos também possam ser usados na nova aba?
    • Eu uso Tmux. Por ser um multiplexador independente do terminal, ele oferece persistência e capacidade de automação poderosas
      https://github.com/tmux/tmux/wiki
    • Talvez você não goste se prefere um terminal com GUI, mas pode ser útil para alguém: https://github.com/tmux-plugins/tmux-resurrect
      Claro, o tmux pode ser usado com qualquer emulador de terminal com GUI que você quiser
    • Eu estava procurando exatamente a mesma coisa. Hoje uso tmux e tmux-ressurect para manter o estado entre reinicializações; funciona mais ou menos, mas é só um bom hack e ainda parece um hack
      É uma pena que, tirando o warp, quase não existam soluções reais para esse problema. Meu pequeno sonho de UX é que essa funcionalidade de salvar espaço de trabalho seja integrada ao sistema operacional inteiro e aos apps dentro dele. Seria ótimo

  • Usei Gnome por alguns anos e mudei para sway e alacritty há 2 anos; sinceramente, não percebo diferença nenhuma. Como em equipamentos de áudio high-end, acho que meus ouvidos e olhos não são calibrados para distinguir essa diferença

    • Já tentou voltar? Muitas vezes é mais fácil perceber quando a latência aumenta do que quando ela diminui
    • Usei Gnome por alguns anos e agora estou no Gnome 46, mas não percebi diferença de latência no terminal em comparação com o Gnome 45. Acho que eu também não sou muito bom em notar essas coisas
    • Talvez não seja uma comparação justa, mas, cerca de 20 anos atrás, enquanto compilava o kernel, o gnome-terminal usava metade da CPU, então decidi não usá-lo mais. O Xterm usava cerca de 2%
    • Em latência ou responsividade, a única coisa que me importa é se o terminal me faz sentir vontade de vomitar ao rolar no vim
    • A tela ou o teclado já podem estar adicionando latência suficiente para que nenhum software dê um bom resultado. A diferença entre latência ruim e latência muito ruim não é tão clara. Fico curioso se você já experimentou hardware gamer

  • Finalmente surgiu um benchmark de terminal que não é apenas dar cat em um arquivo enorme. Gostaria de ver mais terminais, especialmente até o console padrão do Linux, no mesmo teste

  • Fugindo do assunto, o que mais odeio no Gnome Terminal é que ele abre uma janela pequena por padrão. Tem mais ou menos 1/4 da minha tela e, mesmo se eu redimensionar, ele não lembra depois de reiniciar. No fim, tenho que entrar nas configurações e especificar manualmente o número de colunas e linhas

    • Esse comportamento é bem comum em muitos terminais. De cabeça, tanto o Terminal padrão do macOS quanto o Windows Terminal exigem mudar o tamanho padrão nas configurações
      Pessoalmente, prefiro manter o tamanho padrão e redimensionar só janelas específicas que precisam de mais espaço. Ainda assim, deveria haver pelo menos uma opção para lembrar o redimensionamento
    • Dá para mudar nas configurações
      Vá em menu hambúrguer > Preferences > nome do perfil. Meu perfil é simplesmente “Unnamed”. Altere “initial terminal size” e fica como você quiser. Eu deixei em 132x43
    • Muitas vezes deixo vários terminais abertos, cada um com tamanhos diferentes. Não fica claro qual tamanho seria o certo para lembrar
      Por isso, prefiro que não tentem fazer isso. Quando o software pode ter certeza do que eu quero, tudo bem ele agir de forma inteligente; caso contrário, vira mais um caso de “eu estraguei tudo automaticamente para você. Agradeça?”
    • O terminal mais novo do gnome, o Console, lembra o tamanho da janela
    • Pelo que lembro, isso era um recurso vindo do CMD.EXE

  • Quando for lançado, seria bom incluir também o terminal Ghostty de Mitchell Hashimoto nos benchmarks. Ele ainda está em desenvolvimento e polimento, em beta fechado
    https://mitchellh.com/ghostty

  • Uso xterm e i3wn no debian e nunca experimentei nada mais rápido. Nunca nem pensei em desperdiçar GPU com um terminal, então, pessoalmente, acho o alacritty exagerado

    • Também sinto algo parecido. Nunca pensei em latência ao usar xterm. Mesmo usando diariamente recursos pesados como tradução ou sixel. Acho que as pessoas o ignoram por causa do estilo dos widgets Athena, mas na prática ele é excelente