I don't understand why terminals aren't implemented like game engines. (rant)

Posted by funbike@reddit | linux | View on Reddit | 62 comments

I don't understand why the raw speed of terminals is so important. I'm currently using Alacritty terminal and I chose that because of its raw speed due to its use of GPU. But I don't really understand why that's necessary. I don't understand why these terminals aren't implemented like a game engine. In most game engines, the screen is updated asynchronously with the gameplay. So, generally, the game plays the same way no matter how fast your graphics pipeline is. The only difference between faster and slower hardware is the frame rate is.

Terminals can be implemented the same way. The text framebuffer could be read asynchronously to update the graphics framebuffer. But it seems like these terminals are implemented so that those are synchronous. When a program outputs something through its standard output, it is drawn immediately. It seems to me that if this was decoupled, you would have insanely fast terminals. And the only reason why you might want a terminal that uses the GPU is your brain is so fast you can keep up with 100+ frames per second of text scrolling by.

I'd really love it if Tmux implemented something like this, as it is the biggest bottleneck on my setup. Decouple its internal text framebuffer with the ouptput terminal app.

This is really a rant of sorts as there's no easy way to solve this other than someone implementing a new terminal or re-implementing a terminal's graphics pipeline. I just wanted to get it out.

[-]

eftepede@reddit

What exactly you gain when your terminal is 'fast'? For me all of them are fast enough. I want to see the text comming, that's all. I don't need the speed of light for that.

[-]

thinking_pineapple@reddit

It matters when you are handling a large amount of text data passing by in real time, like with logs. The delay can be quite noticeable and you have to use less obvious means.

Terminals don't change or update very often, so this seems like an improvement that should've been worked into them by now.

[-]

xiongchiamiov@reddit

But why would you want that? You can't read all of it. I usually pipe those sorts of commands into a file that I can actually read later, or pipe it through grep or similar to narrow it down to a useful amount.

[-]

ropid@reddit

I think terminals are already doing this, the graphics are decoupled. I tried experimenting a bit here and while there are delays, I think the graphics rendering is not tied to the scrollback text buffer content updates. I did experiments like time seq 1000000 and it's done in 0.1 sec or so. The terminal surely didn't repaint the window 1 million times in those 0.1 sec. That would have been 10 million fps graphics which I guess is unrealistic.

I then got the idea to test one of those terminals that use OpenGL for rendering and could get an fps overlay going with a command line like this:

mangohud --dlsym kitty

That kitty terminal seems to repaint its window limited at the monitor's refresh rate while going through a lot more text lines than that. It needs just 0.2 sec for those one million lines of the time seq 1000000 output.

[-]

ImClearlyDeadInside@reddit

OP is secretly Sonic the Hedgehog.

[-]

ads1031@reddit

I've had a similar idea before. I once noticed that, when taring up a large number of small files with the verbose flag on, the transfer speed was far lower than with the verbose flag off, which makes it seem like printing the file paths to the terminal is both synchronous and slow. I, too, sat there for a moment, wondering why writes to the terminal couldn't be asynchronous.

[-]

pfmiller0@reddit

Part of the reason is probably because a terminal is for displaying text to a user. If the text scrolls off the screen before ever being displayed then it's not really accomplishing that job.

[-]

ads1031@reddit

Ya know what, that makes a ton of sense. It especially makes sense in the context of old-fashioned teletype terminals, where there's a ton of latency per-character since you're waiting on mechanical motion to generate each character. Even at 115200 baud, the CPU is still orders of magnitude faster than the terminal.

With that being said, I do occasionally find myself in situations where, I don't care that the text is entirely readable - I care that it is perhaps only partially readable, but present. If the text is blasting past, and I can tell that my tar or my xz is still running, I'm happy. So I do wish that, as a user, I had the option to make some writes to the standard output asynchronous.

[-]

mina86ng@reddit

Use pv and you’ll get full blown progress bar.

[-]

pfmiller0@reddit

I always forget about pv!

[-]

ads1031@reddit

When possible, I do! I love pv! Unfortunately, there are times when a system I'm working on doesn't have pv available. But that's just the way the cookie crumbles, ya know?

[-]

funbike@reddit (OP)

Thanks for a possitive reply. A long time ago I wrote a web app that took heavy load. We were able to double performance by making log writes asychronous. LOL, that was fun.

Btw you can pipe stdout to mbuffer to get the async output you wanted:

rsync ... 2>&1 | mbuffer -m 16M

[-]

xiongchiamiov@reddit

I don't understand why the raw speed of terminals is so important.

