It takes a PhD to develop that • Hacker News Board

Re: It takes a PhD to develop that

#161

Post by baobabKoodaa » Mon, Oct 04, 2021, 11:34 AM UTC

jstimpfle wrote: post #141

baobabKoodaa wrote: post #76

I understand that different people have different skill sets, that's totally fine. I don't think every single senior developer at Microsoft should have the skillset to fix performance issues like this. That said, however, I do think developers should be able to recognize when a task requires a skill that they do not have. In those cases it's best to reach out to someone within the organization who has that skill. Or,…

I don't think this is about algorithms.

Yes it is. When you have 2 programs that do the same thing, except one program is orders of magnitude faster than the other, it's almost* always because the faster program is written with better algorithmic time complexity.

(*In some cases the big-O time complexity may be the same for 2 programs, but one program can still be much faster in practice due to micro-optimizations, heuristics, etc. Even in cases like this, people who are good at algorithms will be better at writing these heuristics and micro-optimizations than people who don't care about algorithms.)

Re: It takes a PhD to develop that

#162

Post by vblap » Mon, Oct 04, 2021, 11:34 AM UTC

mytailorisrich wrote: post #44

The github issue is a gem. The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions. The tone gets quite condescending towards him. He gets out of all this with flying colours. He should consider adding that Github issue to his resume.

Yeah, typical Microsoft developers (https://github.com/microsoft/terminal/issues/10362). That issue was pretty mild, they felt threatened and used CoC principles ("combative") to shut down the threat.

This is how they also ruin "open" source projects like Python now.

Re: It takes a PhD to develop that

#163

Post by makomk » Mon, Oct 04, 2021, 11:34 AM UTC

ribit wrote: post #58

onion2k wrote: post #7

A few hours later another programmer came up with the prototype of a much faster terminal renderer, proving that for an experienced programmer a terminal renderer is a fun weekend project and far away from being a multiyear long research undertaking. I have no idea if this is the case here, and I suspect it might not be, but pretty much every time I've seen a developer complain that something is slow and then 'prove'…

I don't know about you, but I was really laughing out loud reading that GitHub conversation. GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time MS engineers: drawing colored text is SLOW, what do you expect P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can ren…

It's more subtle than that. What the Microsoft engineers are saying is that the console's current approach to drawing text is inherently slow in this particular case, due to the way the text drawing library it's based on uses the GPU. The proposed solution requires the terminal to have its own text drawing code specific to the task of rendering a terminal, including handling all the nasty subtlties and edge-cases of Unicode, which must be maintained forever. This is not trivial at all; every piece of code ever written to handle this seems to end up having endless subtle bugs involving weird edge-cases (remember all those stories about character strings that crash iPhones and other devices - and the open source equivalents are no better). It's relatively easy to write one that seems to work for the cases that happen to be tested by the developer, but that's only a tiny part of the work.

Re: It takes a PhD to develop that

#164

Post by Aeolun » Mon, Oct 04, 2021, 11:35 AM UTC

kevingadd wrote: post #113

ribit wrote: post #58

Earlier quoted context omitted.

I don't know about you, but I was really laughing out loud reading that GitHub conversation. GPUs: able to render millions of triangles with complex geometrical transformations and non-trivial per-pixel programs in real time MS engineers: drawing colored text is SLOW, what do you expect P.S. And yes, I know, text rendering is a non-trivial problem. But it is a largely solved problem. We have text editors that can ren…

Simply shaping text using state of the art libraries (like harfbuzz) can take an INCREDIBLE amount of time in some cases. If you're used to rendering text in western character sets you may think it can always be fast, but there are cases where it's actually quite slow! You get a sense for this if you try to write something like a web browser or a word processor and have to support people other than github posters. Of…

> naturally going to be somewhat slow

Naturally slow for a text renderer might mean it renders in 4ms instead of 0.1.

Re: It takes a PhD to develop that

#165

Post by somehnacct3757 » Mon, Oct 04, 2021, 11:35 AM UTC

mwcampbell wrote: post #56

tinco wrote: post #49

Earlier quoted context omitted.

And the experienced developer is Casey Muratori who is somewhat well known for being a very experienced developer. That makes it less likely that he doesn't know what he's talking about and is skipping over hard/slow features.

However, his experience, in games and game development tools AFAIK, might not be fully applicable to the development of mainstream commercial software that has to try to be all things to all people, including considerations like internationalization, accessibility, and backward compatibility. The performance difference that he demonstrated between Windows Terminal and refterm is certainly dramatic, but I wouldn't be…

In my experience as a former game dev who moved to enterprise apps, game dev techniques are broadly applicable and speed up enterprise apps without compromising on functionality.

Consider memory management techniques like caching layers or reference pools. Or optimizing draws for the platform's render loop. Or being familiar with profiler tools to identify hotspots. These techniques are all orthogonal to functionality. That is, applying them when you see an opportunity to will not somehow limit features.

So why aren't the enterprise apps fast, if it's so easy? I think that boils down to incentives. Enterprise apps are sales or product led and the roadmap only accommodates functionality that makes selling the software easier. Whereas in games the table stakes point you need to reach for graphics is not achievable by naively pursuing game features.

Put another way, computers and laptops are way stronger than consoles and performance is a gas. Enterprise devs are used to writing at 1 PSI or less and game devs are used to writing at 1 PSI or more.

Re: It takes a PhD to develop that

#166

Post by bsenftner » Mon, Oct 04, 2021, 11:35 AM UTC

TeMPOraL wrote: post #101

Hnus wrote: post #84

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

Third'ing: the current crop of new developers have no freaking idea how much power they have at their finger tips. Us greybeard old game developers look at today's hardware and literally cream our jeans in comparison to the crap we put up with in the previous decades. People have no idea, playing with their crappy interpenetrated languages, just how much raw power we have if one is willing to learn the low level languages to access them. (Granted, Numpy and BLAS to a wonderful job for JIT languages.)

Re: It takes a PhD to develop that

#167

Post by cyber_kinetist » Mon, Oct 04, 2021, 11:36 AM UTC

mytailorisrich wrote: post #44

The github issue is a gem. The reporter is basically being fobbed off by being flooded by random buzzwords and data points, none of them specific, but he keeps trying to drill down to specifics by asking questions. The tone gets quite condescending towards him. He gets out of all this with flying colours. He should consider adding that Github issue to his resume.

He is already well-known enough in his field past the point of writing a resume, and I don't think he really would want to enter the corporate IT world that he intensely despises (even with lots of cash). Plus he's already busy on his own working on various projects: the video game 1935 (which we don't really know that much of), Star Code Galaxy (a CS course focusing on fundamentals), and Handmade Hero (A live recording / tutorial of making a game from scratch). He's already really

Re: It takes a PhD to develop that

#168

Post by schlupa » Mon, Oct 04, 2021, 11:37 AM UTC

eloisant wrote: post #46

cornel_io wrote: post #31

Earlier quoted context omitted.

That sounds like you've never seen performance of a heavily worked-on subsystem increase by 10x because one guy who was good at that kind of stuff spent a day or two focused on the problem. I've seen that happen at least 10 times over my career, including at very big companies with very bright people writing the code. I've been that guy. There are always these sorts of opportunities in all but the most heavily optimi…

More generally, in my experience performance isn't looked at because it's "good enough" from a product point of view. "Yes it's kinda slow, but not enough so customers leave so who cares." Performance only becomes a priority when it's so bad customers complain loudly about it and churn because of it.

There's also sometimes the incentive to slow things down because if it is too fast, the client will perceive that he paid too much money for an operation that takes no time, i.e. it doesn't exists seems unimportant.

Re: It takes a PhD to develop that

#169

Post by mwcampbell » Mon, Oct 04, 2021, 11:37 AM UTC

I pity the developer (or maybe manager) at Microsoft who wrote the GitHub comment on which this article's title is based. (And no, I never met him when I was at Microsoft.) If he's in the Seattle area, he's likely not even awake yet, but when he is, I expect he's going to have a bad day. Assuming he's not already sick of the Windows Terminal versus refterm drama, it would be interesting to read his perspective.

Re: It takes a PhD to develop that

#170

Post by Jach » Mon, Oct 04, 2021, 11:38 AM UTC

TeMPOraL wrote: post #67

Yup, 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.…

There may be a sort of sweet spot in the progression where a programmer can advance to a point where they spend most of their time figuring out the code architecture (maybe with a skeleton) for others to implement the details of, with some code reviews here and there, rather than coding as much themselves (but they still code, especially the critical pieces). This lets them still be a key player as far as programming is concerned but there's also a space for more junior programmers to learn and grow without trashing the whole project in the process. The Godot engine seems to be turning into this sort of sweet spot model with its tech lead. However in a company this seems like an unstable situation, since I've seen such leads advance another step and now the only thing they "architect" is business strategy via all-day meetings, like any other executive, and the last time they coded anything was years ago. You might get them on a rare code review but they've become so far removed from the details they're not as helpful as they used to be, which in turn leads to not including them anymore. This distance hurts again because now that they have at least some influence (not as much as the 'equivalent' managerial track position, 'mysteriously') to address long-standing dev pains they are too far removed from the pain to spend their limited influence fighting it.

My own filter for how likely a company is to fall (or be) in this trap: does the CTO code at all?