Refterm v2 - Resource usage, binary splat, glyph sizing, and more

ecosystem control via code churn?

V2 was a refutation of the people claiming that there secretly was a good technical reason for the slowdown, the "excuse parade".

Well let's keep on making excuses then, so this guy ends up with a full featured but fast terminal!

I have actually cried at compiler messages sometimes.. at least under very emotionally distressing times. That's still really funny though!

Except he was totally willing to accept that it simply was not a priority for the Terminal team. He didn't like that, but could understand it. What set him off was one of the devs claiming that it's basically impossible, while Casey was saying that it's relatively simple.

This is the same attitude that Casey is fighting against and I hope we, as an industry, fight against too. No, you should NOT settle for mediocre, garbage software. You should be professionals - who take pride in their craft and want to achieve the best, especially in cases where it is EASY to do so.

Do you prefer people that are wrong? Because that's the alternative.

Look, I know where you're coming from. A lot of people have made comments about Casey's attitude, and I understand.

But there's a sickness, a rot that goes all the way to the core of programming as a profession. There's this popular notion that optimisation of any kind, no matter how straightforward and quick, is a waste of time because hardware will get faster.

That hasn't been true for a decade, except in the sense that we have more cores now. A single CPU core has only gone up in performance by about 50% during that long period. In the past, that would be the year-on-year speedup.

Hardware has changed and programmers must adapt. Casey is an old soul in the sense that he still has his hair, but he thinks and talks like me, someone who started with computers before you were born. In those days we had to be frugal, and efficient, and smart.

Those days have come again. We can't rely on Moore's law any more for free wins. We have to start thinking like the programmers in the 1990s writing games that ran at 60 fps on hardware with less grunt than the controller in your disk drive.

It's not about perfection. It's about embracing a kind of zen: The simpler solution is not only less work, but also a better fit for the modern machine. That miracle of engineering is a true marvel, a beast of a thing that can absolutely fly if you just let it. If you stop hobbling it with your foolish, outdated notions that weren't even correct "back then". They were never a good idea! In the past we didn't have the capacity to waste, now we don't have the right kind of machine for those approaches.

Write code that's linear and straightforward and you too can revel in the unbridled speed that your personal supercomputer can do in a straight line.

IMHO he's taking his personal crusade a bit too far and only sees things his way - the Windows Terminal team now must reach performance perfection, god forbid they want to ship something that is useful for 99% of their user base.

That's a strawman. He never said this. He made the demo because of the excuses made, he made an update because the excuses kept coming. There's nothing wrong with backing your claims with proof and that's what he did. That's so much better than the usual unsubstantiated complaints, I'd love to see more of constructive criticism like this.

I'm not a fan of people like Jonathan Blow, who strike to me as arrogant and very up their own arse, but Casey doesn't seem to be this way. Or at least in this case, I don't follow him elsewhere.

You're right whenever an optimization is either too much work to implement/test, makes too little difference, or both. This is not such a case.

This attitude is what lead to us having an OS that requires 4GB(!!) of RAM and an 8th gen Intel Core just to install it

the Windows Terminal team now must reach performance perfection

I think the point is not for them to reach performance perfection — Casey mentions multiple times that he has not looked at the output of a profiler to optimize the code — but rather to reach reasonable performance.

performance perfection

He literally just wants them to reach a baseline of performance that isn’t a thousand times slower than it should be…

There no optimization involved in what’s going on here.

Stop raising the straw man.

We have idiots on Reddit endless running around parroting bullshit like “runtime immutability actually executes faster because compiler optimizes better because no aliasing” and they’re upvoted for it even though it’s trivially shown to be a complete lie.

Stop cargo culting.

“I have run out of excuses, therefor Casey is an asshole!”

It’d be funny if it weren’t so predictable and sad.

He's indeed a genius and has a lot of knowledge to share, but he has to be right, and things have to be done his way.

That's not true. a) If you find a better way he will 100% listen. 2) On stream, he encourages people not just follow everything he says blindly, but to question it, and go find their own way of programming that they enjoy. 3) He says things like "I like" and "I prefer". Etc...

He's only calling out on things he legitimitly sees as bad engineering and he usually has everything ready to back up his claims. The problem is that other peoples way is usually OOP which is by all messurable metrics objectively bad software engineering.

The thing OOP is good at is that it lets developers think of one object in terms of life-time, functionality, error handling, etc.. Instead of data collection & algorithms - thus giving the illustration of simplicity, at the expense of creating complexity, and poor performing software. The stage of individual object thinking might be easier to wrap your head around, which I think is why OOP has become an industry standard. The problem is that people think individual object thinking is the last stage of programming, and even think it's a good stage for software. It's not, it's a very, very bad stage. It produces terrible, way too complicated software (as this drama beautifully demonstrates).