It isn't. I use whatever terminal emulator is handy, and not once in several decades have I thought about it being something needing performance optimization.

[-]

djao@reddit

At the very least, you need to avoid unoptimizations such as quadratic time algorithms for inserting characters at the beginning of a long input line, which many old terminal emulators suffered from.

[-]

mina86ng@reddit

Even then, a computer can move 100 bytes faster than I can type a character.

[-]

djao@reddit

I've had single command lines with 100000 characters before. In this case it really matters that your character insertion algorithm is not quadratic in time complexity.

[-]

mina86ng@reddit

In that case you should be running fc.

[-]

djao@reddit

Also, fc does not entirely solve the problem in all cases. You still have the problem that editing a long line in a text editor can take a long time if the terminal is deliberately unoptimized for character insertion at the beginning of a long line. A large screen with a maximized terminal window can easily display 20000 or more characters on the screen at once in a single line, long enough that quadratic time algorithms are very painful.

[-]

djao@reddit

Yes, there's other ways to do it. You don't even really need fc, you can just open up a text editor and create a shell script and write it to disk. If your philosophy is that there should only be one way to do everything and that everyone must use the one approved way, then there would be no need for heavy terminal optimization.

But if you think that users should be provided with multiple options to do what they want, then it is worthwhile to make the terminal a viable option.

[-]

mina86ng@reddit

My philosophy is that it’s questionable whether one in a million occurance is worth optimising for. Especially if better solutions to the problem already exist.

[-]

djao@reddit

At the end of the day it's not that hard to avoid quadratic time algorithms. We're not talking about spending months of effort to eke out a small gain. It's just a matter of being mindful to avoid the worst options. I think this amount of effort is worth it.

[-]

NotPrepared2@reddit

I had to use my roommate's 300 baud modem to connect to the campus mainframe for a whole summer, 40 years ago. That terminal was pretty slow. But since then it's all good.

[-]

TetrisMcKenna@reddit

In most game engines, the screen is updated asynchronously with the gameplay. So, generally, the game plays the same way no matter how fast your graphics pipeline is.

That's actually not how it works, the gameplay code is typically synchronous with the framerate. Up until recently most games were single core, even. Things move consistently across the screen at different frame rates because the delta value (the time between frames) is used as a multiplier for the change in position, not because the positioning code is running async to the framerate.

[-]

bvgross@reddit

I think this is less and less the case. At least for things like physics, because it causes a lot of crazy things when they are coupled.

[-]

TetrisMcKenna@reddit

Physics callbacks running at a fixed rate in the game loop is still synchronous generally, though it's true physics engines are more threaded these days. Physics callbacks usually run at a fixed rate at the expense of frame rate, which is definitively synchronous - if the physics ticks can't run at the set rate (eg 60hz) the frame rate will drop to give the physics engine more time to hit its fixed rate.

[-]

bvgross@reddit

Thanks for the technical explanation.

That's what I tried to say, that physics "run at a fixed rate at expense of frame rate" (So, not coupled to it). It's synchronous to it's process but not dependent on the frame rate, as you explained.

In the past we had physics simulations being dependent on frame rate as each frame was a tick for the physics engine to calculate. A slow framerate would give you different results than faster ones.

[-]

TetrisMcKenna@reddit

Oh, yeah that's true, though even back in the day that was considered bad practice! Kind of a separate issue in that both methods are not technically async to the rendering loop, as in OPs complaint. But it was always fun to see those games completely break on newer systems as PCs got faster so quickly :)

[-]

ViktorLudorum@reddit

A long, long time ago, I wound up using some proprietary tools through the command line that were mildly to incredibly hostile to automation. (Chip design software before they switched to a TCL based language.) I spent forever trying to beat some intelligence into it, until I tried something from my undergrad days: a MUD client.

In addition to asynchronous UI updates, it had sophisticated macros, a trigger system, and a scripting language superior to the nasty mess of the million-dollar tool. It also had rule-based highlighting to let me know when scrolling through megabytes of timing files what should be addressed. I miss it.

[-]

funbike@reddit (OP)

I'm going to delete my post in a few minutes. I'm not sure why better performance isn't considered desireable, even when performance is already good enough. But I don't want to annoy people in this sub with my idea.

[-]

Jordan51104@reddit

performance being good enough is exactly why better performance isnt really a thing people consider. what would you gain by it being "faster"?

[-]

funbike@reddit (OP)

The same question could be posed to the authors of Alacritty and Kitty, both of which use the GPU. Why not just used CPU terminals, which could be considered fast enough.

