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

It takes a PhD to develop that

blog.royalsloth.eu

Post reply on HN
Print view View original

71–80 of 429 posts

Re: It takes a PhD to develop that

#71

Post by zohch »

joshuamorton wrote: post #48
zohch wrote: post #40

Earlier quoted context omitted.

> It saddens me to see, time and again, the role of leadership painted in such a dire and incorrect way. It saddens me to time and again be stuck with "leaders" who don't know what they are talking about and think they need to weigh in on everything, even though they add negative value when they do so, because they want to justify their mostly pointless job. In a 14 year career, I have had "leadership" that is not co…

So have you met any good leaders? Or are you saying that good leaders are nearly impossible to find (and therefore perhaps the job is difficult?)

> So have you met any good leaders?

I have met people who lead well, but I have not met anyone who's job it was to be a leader that lead well.

> Or are you saying that good leaders are nearly impossible to find (and therefore perhaps the job is difficult?)

It's almost impossible to find someone that has a job of being a leader that is good leader. The job being difficult does not explain why the worst possible people end up being leaders, and it also does not mean that we should somehow not call out the phenomena that leadership is mostly feckless and adds negative value.

We should call this out more often, and we should tell people who want to be leaders that they better not suck because there are enough people who suck at it, and we should let them know that going by actual outcomes, they will likely suck, and are even more likely to suck if they think they are good at it.

Re: It takes a PhD to develop that

#72

Post by cornel_io »

yetihehe wrote: post #41
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…

I've made such optimizations and others made them in my code, so: c) slow code happens to everyone, sometimes you need fresh pair of eyes.

Absolutely: what I should have said is that I've been the one to cause performance problems, I've been the one to solve them, I've been the manager who refused to allocate time to them because they were not important enough, and I've been the product owner who made the call to spend eng hours on them because they were. There are many systemic reasons why this stuff does not get fixed and it's not always "they code like crap", though sometimes that is a correct assessment.

But show me a codebase that doesn't have at least a factor of 2 improvement somewhere and does not serve at least 100 million users (at which point any perf gain is worthwhile), and I'll show you a team that is being mismanaged by someone who cares more about tech than user experience.

Re: It takes a PhD to develop that

#73

Post by jiggawatts »

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…

To be fair to the MS engineers, from their background experience with things like DirectText, they would have an ingrained rule-of-thumb that text is slow.

That's because it is slow in the most general case: If you have to support arbitrary effects, transformations, ligatures, subpixel hinting, and smooth animations simultaneously, there's no quick and simple approach.

The Windows Terminal is a special case that doesn't have all of those features: No animation and no arbitrary transforms dramatically simplifies things. Having a constant font size helps a lot with caching. The regularity of the fixed-width font grid placement eliminates kerning and any code path that deals with subpixel level hinting or alignment. Etc...

It really is a simple problem: it's a grid of rectangles with a little sprite on each one.

Re: It takes a PhD to develop that

#74

Post by ClumsyPilot »

quickthrower2 wrote: post #19
Karrot_Kream wrote: post #14

This would be a nice thesis. Unfortunately we have software like memcached, redis, nginx, Envoy, Kafka, Zookeeper, and more that come straight from professional programmers which makes this thesis more complicated than this post makes it sound. Perhaps Occam's Razor should apply here.

That software from a pool of millions of SWE across the world. And importantly this software created outside of corporate structures! I think these exceptions prove the rule. Most SWE are working for companies that don’t make money reinventing architecture. Leading a bunch of people to use existing tools to sell something to customers is probably where most of the value comes from in SME world and probably most of th…

"Everywhere I have worked the very experienced people are probably doing the “the same year repeated many times”

Yeah...

Re: It takes a PhD to develop that

#75

Post by mytailorisrich »

lstamour wrote: post #28
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'…

Reading the thread itself, it’s a bit of both. Windows Terminal is complex, ClearType is complex and Unicode rendering is complex. That said… https://github.com/cmuratori/refterm does exist, does not support ClearType, but does claim to fully support Unicode. Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2 and (b) it sounds like the Windows Terminal project is indeed a bit more complicated than can…

