Earlier quoted context omitted.
What's wrong with the performance? I don't notice any performance issues in Windows terminal.
Do you use colored text tags? The performance issues only happened when that was on.
Yes
It takes a PhD to develop that
341–350 of 429 posts
Re: It takes a PhD to develop that
#342Earlier quoted context omitted.
> could they not have collaborated to put together an improvement in Windows Terminal? My experience with people that want to collaborate instead of just recognizing and following good advice is that you spend a tremendous amount of effort just to convince them to get their ass moving, then find out they were not capable of solving the problem in the first place, and it’s frankly just not worth it. Much more fun to j…
> Much more fun to just reimplement the thing and then say “You were saying?” The thing is NO ONE likes to lose face. He could have still done what he did (and enjoy his "victory lap") but in a spirit of collaboration. To be fair, MS folks set themselves up for this but the smart-alec could have handled it with more class and generosity.
This was purely self-inflicted.
Re: It takes a PhD to develop that
#343Earlier quoted context omitted.
Honestly, I felt like the ones to start with the condescending tones were the Microsoft devs who kept talking down to Casey about You Don't Understand How Hard This Is, when they also readily admitted they didn't understand the internals very well.
I don't think they're actually contradicting themselves there. They know enough about how hard text rendering is to conclude that they're better off delegating it to the team that specializes in that particular area, even though it means they have to settle for a good-enough abstraction rather than winning at a benchmark.
Enterprise deployment of a Somebody Else’s Problem field can really harm innovation,
“Any object around which an S.E.P. is applied will cease to be noticed, because any problems one may have understanding it (and therefore accepting its existence) become Somebody Else's Problem.”
Re: It takes a PhD to develop that
#344Earlier quoted context omitted.
Honestly, I felt like the ones to start with the condescending tones were the Microsoft devs who kept talking down to Casey about You Don't Understand How Hard This Is, when they also readily admitted they didn't understand the internals very well.
I don't think they're actually contradicting themselves there. They know enough about how hard text rendering is to conclude that they're better off delegating it to the team that specializes in that particular area, even though it means they have to settle for a good-enough abstraction rather than winning at a benchmark.
Agree. Rendering text well really is hard, if you sit down and try to do it from scratch. It’s just that dealing with all of the wonderful quirks of human languages doesn’t have to make it _slow_. That’s their mistake.
And you’re right; all refterm really does is move the glyph cache out to the GPU rather than copying pixels from a glyph cache in main memory every frame.
Re: It takes a PhD to develop that
#345> Due to the way the programmer’s ranking system works, an average company will have a big crowd of inexperienced people and very few who can tackle complex problems. For this reason, the vast majority of software is written by the ones who are still learning the ropes.
I wonder if another reason is just that it’s such a growing industry. The number of CS grads each year are growing, and I know tons of people who sidestepped into the profession from other degrees as well. The number of jobs too. If the job market is twice the size it was a decade ago, half the employees are going to be new no matter what. Perhaps hilariously, that huge demand means high wages, means more early retirements, means fewer senior people too.
Re: It takes a PhD to develop that
#346Earlier quoted context omitted.
Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…
I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil." I have encountered far too many people who interpret that to mean, "thou shall not even even consider performance until a user, PM or executive complains about it."
> I feel obliged to point out the destructive power of Knuth's statement, "Premature optimization is the root of all evil."
Except that line was written in a book (Volume 1: Art of Computer Programming) that was entirely written from the ground up in Assembly language.
Its been a while since I read the quote in context. But IIRC: it was the question about saving 1 instruction between a for-loop that counts up vs a for-loop that counts down.
"Premature optimization is the root of all evil" if you're deciding to save 1-instruction to count from "last-number to 0", taking advantage of the jnz instruction common in assembly languages, rather than "0 to last-number". (that is: for(int i=0; i=0; i--). The latter is slightly more efficient).
Especially because "last-number to 0" is a bit more difficult to think about and prove correct in a number of cases.
Re: It takes a PhD to develop that
#347Earlier quoted context omitted.
The ticket discussion brought to light that it is a rendering problem. The other person wrote a terminal renderer that has none of the performance problems and all of the required features. I would say the MS developers have been proven wrong.
Possibly the thread has been edited, but I see the original poster claiming that, and it seems a popular view around here, but I don't actually see the evidence that it actually happened in the thread itself. Are we talking about this thread? https://github.com/microsoft/terminal/issues/10362
It's here:
https://github.com/cmuratori/refterm
That issue was closed but the current open issue which acknowledges this is a real problem is here:
https://github.com/microsoft/terminal/issues/10462
Here is a comment on the code directly from a contributor at Microsoft:
> @AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us to strive for. Unfortunately the code is intentionally GPLv2 licensed and we‘ll honor this wish entirely. As such no one at Microsoft will ever look at either of the links.
> I‘m the person who‘s tasked with building an equivalent solution and you may subscribe to #10461 to get updates of my progress. Unfortunately our existing project isn’t straight forward to modify the same way we could build a terminal from scratch. A lot of parts of this project must be rewritten and as such it‘ll take a bit for us to catch up. But we will - it’s only a matter of time.
https://github.com/microsoft/terminal/issues/10462#issuecomm...
Re: It takes a PhD to develop that
#348Yup, this. Something I've been ranting about[0] for a while: there is no technical progression ladder. The Senior->Principal-> ... path seems to be a faux-management track, with all the managerial responsibilities and little of the authority. Software is shitty in big part because it's mostly written by juniors, as almost anyone who has any clue moves over (or gets pushed over) to managerial or faux-managerial roles.…
It seems like companies are creating independent contributor tracks to remedy this issue. You can have people who are legendary programmers float around and contribute where they wish.
Re: It takes a PhD to develop that
#349Earlier quoted context omitted.
When I saw this mentioned on HN I immediately knew this kind of comment would be there because something along the lines and I am paraphrasing "its probably fast because its not enterprise enough" was repeated in every place the refterm was shared by different people even multiple times even after showing all the proof in the world that its in fact the opposite they almost refused to believe that software can be that…
Seconding. It takes doing some low-level gamedev[0] stuff, or using software written by people like Casey, to realize just how fast software can be. There's an art to it, and it hits diminishing returns with complex software, but the baseline of popular software is so low it doesn't take much more than a pinch of care to beat it by an order of magnitude. (Cue in the "but why bother, my app is IO bound anyway" counter…
I think there's a story in here that most are missing, but your comment is closest to touching on. This was not a performance problem. This was a fundamental problem that surfaced as a performance issue.
The tech stack at use in the Windows Terminal project is new code bolted onto old code, and no one on the existing team knows how that old code works. No one understands what it's doing. No one knows when the things that old code needed to do was still needed.
It took someone like Casey who knew gamedev to know instinctually that all of that stuff was junk and you could rewrite it in a weekend. The Microsoft devs, if they wanted to dive into the issue, would be forced to Chesteron's Fence every single line of code. It WOULD have taken them years.
We've always recommended that programmers know the code one and possibly two layers below them. This recommendation failed here, it failed during the GTA loading times scandal. It has failed millions of times and the ramifications of that failing is causing chaos of performance issues.
I'm come to realize that much of the problems that we have gotten ourselves into is based on what I call feedback bandwidth. If you are an expert, as Casey is, you have infinite bandwidth, and you are only limited by your ability to experiment. If your ability to change is a couple seconds, you will be able to create projects that are fundamentally impossible without that feedback.
If you need to discuss something with someone else, that bandwidth drops like a stone. If you need a team of experts, all IMing each-other 1 on 1, you might as well give up. 2 week Agile sprints are much better than months to years long waterfall, but we still have so much to learn. If you only know if the sprint is a success after everyone comes together, you are doomed. The people iterating dozens of times every hour will eat your shorts.
I'm not saying that only a single developer should work on entire projects. But what I am saying is that when you have a Quarterback and Wide Receiver that are on the same page, talking at the same abstraction level, sometimes all it takes is one turn, one bit of information, to know exactly what the other is about to do. They can react together.
Simple is not easy. Matching essential complexity might very well be impossible. Communication will never be perfect. But you have to give it a shot.
Re: It takes a PhD to develop that
#350Earlier quoted context omitted.
Possibly the thread has been edited, but I see the original poster claiming that, and it seems a popular view around here, but I don't actually see the evidence that it actually happened in the thread itself. Are we talking about this thread? https://github.com/microsoft/terminal/issues/10362
It's here: https://github.com/cmuratori/refterm That issue was closed but the current open issue which acknowledges this is a real problem is here: https://github.com/microsoft/terminal/issues/10462 Here is a comment on the code directly from a contributor at Microsoft: > @AnuthaDev We‘re quite aware about the code and are extremely happy about what was created there. I mean it seriously: It sets a great goal for us…
Maybe I'm misreading that comment from the MS devs but it seems like a very politely worded, "fuck off" rather than a "yes, you were right".
Could be wrong, but even if I'm right about that, I'm still on their side I think.