The Win-Term guys probably are - top of the line OOP developers - yet, they were unable to make good quality simple software.

Casey explains it better - Programming stages of mental development with respect to architecture: Individual Element thinking vs Grouped element thinking.

https://www.youtube.com/watch?v=f4ioc8-lDc0&t=4464s

He has a cruzade against bad code in general, just check it out an old rant of him https://twitter.com/cmuratori/status/1246930755860586496, I agree with him that our apps are just a pile of crap, just because we have more resources it doesn't mean we need to ship apps faster instead of at least optimize them.

It really doesn't matter how many features your terminal emulator has if it can't provide any of them in a reasonable amount of time. When my terminal emulator is slow, I'm going to think twice before running commands in it, I'm going to have to use workarounds to avoid it slowing down the commands I do run. This is my experience with Windows Terminal today, and it's really frustrating.

Performance isn't a nice to have, it's a feature that really affects how you use a product. I'd like to not have to think twice about running commands when I use WE, nothing more.

the Windows Terminal team now must reach performance perfection

His slapped together side project is hundreds of times faster than their product.

Nobody is asking for perfection, the point he makes is that the terminal is much, much slower than it should be.

that may be, but it's hard love.

although i'm a bit worried. he locked down his discord i guess due to invasion by incompetents. and jon blow isn't streaming programming anymore. he likely got demoralized by incompetents in his chat.

we can't lose those two.

Windows terminal is garbage. The thing just slows down the FPS on my ryzen 3800x PC to a crawl. It’s basically useless and I have to switch to the Ubuntu app instead in order to use WSL.

Sounds like he'd be an awful coworker.

This is also the downside of having dev staff directly responding to customers. It cuts red tape and can help the devs work much more closely with users, but occasionally a flippant remark that would be OK in private becomes a firestorm in public. Making a few of these mistakes as a dev makes you appreciate why companies have PR staff and community managers and the restraint they have in responses.

I appreciate the uphill battle that the current Terminal team has, but this was clearly not the right response when there are decades of examples of console I/O being done an order of magnitude faster than in Windows.

Also refterm doesn't have a software renderer as it uses the GPU to build the font texture atlas.

Funny thing is, Windows Terminal also uses GPU rendering. In fact, it's one of their selling points:

The Windows Terminal is a modern, fast, efficient, powerful, and productive terminal application for users of command-line tools and shells like Command Prompt, PowerShell, and WSL. Its main features include multiple tabs, panes, Unicode and UTF-8 character support, a GPU accelerated text rendering engine, and custom themes, styles, and configurations.

Where the hell did the performance go? Are people just so used to how shit

Well, this is why he has made it. Not to attack the cmd in particular, but to prove that we are routinely leaving orders of magnitude of performance on the table. Would you be fine if your car would have 10.000 horses just so that you could use a hundred? Because, we (the developers) are right now.

But that doesn't make sense, SQL Server 2019 runs on Linux. MOST cloud SQL Servers run on Linux. It's not just the OS, it's that the dev teams choose between keeping compatibility and keeping performance - they choose compatibility every time.

Honestly, what Microsoft needs to do is .NET Core all of their projects - say fuck backwords compatibility, deprecate a bunch of corporate cruft, and make a lighter version of their existing projects that everyone can use.

I just tried the Calculator app on my quite old laptop and it "only" takes about 1,100 milliseconds to fully launch. That's not "two seconds", but it's still atrocious. You've got to wonder... what is it even doing that requires a solid 700 milliseconds of processor power and over a second of wall-clock time?

A quick peek reveals that the "calculator" app does all of the following

• Loads or touches 216 distinct files (mostly WinRT DLLs).
• Performs 16,669 registry API calls, including stuff like "FIPS algorithm policy" and "DC locator policy".
• Loads a storage library (for calculator? Storing what!?)
• Loads URL and web-related libraries -- this is for the currency conversion functionality I assume.
• Loads a cryptographic library -- makes sense for HTTPS used above.
• Creates a thread pool -- ditto, this is probably for async HTTP API calls.
• Directly involves the NVIDIA drivers, including at least one slow file write
• Loads "imagehlp.dll", which is an EXE metadata reader library typically used for writing compilers or similar tools.
• Loads "ngcrecovery.dll", which is apparently the Windows Hello Recovery Helper. Wat?
• Wastes 13 milliseconds faffing about writing to some file calld "nvAppTimestamps", which might be an NVIDIA telemetry log or something.
• Loads the "Windows.Energy" DLLs. Wat?
• Loads the Windows CODECs libraries? For video playback support?
• Loads its own custom font.
• And even includes OLE2 because why not. Just in case you want to embed calculator in an Excel spreadsheet or whatever.