> Unfortunately, Microsoft can’t use the code because (a) it’s GPLv2

One thing to remember is that it is always possible and acceptable to contact the author of a GPL-licensed piece of code to enquire whether they would consider granting you a commercial license.

It may not be worthwhile but if you find exactly what you're looking for and that would take you months to develop yourself then it may very well be.

Re: It takes a PhD to develop that

#76

Post by baobabKoodaa »

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, you know, you can be a senior developer at Microsoft and condescendingly claim that it's impossible, or "takes a PhD to develop that". I guess this is what you get when you fill organizations with people who don't care about performance, computer science or algorithms.

I'm going to use this case as another example to point to when people argue that algorithm skills are useless and shouldn't be used when interviewing.

Re: It takes a PhD to develop that

#77

Post by meheleventyone »

AndrewThrowaway wrote: post #52
jiggawatts wrote: post #20

Earlier quoted context omitted.

This particular case was discussed at length on Reddit and on YC News. The general consensus was that the Microsoft developers simply didn't have performance in the vocabulary, and couldn't fathom it being a solvable problem despite having a trivial scenario on their hands with no complexity to it at all. The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] an…

A bit out of topic but has anybody followed performance issues of Microsoft Flight Simulator 2020? For more than half a year it was struggling with performance because it was CPU heavy, only loading one core and etc. Barely ran on my i5 6500. Fast forward half a year, they want to release it on XBox. MS/Asobo moves a lot of computation on GPU, game starts running smoothly on the very same i5 with maximized quality se…

It's pretty straightforward case of prioritization. There are always more things to do on a game project than you have people and time to do.

The game runs well enough so the people who could optimize things by rewriting them from CPU to GPU are doing other things instead. Later performance is a noticeable problem to the dev team, from customer feedback and need to ship in more resource constrained environments (VR and XBox) and that person then can do work to improve performance.

It's also handy to have a reference CPU implementation both to get your head around a problem and because debugging on the GPU is extremely painful.

To go further down the rabbit hole it could be that they were resource constrained on the GPU and couldn't shift work there until other optimizations had been made. And so on with dependencies to getting a piece of work done on a complex project.

Re: It takes a PhD to develop that

#78

Post by tuananh »

galkk wrote: post #37

cmuratori is great software engineer, for sure, but, god, this bug report poisons the well right from the start (see below). Also the report is actually quite bad, because 40x performance drop, that is stated, could be actually nothing. If something takes 1 millisecond instead of 25 microseconds (numbers from the head, to illustrate the point), it might be an issue, but also might mean nothing. This is the thing that…

i find the expected behavior paragraph perfectly fine.

Re: It takes a PhD to develop that

#79

Post by [deleted] »

galkk wrote: post #50
mwcampbell wrote: post #43

Earlier quoted context omitted.

> 40x performance drop that is stated could be actually nothing. It isn't though. The performance difference between Windows Terminal and refterm is dramatic enough that he could demonstrate it in a video.

And that is why I'm saying that initial bug report could be done better. For example, out of curiosity I did the test from the last message: doing "cat big.txt" in WSL2. In Windows terminal it took 1.5s, but in Kitty terminal, that is running under wslg (same ubuntu version), it takes 0.34s. Powershell, from the other side, is awful (20-25s).

[deleted]

Re: It takes a PhD to develop that

#80

Post by tonyedgecombe »

thriftwy wrote: post #47
tasogare wrote: post #4

Earlier quoted context omitted.

Windows terminal is a shit show. The dev blogs posts are all about useless features such as image background while fundamentals like unicode input are still broken.

Like Windows Notepad. I suspect it was never designed for anything more than trivial cases, and then it never got requirements overhaul later in subsequent versions of Windows.

I was under the impression that Windows Terminal is a recent greenfield project.
Post reply on HN