Mức cải thiện tốc độ của terminal GNOME 46

 (bxt.rs)
3 điểm bởi GN⁺ 2024-04-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong chu kỳ GNOME 46, các terminal dựa trên VTE đã giảm đáng kể độ trễ nhập liệu, gần tiệm cận Alacritty vốn được dùng làm mốc nhanh trong thử nghiệm trên Fedora 40
  • Việc đo đạc được thực hiện bằng cách dùng cảm biến phần cứng để đo độ trễ nhập liệu đầu-cuối từ lúc nhấn phím đến khi pixel trên màn hình thay đổi, nên thời gian phản hồi của kernel, compositor, ứng dụng và màn hình đều được phản ánh
  • Cả tác vụ nhập đơn giản với cat > /dev/null lẫn cuộn neovim phức tạp đều cho thấy Console, VTE Test App và GNOME Terminal cải thiện rõ rệt so với GNOME 45
  • Thay đổi cốt lõi nhiều khả năng là VTE đã bỏ bộ hẹn giờ vẽ lại 40Hz trước đây để chuyển sang vẽ lại theo từng khung hình đồng bộ với màn hình
  • Terminal GNOME 46 dùng VTE 0.76 cho cảm giác độ trễ thấp hơn, đủ để những ai từng tránh terminal dựa trên VTE vì chậm có thể thử lại

Những thay đổi xảy ra với terminal dựa trên VTE

  • VTE là thư viện Virtual TErminal làm nền cho nhiều trình giả lập terminal của GNOME
  • Trong chu kỳ GNOME 46, VTE nhận được nhiều cải tiến hiệu năng, và độ trễ nhập liệu mà người dùng thực sự cảm nhận là mục tiêu kiểm chứng chính

Cách đo độ trễ nhập liệu

  • Độ trễ nhập liệu là khoảng thời gian từ lúc nhấn một phím trên bàn phím đến lúc màu pixel trên màn hình thay đổi
    • Độ trễ càng thấp thì ứng dụng càng cho cảm giác phản hồi tức thì hơn
    • Khi so sánh luân phiên giữa độ trễ thấp và cao, khác biệt sẽ dễ nhận ra hơn
  • Việc đo không dùng chụp màn hình bằng phần mềm mà dùng thiết bị kiểm tra độ trễ nhập liệu bằng phần cứng
    • Một cảm biến ánh sáng được nối với bo mạch Teensy, và bo mạch được kết nối với máy tính qua USB
    • Cảm biến nhìn vào một vùng nhỏ trên màn hình, như một ô ký tự cụ thể trong terminal, nơi độ sáng thay đổi khi có nhập liệu
    • Bo mạch gửi một lần nhấn phím như Space, phát hiện thay đổi ánh sáng, rồi dùng phím thứ hai như Backspace để đưa trạng thái về ban đầu
    • Giữa các lần lặp có chèn khoảng chờ ngẫu nhiên để tránh việc phép đo bị khóa theo tần số quét của màn hình
  • Cách này đo độ trễ đầu-cuối bao gồm thời gian phản hồi của kernel, compositor, ứng dụng và màn hình
    • Không bao gồm độ trễ firmware của bàn phím
    • Với bo mạch và firmware hiện tại, hệ thống ghi lại khoảng 35.500 giá trị cảm biến ánh sáng mỗi giây
  • Mỗi bài test được lặp lại 120 lần
    • Phân bố các điểm được kỳ vọng sẽ trải đều khá đồng đều trong khoảng một chu kỳ làm tươi của màn hình
    • Chu kỳ làm tươi của màn hình 144Hz là khoảng 6,94ms, và các điểm trong biểu đồ ví dụ trải trong khoảng 7–8ms
    • Các ngoại lệ cao hoặc phân bố rộng hơn có thể cho thấy độ trễ hoặc xử lý chậm từ ứng dụng được thử nghiệm

