Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A completely unoptimized terminal renderer that runs at several thousand FPS

twitter.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#11

Post by miltondts »

eska wrote: post #6

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#12

Post by CuriousCosmic »

bloniac wrote: post #9
DixieDev wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#13

Post by AnIdiotOnTheNet »

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#14

Post by eska »

miltondts wrote: post #11
eska wrote: post #6

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…

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#15

Post by Narishma »

CuriousCosmic wrote: post #12
bloniac wrote: post #9

Earlier quoted context omitted.

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.

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 milliseco…

> 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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#16

Post by andruc »

miltondts wrote: post #10
bloniac wrote: post #9

Earlier quoted context omitted.

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#17

Post by craftinator »

bloniac wrote: post #9
DixieDev wrote: post #8

Earlier quoted context omitted.

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.

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#18

Post by alpaca128 »

andruc wrote: post #16
miltondts wrote: post #10

Earlier quoted context omitted.

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#19

Post by temp22334455 »

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.

Re: A completely unoptimized terminal renderer that runs at several thousand FPS

#20

Post by eska »

temp22334455 wrote: post #19

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 produc…

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
Post reply on HN