A completely unoptimized terminal renderer that runs at several thousand FPS | Hacker News Reader

A completely unoptimized terminal renderer that runs at several thousand FPS

twitter.com

85 pointscrummy20 comments

I really understand Casey's anger here after using software that gets slower and slower every year even while hardware has become ludicrously fast. Our industry is a pile of bad excuses for why everything has to suck made by developers who are more concerned with fashion than making shit that's actually any good.

Link to the mentioned Github issue:

https://github.com/microsoft/terminal/issues/10362

I think there's stuff for a PhD in there. Just not in CS.

This summarizes corporate programming in a nutshell and why I think that almost no programming done nowadays can be considered engineering in practice. I’ve become a pessimist about this industry long ago. We ought to wear blue collars soon.

If you press them hard enough they'll start spouting stuff like:

- "We engineer for maintainability/extensibility/scalability!"

Except that unlike with performance, they generally don't have any numbers to back their assertions. I know it is much more difficult to measure, but their confidence would have you believe that what they are saying is a well established fact. When I point this out, the responses turn to "I read it in some book. It looks cleaner!". Very hard to turn those discussions into anything productive due to the lack of metrics.

That stings so bad. I’ve had this exact same experience of pressing somebody for proof, some measurement, a paper, some post mortem, anything. And I literally got the response “I read that in some book by some author in some chapter on some page I don’t remember”. I just told the CTO “sorry, but what do you expect me to do with this?”.

In some company where we offered a web API I couldn’t get the cto to publish statistics about endpoint usage. I became great friends with one of the ops, who I passed an awk script to run on all the web servers’ access files. Turned out that most of the supposedly critical endpoints with tight deadlines were used almost never. But for some reason people REALLY don’t like measuring.

By now I’m in charge of a software team, and I instill into everyone that programming should be engineering work, and emotional judgements are unprofessional and signs of a bad programmer.

The linked YT video was posted yesterday, in case anyone wants to check for the (limited amount) of previous discussion:

https://news.ycombinator.com/item?id=27725133

This: “We need less excuses and more of this. It's ridiculous the kind of things we tell ourselves and each other can't be done.”

I think it’s a little myopic to critique software engineering for a lack of focus on performance. Software engineers generally work on products, and performance is only one facet of a product. Just enough time is spent on performance until it is good enough. Any extra time spent on performance detracts from making other facets reach the “good enough” point. Sure, you can make a focus on performance part of the product (e.g. the fastest terminal), but the general product equation still applies.

This is addressed quite in the beginning of the video. This is much less code, MUCH less code, than what MS is doing. Going for worse perf did not make the code more maintainable. And it’s only good enough because the hardware carries these horrible software development practices on its turbocharged back. Hardware engineers are carrying software artists

I get what you're going for, but as a programmer with a bachelor's degree in arts I can tell you that most artists aren't remotely as wasteful as these developers. If anything they (on average) live an extremely frugal lifestyle due to having much less disposable income.

Maybe the art they produce seems wasteful to you, but at least it's a conscious choice to "waste" the resources that went into it and for which a ton of sacrifices usually had to be made.

Someone that is putting his code where his mouth is, that's great.

What does “thousands of frames per second” even mean when the monitor is displaying in the range of sixty frames per second or if you have a fast one, 144 FPS?

Is it just conceptual frames per second? So for the terminal to be doing 1,000s of frames per second then the graphics card is outputting thousands of frames per second?

I don’t get it. Where are these thousands of FPS?

One frame, in this case, is the time it takes to do a full iteration of its loop containing all the input handling and rendering, up to and including the point where it flips its buffers for the main screen. Enabling v-sync would bring that down to your monitor's refresh rate, as it prevents the buffers from flipping until your monitor is refreshing.

So to be clear, there are no thousands of frames per seconds actually being displayed anywhere. There’s 144 at best.

The internal buffer is being updated thousands of times per second. The user will see their regular 60FPS.

Where exactly is it claimed that it displays thousands of frames per seconds? The purpose is to show how fast the program is. This is standard practice in benchmarks. You show an FPS counter that doesn't correspond to the frames the monitor displays.

It is claimed very clearly in the linked tweet, and the metrics are shown in the video.

No. The linked tweet says it is running at thousands of FPS. Which is correct. It's not the program's problem when the graphics hardware cannot process every single frame.

Referring to FPS as the framerate rendered is the standard, when you talk about e.g. the display's output you use Hz. Every professional esports player runs their game at hundreds of FPS if possible, to minimise latency.

Yep. This is pretty standard terminology in the graphics space. In reality all it really means is that the AET (average execution time) for a single loop is some fraction of a millisecond even for decently heavy loads.

I'm honestly more interested in the actual WCET (worst case execution time) would be however I imagine it's at least decent all things considered.

In the end as long as the WCET is only a few milliseconds (sufficient for up to 240Hz monitors) or at least the AET for most loads is beneath that then anything extra just means more power to throw at anything else.

> In the end as long as the WCET is only a few milliseconds (sufficient for up to 240Hz monitors) or at least the AET for most loads is beneath that then anything extra just means more power to throw at anything else.

It also means a cooler and quieter laptop, and longer lasting if running on battery.

There are thousands of FPS being pushed to the frame buffer, where they could be displayed at that rate with the right hardware (Although I'm not sure there are display technologies that could update that quickly...). Another way of looking at it is that the FPS rate is now display hardware bound, rather than software bound.

Reply on news.ycombinator.com