Môi trường thử nghiệm và đối tượng so sánh

  • Hệ thống thử nghiệm là laptop Lenovo Legion 7 Gen 7 AMD
    • CPU là Ryzen 7 6800H
    • GPU là Radeon RX 6700M dGPU và chỉ dùng dGPU qua công tắc MUX
    • Màn hình là Acer Nitro XV320QU, 2560×1440, 144Hz, scale 100%
    • Máy chủ chạy Fedora 40 Silverblue Beta, Mesa 24.0.4
    • Compositor là raw Mutter 46.0
  • raw Mutter là môi trường thử nghiệm tối giản chỉ chạy Mutter mà không có GNOME Shell
    • Có thể chạy bằng lệnh như mutter --display-server -- alacritty
    • Đây gần như là điều kiện lý tưởng với rất ít overhead từ GNOME Shell
  • Có bốn terminal được đem ra so sánh
    • Alacritty: không dựa trên VTE, và luôn là terminal nhanh trong các thử nghiệm trước nên được dùng làm mốc
    • Console: terminal GNOME mặc định dựa trên GTK 4
    • VTE Test App: terminal thử nghiệm GTK 4 trong kho mã VTE
    • GNOME Terminal: trong GNOME 46 vẫn là ứng dụng GTK 3 và được cài sẵn trên nhiều bản phân phối
  • Việc so sánh giữa GNOME 45 và GNOME 46 dùng các container Fedora 39 và Fedora 40 toolbox
    • Mỗi terminal được cài đúng gói Fedora và chạy nguyên trạng, không tinh chỉnh thêm
    • Cửa sổ được đặt ở góc trên bên trái màn hình, còn con trỏ chuột được để ngoài cửa sổ để logic phát hiện liên kết không làm sai lệch kết quả

Kết quả với nhập liệu đơn giản và cuộn neovim

  • Bài test đầu tiên chạy cat > /dev/null, sau đó đo thời gian để con trỏ khối dịch sang phải một ô khi nhập Space
    • Đây là tình huống overhead tối thiểu vì không có xử lý bổ sung như readline
    • Alacritty đúng như kỳ vọng gần như không thay đổi khi chuyển từ Fedora 39 sang Fedora 40
    • Các terminal dựa trên VTE cải thiện lớn trong GNOME 46 so với GNOME 45 và đạt mức gần tương đương Alacritty
    • GNOME Terminal dựa trên GTK 3 cũng cho kết quả rất sát
  • Nguyên nhân chính của mức cải thiện lớn này nhiều khả năng là thay đổi trong VTE do Christian Hergert thực hiện
    • Loại bỏ bộ hẹn giờ vẽ lại VTE 40Hz cũ
    • Chuyển sang cách vẽ theo từng khung hình đồng bộ với màn hình như một widget GTK đúng nghĩa
  • Console có một vài ngoại lệ, có thể do việc theo dõi tiến trình
    • Đây không phải hiện tượng mới xuất hiện
    • Vẫn là hạng mục có thể xem xét tiếp trong GNOME 47
  • Bài test thứ hai dùng cấu hình neovim thực tế hơn
    • Mở README của Ptyxis từ một ảnh chụp cấu hình neovim, rồi đổi một phần văn bản thành ký tự Unicode full-block để cảm biến ánh sáng có thể phát hiện
    • Lặp lại Ctrl+D và Ctrl+U để cuộn bộ đệm văn bản xuống rồi lên
    • Terminal phải vẽ các thành phần giao diện như gạch chân, undercurl, biểu tượng gutter, thanh trạng thái...
  • Trong bài test neovim, cải thiện của terminal GNOME 46 cũng rất rõ ràng
    • Các terminal dựa trên VTE của GNOME 46 vẫn gần ngang Alacritty
    • Nếu chỉ nhìn kết quả Fedora 40, bài test neovim làm tăng độ trễ so với bài test cat đơn giản, nhưng mức tăng ở mọi terminal là tương tự nhau