Craziness.

Ah see that was your mistake! You used a calculator app to calculate and expected it to be fast. Why can’t you use the intended process of opening start menu and typing in your calculation in search and let cortana give you the result? After all - it’s the fast way! Oh and the calculator is deprecated, have you not read the buried issue we hid somewhere deep in the pile of issues? The splash screen is a performance optimisation. We added it for better UX while we load all the legacy code of every calculator since windows 95 in the background so the user feels “involved” and “important” while they wait for the calculator to load. I am closing your issue as “duplicate” now.

<3 Microsoft Dev Team

—- On a much more serious note: it takes about a second for my start menu to open sometimes. Yet it takes an imperceptible amount of time for Microsoft’s power tools omnibar to pop up so I just use that. It’s almost like they load a bunch of crap on start menu every time you open it. Like they’ve never heard of what a cache is or something. I feel like I’m mining Bitcoin each time I click on start. I hope 11 is faster…

Why do you use windows then? Linux is free

Chrome stays loaded in the background by default btw, after closing all windows. Funnily enough Windows also tries to keep some of its very basic applications in "sleep mode" to start them faster. I never understood why they added this feature but guess I do now.

But yeah that's pretty ridiculous performance on the calculator. Can't say I've noticed it but it has also been a long time since I used Windows 98.

Thanks for responding!

I also think Caseys one fundamental mistake was not simply doing the work first and submitting it as a PoC for the purpose of it carrying his argument. This would have directed the convo all on its own and focused the maintainers.

That's an unreasonable amount of work to expect from someone who's just submitting a bug report. I agree that it definitely would have cleared up some of the misconceptions, though.

Also, did you see his two videos where he shows his implementation? (That’s not a combative remark, just a sincere question)

I have, and I've also skimmed through the source code of v1 and a bit of v2. He actually makes several problematic remarks, indicating he doesn't quite know what he's talking about re: Unicode:

// taken from refterm_example_terminal.c, also in the first video, he makes the same claim about what Uniscribe does
static void ParseWithUniscribe(example_terminal *Terminal, source_buffer_range UTF8Range, cursor_state *Cursor)
{
    /* TODO(casey): This code is absolutely horrible - Uniscribe is basically unusable as an API, because it doesn't support
       a clean state-machine way of feeding things to it.  So I don't even know how you would really use it in a way
       that guaranteed you didn't have buffer-too-small problems.  It's just horrible.
       Plus, it is UTF16, which means we have to do an entire conversion here before we even call it :(
       I would rather get rid of this function altogether and move to something that supports UTF8, because we never
       actually want to have to do this garbage - it's just a giant hack for no reason.  Basically everything in this
       function should be replaced by something that can turn UTF8 into chunks that need to be rasterized together.
       That's all we need here, and it could be done very efficiently with sensible code.
    */
    // ...
}

Either he's massively underestimating the work Uniscribe does or he's seriously suggesting someone write their own text shaper. This kind of "belittling" (sorry for the charged language) isn't really productive to discussion.

He does show how direct write is egregiously slow and a lot of uniscribe stuff is… well it’s not great. I wonder if this could have also been something that would have driven the conversation in the right direction had the work been done in advance and linked to the issue?

What, in particular, do you think would have helped? Work around DW/Uniscribe? That's a pretty drastic step, as then you have to deal with Unicode corner cases.

However from where I was seeing this unfold, it seemed to me like those remarks were made by someone who should have had the training to interact with a user and “dig deeper” before responding the way they did. I dunno… it’s human to misunderstand things, but I feel like if one is unsure about making a response - it would be prudent to clarify before responding. Every time I had a comment war on git stemmed from me not taking the time to really understand the situation and ask the right questions. Speaking from experience. Makes me ask whether the replies came from a heated place or perhaps had some artificial urgency attached to them based on Casey’s terseness.

I agree. Nonetheless, there's a lot of work put into WT's renderer, and I can see why Casey's dismissing of it as "extremely simple" could rub them the wrong way.

Individual websites may be slow, but the building blocks of the web are very fast

As in a lot of websites are coded poorly, but web technology generally is quick.

No, you’re clear. I just just woke up and my brain processed it wrong. Sorry about that!

That’s the cargo cult cult, where a redditor just invokes the magic words “cargo cult” and it automatically constitutes a cogent argument.

They're not. It's a strawman. The issues that Casey points out aren't really results of cargo culting in how you write code. However, several of them (allocating memory in inner loops, not minimizing draw calls, etc.) are common sources of performance issues that subject matter experts would tell you are worth optimizing up front.

You could call it "bad code", but not "cargo culting".

abstraction-based programming is the main culprit here.

By not thinking about what's going on under the hood, you end up wasting the computer's resources. A lot of the time, collapsing abstraction layers not only makes the code faster, it also makes it clearer.