[-]

NonStandardUser@reddit

Except that simply rendering things faster may be less risky and take less effort than making the terminal emulation backend asynchronous and possibly breaking many print() interfaces?

[-]

funbike@reddit (OP)

The text framebuffer would still be synchronous with stdout/tty, so it would not break anything like print(). The asynchronous-ness is just how it visually renders.

The biggest downside is some dropped frames when you are outputing a ton of text, such as cat 1G-file.txt.

[-]

Cercle@reddit

Why delete it instead of providing the specific use cases that people are asking for?

Other comments state that: you can only read so fast, you need to be able to cancel a process gone awry as soon as you notice it, you can't lose data, you have to be able to scroll back.

Terminals are also quite a bit more complex than they appear, and a lot of optimization work has gone into them for decades.

What you are suggesting is raising alarms for people because it appears to be a very complicated solution to make things less safe, for... What ? What would you do with it that you can't now ?

[-]

funbike@reddit (OP)

Good points, but I come here for enjoyment. There's too much negativivity already coming my way to have a good experience if I continued. Maybe I'll repost the idea in a better way in a few weeks. I'll use better examples and explain it better.

Terminals are also quite a bit more complex than they appear, and a lot of optimization work has gone into them for decades.

Perhaps, but most terminals already have a separate text framebuffer and graphics framebuffer. What I suggest shouldn't introduce excessive new complexity.

Thanks for the advice.

[-]

NonStandardUser@reddit

You clearly stated that this is a rant. That means you are unhappy with the current state of things. Commenters simply explained: a) why things are that way, and b) what the reason/use-case is for your idea.

Nobody called you names or behaved in a derogatory manner. As for the downvotes, that's just the reddit system for expressing disagreement(in cases of civil discussions, which this currently is). I don't see any 'negativity', just a lot of people that want you to listen and accept their explanations.

[-]

funbike@reddit (OP)

You clearly stated that this is a rant.

Sorry, that was my mistake. This was just an idea to make something better. I mistakenly said it was a rant because of my surprise that it's not commonly done.

[-]

funbike@reddit (OP)

A big mistake I made is framing this as if there is a problem. I put a negative spin on it. I should have put a positive spin, such as "Code idea to make any terminal massively faster"

[-]

NonStandardUser@reddit

Yes, like "Async stdout for faster terminals: what do you think?"

People are simply reacting to the part where you wrote '(rant)'.

[-]

funbike@reddit (OP)

Thanks. I'll let you know when I re-post.

[-]

eftepede@reddit

Why delete? You've triggered an interesting discussion. Don't hide it just because others think you're wrong, it's cowardice.

[-]

NonStandardUser@reddit

You said it yourself - it's already good enough. If more performance is desired, only then people will look into it.

Are you an overclocker by any chance? The people that spend hours and days dialing in the voltages and frequency of processors to get 1 more point in a benchmarking tool. As you currently put it, you sound like that. Sure, they're not evil or bad, they actually contribute to the advancement of hardware technology! But are most users overclockers? No. Most people will go for 'good enough' and 'whatever that is conventional'.

"Not sure why better performance isn't considered desireable" : the answer to that is 'diminishing returns' and 'no need for that'. If performance is served free on a silver platter, who would say no? But in this case, someone needs to work on it; it's just that nobody thinks it's necessary.

[-]

ropid@reddit

I'm not sure programs aren't already doing this. I tried using kitty for testing because it's using OpenGL for rendering and I could then get an fps overlay going with MangoHud with a command line like this:

mangohud --dlsym kitty

When I print a lot of lines of text on screen, the window gets repainted vsync limited to my monitor's refresh rate, so at 144fps with my 144Hz screen. The text output in the terminal is much faster than that. For example, if I run this here:

seq 144000

It's not taking 1000 seconds at 144fps to print, it's instead done instantly. I see this kind of performance here:

$ time seq 144000
...
143997
143998
143999
144000

real    0m0.034s
user    0m0.002s
sys 0m0.032s

[-]

daemonpenguin@reddit

You might want to spend some time considering why this could be a bad idea. Having a terminal where I/O is not synchronis has some obvious issues that would need to be worked around.

as it is the biggest bottleneck on my setup

You might also question whether there is a better way to do what you are doing if you need I/O on a terminal so fast that current GPU acceleration isn't enough. How could you possibly be putting that much I/O through a terminal on a regular basis that it's a bottleneck for your processes? Do you need a faster terminal, or just better processes?

[-]

funbike@reddit (OP)