Những khác biệt còn lại mà vtebench cho thấy

  • vtebench là benchmark tự động đo hiệu năng đọc và phân tích PTY, chứ không đo độ trễ nhập liệu
    • Vì không xét tới các yếu tố quan trọng như framerate hay độ trễ, nó không đủ để hiểu toàn bộ hiệu năng terminal
    • Nó chủ yếu tạo áp lực mạnh lên tốc độ terminal đọc từ PTY
  • Thời gian repaint cũng có thể ảnh hưởng đến kết quả vtebench
    • Điều này đặc biệt đáng kể với các terminal như VTE, nơi logic đọc/phân tích PTY và repaint chạy trên cùng một luồng
  • VTE của GNOME 46 cũng được cải thiện trong vtebench
    • Mức cải thiện đa dạng hơn so với bài test độ trễ nhập liệu
    • Vẫn chưa đạt tới mức của Alacritty, nơi việc đọc và phân tích được thực hiện trên luồng riêng với render
    • Các cải thiện này có vẻ đến từ nhiều tối ưu hóa khác nhau được đưa vào VTE trong chu kỳ GNOME 46
  • Hai benchmark dense_cells và unicode bị loại khỏi biểu đồ kết quả mặc định
    • Đây là hai bài stress test chính của vtebench
    • VTE vẫn cho kết quả dao động lớn ở đó, làm giảm tính dễ đọc của biểu đồ
  • Xét theo các trường hợp thử nghiệm, phần chênh lệch còn lại gần như có thể bỏ qua
    • Một phần khác biệt có thể được giải thích bởi việc VTE phải làm thêm cho accessibility, tính toán thanh cuộn và các tính năng khác
    • accessibility đang bật trong GNOME Terminal, còn hiện tại đang tắt trong các terminal GTK 4
    • Dùng VTE 0.76 sẽ mang lại hiệu năng bao gồm các cải tiến của GNOME 46

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-09
Ý kiến trên Hacker News

  • Nhờ thay đổi này, độ trễ đầu vào trung vị trong cấu hình được thử nghiệm cuối cùng đã thấp hơn Apple //e. Console khoảng 12ms, còn Apple //e năm 1983 là 30ms, tức là mất 41 năm
    https://www.extremetech.com/computing/261148-modern-computer...
    https://danluu.com/input-lag/
    Tuy nhiên benchmark này không dùng GNOME Shell mà dùng trình tổng hợp raw Mutter 46.0, và raw mutter là một môi trường rất cơ bản, gần như để thử nghiệm. Ngoài ra nó cũng không tính độ trễ bàn phím, nên không phải phép đo đầu-cuối. Trong thử nghiệm này, bo mạch gửi phím nhấn qua USB, mà riêng độ trễ bên trong bàn phím cũng có thể lên tới 60ms
    https://danluu.com/keyboard-latency/
    Tôi tò mò các con số đầu-cuối thực tế của cấu hình mặc định thật sự quan trọng sẽ như thế nào; giá mà bài viết đo luôn phần đó. Công việc của nhóm GNOME và tác giả benchmark rất tuyệt, nhưng câu hỏi quan trọng vẫn còn đó. Apple //e dùng tăng tốc phần cứng và cũng không xử lý Unicode nên có nhiều khác biệt, nhưng dù sao vẫn mong có thể quay lại mức phản hồi “đúng chất con người” của một cỗ máy hơn 41 năm tuổi

    • Ngược lại, tôi thấy tác giả loại trừ độ trễ bàn phím là đúng. Mỗi người dùng bàn phím, giao tiếp USB, máy tính, phiên bản hệ điều hành khác nhau, thậm chí còn có thể qua hub hoặc KVM
      Nếu độ trễ của các thành phần đó dao động mạnh trong lúc thử nghiệm, sẽ khó phân tích phần cốt lõi của bài này là cải thiện độ trễ VTE. Ngay cả khi chúng hoàn toàn cố định, chúng cũng chỉ được cộng vào giá trị tuyệt đối như một hằng số, nên kết luận không đổi. Vì vậy không nên biểu diễn chênh lệch độ trễ bằng phần trăm. Trong tập mẫu có một hằng số có thể chuẩn hóa, nhưng trong toàn bộ tập người dùng lại có nhiều hằng số không thể chuẩn hóa. Phần Mutter khá thú vị; vì GNOME chạy trên Mutter nên khả năng mức cải thiện độ trễ tuyệt đối cũng sẽ tương tự. Tuy nhiên GNOME cũng có thể tạo ra dao động không mong muốn giống như độ trễ bàn phím, nên tôi muốn thấy đo thực tế
    • Vậy thì cứ dùng Apple 2e và từ bỏ các tiện ích của hệ điều hành hiện đại là được. Cách này giống như chê bai dài dòng các lập trình viên mã nguồn mở đang cố cung cấp miễn phí, nên khó chấp nhận
    • Trong phương pháp của bài viết được liên kết về độ trễ bàn phím, việc tính cả thời gian phím di chuyển vật lý luôn khiến tôi hơi khó chịu
    • Xử lý Unicode không phải vấn đề khó như mọi người vẫn tin. Có một số trường hợp biên trở nên kỳ lạ, nhưng không nhiều và cũng dễ giải quyết
      Điều thật sự làm tôi khó chịu trong bài này là trước phiên bản thử nghiệm mới nhất, tốc độ vẽ lại của Gnome bị cố định ở 40Hz. Rốt cuộc ai đã quyết định như vậy
    • Tuyên bố 60ms trong bài về độ trễ bàn phím đáng nghi. Nếu độ trễ từ nhấn phím tới USB thường là 60ms trên bàn phím thì game nhịp điệu đúng nghĩa là không thể chơi được. Nhưng tôi chưa từng gặp vấn đề đó với bất kỳ bàn phím nào đã dùng

  • Tốt. Tôi thích việc các nhà phát triển VTE tập trung vào hiệu năng, và quy trình đo dựa trên phần cứng trong bài cũng rất ấn tượng
    Cách dùng cảm biến quang để đo độ trễ làm tôi nhớ tới sản phẩm có cái tên khá lộ liễu của Ben Heck, “Xbox One Controller Monitor” [1]. Đây là sản phẩm đọc trực tiếp trạng thái nút của tay cầm console và kết hợp với cảm biến quang để giúp nhà phát triển game giữ độ trễ ở mức thấp. Trông rất hay, nhưng giá 900 đô la
    [1]: https://www.benheck.com/xbox1monitor/

    • Việc bắt đầu tập trung vào hiệu năng là chuyện gần đây. VTE vốn khá chậm
    • Sự thật thú vị: nếu bật đồng bộ dọc, độ trễ sẽ thay đổi tùy bạn đặt cảm biến ở đâu

  • Cả bài này lẫn bài được liên kết đều đặt cảm biến quang khoảng giữa màn hình. Việc đó không sao cho so sánh số đo, nhưng với khá nhiều màn hình thông thường, ở 60Hz nếu đặt cảm biến ở phía trên màn hình thì sẽ đo nhanh hơn khoảng 8ms, còn đặt ở phía dưới thì chậm hơn khoảng 8ms. Lý do là pixel hoặc dòng được điều khiển từ trên xuống dưới, về cơ bản giống CRT
    Vì vậy nếu đi vào chi tiết, cũng nên nhắc tới điểm này, giống như việc đặt ngưỡng nào cho tín hiệu cảm biến quang để kết luận pixel đã sáng. Nhìn các con số trong bài thì 8ms là khác biệt khá lớn. Tương tự, chỉ nói “màn hình X chậm hơn màn hình Y 30ms” cũng có thể là phóng đại. Nên hiểu là trong cấu hình và thiết lập X, Y, Z của tôi thì đo được như vậy. Cũng cần kiểm tra xem màn hình có áp dụng các tính năng cải thiện kỳ quặc chỉ thêm độ trễ mà không có hiệu quả cảm nhận được không, và khi đổi màn hình, card đồ họa hay driver có “tử tế” tự ý chuyển sang cấu hình hiệu chỉnh, scaling hoặc profile cải thiện nào đó không. Những thiết bị này thường không cảnh báo gì, và tôi đã thấy vài trường hợp thực tế như vậy

    • Nếu nhìn màn hình đang cuộn theo thời gian thực, tôi nhiều khả năng sẽ nhìn vào 1/3 phía dưới của màn hình

  • Thật buồn cười khi chúng ta sống trong một thế giới có thể render các trò chơi và cảnh 3D siêu thực từng tưởng như không thể trên phần cứng tiêu dùng, nhưng đồng thời vẫn đang cố làm cho việc in văn bản ra terminal trở nên hoàn hảo

    • Tôi đoán một phần là do tối ưu nhiều hơn cho đồ họa. Có sự đánh đổi giữa hai bên, và đồ họa càng tốt thì văn bản có xu hướng càng tệ hơn. Terminal dùng tăng tốc GPU sẽ bù lại phần nào, nhưng vẫn phải trả chi phí cho pipeline đồ họa đó
    • Có lẽ trước đây nó cũng không quá quan trọng. Chỉ cần “chạy được” là đủ, và cho tới gần đây, trong nhiều trường hợp dùng terminal, độ trễ mạng cần xử lý còn lớn hơn

  • Không liên quan đến tốc độ, nhưng tôi tò mò liệu trên Linux có terminal nào giống Mac OSX Terminal, khi đóng rồi mở lại thì khôi phục tất cả tab, lịch sử lệnh của từng tab và scrollback hay không. Phía Mac xử lý bằng cách đặt file lịch sử bash khác nhau cho từng tab
    Với mục đích này, tôi thích terminal GUI hơn

    • Hơi lạc đề một chút, nhưng mới 1 giờ trước tôi vừa biết iterm2 trên Mac có thể tích hợp với tmux. Nếu chạy tmux với tham số -CC, phiên tmux sẽ được ánh xạ vào các cửa sổ GUI và tab của iterm2; ngay cả khi dùng tmux trên máy từ xa qua ssh cũng được
      Tôi lúc nào cũng quên phím tắt điều khiển và lệnh của tmux, nên khá kỳ vọng vào tính năng này
      [1] https://iterm2.com/documentation-tmux-integration.html
    • Tôi tò mò nếu đóng tất cả tab rồi mở tab mới thì chuyện gì xảy ra. Liệu lịch sử theo từng tab có được gộp lại vào file lịch sử thông thường khi đóng, để tab mới cũng dùng được các lệnh đó không
    • Tôi dùng Tmux. Vì là một multiplexer không phụ thuộc vào terminal, nó đem lại khả năng duy trì phiên và tự động hóa rất mạnh
      https://github.com/tmux/tmux/wiki
    • Nếu thích terminal GUI thì có thể không hợp ý, nhưng có thể hữu ích với ai đó: https://github.com/tmux-plugins/tmux-resurrect
      Tất nhiên tmux có thể dùng cùng bất kỳ trình giả lập terminal GUI nào bạn muốn
    • Tôi cũng đang tìm đúng thứ như vậy. Hiện giờ tôi dùng tmux và tmux-ressurect để giữ trạng thái giữa các lần khởi động lại; nó hoạt động tạm được, nhưng chỉ là một mẹo hay và vẫn có cảm giác như một bản hack
      Thật tiếc là ngoài warp ra gần như không có giải pháp thực sự nào cho vấn đề này. Giấc mơ UX nho nhỏ của tôi là tính năng lưu không gian làm việc như vậy được tích hợp trên toàn hệ điều hành và các ứng dụng bên trong nó. Nếu được thế thì sẽ rất tuyệt

  • Tôi đã dùng Gnome vài năm rồi chuyển sang sway và alacritty 2 năm trước, nhưng thành thật mà nói tôi chẳng nhận ra khác biệt gì. Có lẽ tai và mắt tôi chưa được tinh chỉnh để phân biệt sự khác nhau đó, giống như với thiết bị âm thanh cao cấp

    • Đã từng thử quay lại chưa? Thường thì dễ cảm nhận khi độ trễ tăng lên hơn là khi nó giảm xuống
    • Tôi đã dùng Gnome vài năm và hiện là Gnome 46, nhưng không cảm nhận được khác biệt về độ trễ terminal so với Gnome 45. Có vẻ tôi cũng thuộc kiểu không nhạy với mấy thứ này
    • Có thể không phải so sánh công bằng, nhưng khoảng 20 năm trước, khi đang biên dịch kernel, gnome-terminal dùng một nửa CPU, nên từ đó tôi quyết định không dùng nữa. Xterm chỉ dùng khoảng 2%
    • Về độ trễ hay độ phản hồi, điều duy nhất tôi quan tâm là khi cuộn trong vim thì terminal có làm tôi thấy buồn nôn hay không
    • Có thể màn hình hoặc bàn phím đã thêm đủ độ trễ rồi, nên dùng phần mềm nào cũng không cho kết quả tốt. Khác biệt giữa độ trễ tệ và rất tệ không rõ ràng đến vậy. Tôi tò mò bạn đã thử phần cứng gaming chưa

  • Cuối cùng cũng có benchmark terminal không chỉ là cat một file khổng lồ. Tôi muốn thấy thêm nhiều terminal khác trong cùng bài test, đặc biệt là cả console mặc định của Linux

  • Hơi lạc đề, nhưng điều tôi ghét nhất ở Gnome Terminal là mặc định nó mở một cửa sổ nhỏ. Kích thước chỉ khoảng 1/4 màn hình của tôi, và dù có đổi kích thước thì sau khi khởi động lại cũng không nhớ. Cuối cùng phải vào phần thiết lập và tự chỉ định số cột và số hàng

    • Hành vi đó khá phổ biến ở nhiều terminal. Chỉ nghĩ ngay ra thôi thì cả macOS Terminal mặc định lẫn Windows Terminal đều phải đổi kích thước mặc định trong phần thiết lập
      Cá nhân tôi thích giữ kích thước mặc định, rồi chỉ resize những cửa sổ cụ thể cần không gian lớn hơn. Dù vậy, ít nhất cũng nên có tùy chọn ghi nhớ kích thước sau khi resize
    • Có thể đổi trong phần thiết lập
      Vào menu hamburger > Preferences > tên profile là được. Profile của tôi chỉ là “Unnamed”. Đổi “initial terminal size” là sẽ được như ý. Tôi đặt là 132x43
    • Tôi thường mở nhiều terminal với kích thước khác nhau. Không rõ nên nhớ kích thước nào mới đúng
      Vì vậy tôi mong họ đừng cố làm chuyện đó. Khi phần mềm có thể chắc chắn tôi muốn gì thì tỏ ra thông minh cũng ổn, nhưng nếu không thì lại thành một trường hợp “Tôi đã tự động phá hỏng giúp bạn rồi. Biết ơn chứ?” nữa
    • Terminal gnome mới hơn là Console có ghi nhớ kích thước cửa sổ
    • Theo tôi nhớ thì đây là một tính năng bắt nguồn từ CMD.EXE

  • Khi được công khai, tôi mong terminal Ghostty của Mitchell Hashimoto cũng được đưa vào benchmark. Hiện nó vẫn đang trong giai đoạn phát triển và hoàn thiện, và là beta riêng tư
    https://mitchellh.com/ghostty

  • Tôi dùng xterm và i3wn trên debian và chưa từng trải nghiệm thứ gì nhanh hơn. Tôi chưa bao giờ nghĩ đến việc lãng phí GPU cho terminal, nên cá nhân tôi thấy alacritty là hơi quá mức

    • Tôi cũng cảm thấy tương tự. Khi dùng xterm, tôi chưa từng nghĩ về độ trễ. Ngay cả khi hằng ngày dùng các tính năng nặng như dịch hay sixel cũng vậy. Có vẻ mọi người bỏ qua nó vì phong cách widget Athena, nhưng thực tế nó rất tuyệt