However, this runs counter to the mainstream programming education that focuses on treating computers like abstract machines and treating programming like a mostly mental activity where the computer is just the "current hardware implementation" of some "idealized" computation theory.

In my experience on the internet, there is, and always has been, a subculture to programming of very toxic and elitist people who really like the idea of being the genius programmer in the room, but generally don't actually work in the industries they find worthwhile (games, graphics, systems, etc). Goes along with accusing everyone else of being stupid that actually does work in fields outside what they deem as "cool", like web stuff. These are people that really love talking about programming, and thinking about it, but don't actually do it that much, or at least not professionally.

Not saying that's Casey whatsoever, but this kind of person generally loves people like Casey and Jonathan Blow cause they validate their world view of being the hardcore programmer in the room.

Honestly, Casey is a bit like the old Linus. He is good technically but he can improve a lot on the social skills. In the issue, he is ok but the exposure (mostly rants) on Youtube and Twitter is a bit too much imho. This is especially easy for him in the position he is in. But the poor maintainers have a lot to deal with and no need to go on your high horses with them. I still remember the VSCode issue where a guy tried to use git for the first time (with VSCode) deleted his whole code and then created an issue insulting the developers. The bottom line is be cool with the maintainers even when they are wrong. State your argument without being a dick. It will be nicer for them and you actually have more chance to get a helping hand from them. No need to put a light on then on the social networks. We all write bad code from time to time.

Well, if I understood correctly, the problem is the rendering performance, I think it is an issue but I can't read yet a 1GB file in the console yet. But if he can then it is really bad that the terminal couldn't do it.

Maybe he could measure piping performance or something else that really matters but rendering text? (or developers should stop that practice to log everything in the console and put it in a file or something else).

Make them quit by flaming a volunteer on GitHub issues?

Shouting at people how shitty they are has zero constructive benefits. Sure you can critizie them but then actually starting a dialogue, recommending some actionable points, providing feedback (preferably not laced with swear words) is an actual contribution towards a goal. Dumping rant after rant on volunteer contributors burns them out, makes them leave and shrinks the team. Actively hurting the chances of issues getting worked on.

If level-headed discourse without bringing their axe to grind along is too hard for some people maybe they shouldn't be part of communities.

Some people (by their own admission) respond well to fat-shaming - does that mean it's always, or even commonly, justified to use that tactic?

You know, I wonder what timeline we'd be in if the comment was instead

I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” 😅

Because I believe that comment was originally intended to be a joke. But tone is hard to convey on the internet, and now a misunderstanding has spiraled into all this.

He's going to be in for a shock if any potential employer looks up his Github and sees his comments. Even if he were right, nobody wants to hire someone with that kind of attitude.

I mean then I get it, it sucks living on noodles and seeing people clearly much more incompetent than yourself making six figures for subpar work you could do on the weekends.

I do not believe that MS devs never actually look at GPL code. This is probably a line they write to avoid legal issues and have plausible deniability.

Microsoft is free to buy a license from Casey.

I do understand that. I don't think you understand the comment you're replying to though.

Yes, before refterm was implemented, there was termbench.

FYI alacritty crashes on it.

https://github.com/cmuratori/termbench

Casey's code style is to typically use zero dependencies, use datastructures that solve the problem AT HAND, not some generic problem, use extremely simple C++ constructs, and write code that is easy to maintain and modify. Another big thing I've noticed in his code is that he almost never worries about memory allocation because he always allocates up front and manages memory at a very high level.

Mike Acton describes this style of programming as "Data-oriented design": https://www.youtube.com/watch?v=rX0ItVEVjHc

You can get very fast code, very quickly using this methodology.

Unfortunately it requires unlearning a lot of orthodoxies about how to do "professional" software engineering (Object Oriented Enterprise Grade Programming, for example). He made the Handmade Hero series on Youtube in which he uses this style of programming to make a game engine.

He doesn't start with faulty assumptions.

The only trick is he uses an LRU cache for glyphs.

That's basically it.

I don't know why, but one thing to remember is that "refterm2" isn't actually a terminal. There's a warning right there, if you try to use it you're going to have a bad day.

It's possible that he's produced a wicked-fast tech demo that was optimized for the specific use cases he's demonstrating, and that adding in all the bits that support the weirdo edge cases that inevitably come into play (especially when you're playing the compatibility long game like MS does), it'll settle into something closer to other high-performance terminals.

I don't know that this is true, maybe he's operating on a whole other level, but it's possible.

I think, by no optimizations, he means beyond the different structural decisions. He hasn’t attempted to squeeze performance out of that structure.

Ah I was mistaken. It’s not a pr yet, just an issue that’s currently being worked