I didn't go into that kind of architecture/algorithm detail as I thought it was obvious a good developer wouldn't make a native mistate like that.

You'd do synchronous updates for small amounts of output and asynchronous updates for large amounts of output. 2D games engines have solved this kind of problem decades ago, back when CPUs were slower and there were no GPU.

You might also question whether there is a better way to do what you are doing if you need I/O on a terminal so fast that current GPU acceleration isn't enough. How could you possibly be putting that much I/O through a terminal on a regular basis that it's a bottleneck for your processes? Do you need a faster terminal, or just better processes?

To be clear, I am happy with my setup. I didn't say I wasn't. I don't have I/O issues. But like anyone else, I would be happier if ALL my apps were faster, but that doesn't mean I'm unhappy with current performance of any of them, necessarily.

Next time I'll be more precise to avoid this kind of reply. My posts will be 3 times longer, but maybe it will cut down on misunderstanding.

[-]

mina86ng@reddit

But like anyone else, I would be happier if ALL my apps were faster, but that doesn't mean I'm unhappy with current performance of any of them, necessarily.

The thing is, 99.99% of things you’re doing on your computer will not be faster with terminal which uses asynchronous display pipeline. And those that would be can be addressed by redirecting output to a log file or use of stdbuf.

[-]

NonStandardUser@reddit

Define 'small' and 'big' amounts.
Also, anything that print()s on the output expects the behavior; if you want asynchronous output, why not implement a separate output thread for that specific program, or better yet, defer the stdout print?

[-]

KamiIsHate0@reddit

Yea you could do that, but why? People like to read what is happening in terminal and most of times it's already too fast to keep up with it. Also, there no human-machine process that would benefit from this asynchronous speed. Anything that can use this blazing fast speed already do it in background without human need to input/followup.

[-]

martinus@reddit

Actually many terminals you that, e.g. gnome-terminal or konsole

[-]

keremimo@reddit

It is thanks to the syncronous nature of terminals that someone noticed there was something fishy going on with XZ library this year, leading to one of the biggest backdoor busts of recent. I wouldn't have it any other way.

[-]

NonStandardUser@reddit

good point

[-]

BranchLatter4294@reddit

What is the actual use case for all this development work?

[-]

RusselsTeap0t@reddit

Terminals are designed for real time, immediate feedback and precise control. The synchronous nature of terminal output is a feature, not a bug. It ensures that what you see is exactly what's happening, without any delay or buffering.

Game engines, are designed for rendering complex visual scenes where some latency is acceptable and often unnoticeable (depends).

Decoupling the text buffer from the graphics buffer seems like it would increase speed. It could actually introduce latency and inconsistencies in certain scenarios.

Implementing a game engine-like approach for terminals would increase resource usage. Terminals are used in resource-constrained environments. Efficiency is vital.

Modern terminals already implement various optimizations, such as damage-based rendering, to minimize unnecessary redraws and improve performance.

Terminals must be as simple as they can get. It's a fundamental part of a machine, especially on Linux computers, servers, cloud systems, and embedded devices. The possibility of a problem should be as minimal as possible; as well as the attack surface.

I use Foot terminal on Wayland. It doesn't even use GPU and in my tests; it's faster, lighter than Alacritty, Kitty and Wezterm. It has more straightforward usage and configuration. It uses 10mb ram while Wezterm can go up to 250mb easily in a single window.

[-]

tinycrazyfish@reddit

There is actually a terminal doing something like what you suggest and it doesn't use the GPU. It's mosh https://mosh.org/. But it's purpose is not raw speed, it's purpose is to have a more "usable" shell over unreliant, intermittent, high latency network connection, and that also plays well with roaming.

But one thing you have to understand. While gaming is perfectly tolerant to loss of frames. A terminal can visually skip frames, but loss of output is not acceptable.

[-]

Cercle@reddit

Mosh > typical ssh any day of the week

[-]

sharptoothy@reddit

Have you heard of Casey Muratori's "refterm?"

https://github.com/cmuratori/refterm

It sounds similar to what you're describing.

[-]

djao@reddit

Games don't need scroll back for the video feed. Terminals need scroll back for the output. End of answer.

[-]

Dizrak_@reddit

As far as I am concerned there is simply no task that would require this. If it ain't broken, do try fo fix it

[-]

necrophcodr@reddit

I can't even keep up with urxvt displaying my listing of dmesg, so for me personally there's absolutely no point to this. What situation would you want a lot of scrolling information to perceive, rather than just so what you gotta do and output one final readable result?

[-]