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

51–60 of 429 posts

Re: It takes a PhD to develop that

#51

Post by misnome »

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.

"Need" especially, because often it's just that those fresh eyes don't have any of the political history, so doesn't have any fallout from cutting swaths through other people's code that would be a problem for someone experienced in the organisation.

Re: It takes a PhD to develop that

#52

Post by AndrewThrowaway »

jiggawatts wrote: post #20
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'…

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

You just begin to wonder how these things happen. You would think top programmers work at these companies. Why would they not start with the good concept, loading GPU first etc. Why did it take them so much time to finally do it correctly. Why waste time not doing it at the beginning.

Re: It takes a PhD to develop that

#53

Post by rhizome »

moralestapia wrote: post #8

This reflects a lot of what goes on in Academia as well. Also, if you think you can counter a "that's not possible" with a working proof of said thing working, think again, most people don't like to be shown they're wrong, particularly tenured professors. That's one of the fastest ways to sabotage your own developing career. "Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.…

>"Yes men" climb the ladder much easier, but then work doesn't do itself so that's the catch.

The harder the work, the lower the pay.

Re: It takes a PhD to develop that

#54

Post by loup-vaillant »

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

As good as Casey Muratori is, Microsoft is more than big enough to have the means of taking his core ideas and implement them themselves. It may not take them a couple weekends, but they should be able to spend a couple experienced man-months over this.

The fact they don't can only mean they don't care. Maybe the people at Microsoft care, but clearly the organisation as a whole as other priorities.

Besides, this is not the first time I've seen Casey complain about performance in a Microsoft product. Last time it was about boot times for Visual Studio, which he does to debug code. While reporting performance problems was possible, the form only had "less than 10s" as the shortest boot time you could tick. Clearly, they considered that if VS booted in 9 seconds or less, you don't have a performance problem at all.

Re: It takes a PhD to develop that

#55

Post by pjc50 »

> the software industry doesn’t value technical excellence as much as it values having warm bodies report to you.

One of those can easily and objectively be measured, and the other one can't.

Various orgs have tried to measure financial "value", imperfect in and of itself, but then face serious problems attributing that to individual developers.

Fundamentally, discussing "good" software is performing subjective evaluations against subjective criteria. There's no easy route out of that.

Re: It takes a PhD to develop that

#56

Post by mwcampbell »

tinco wrote: post #49
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…

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 surprised if there's something he's overlooking.

Re: It takes a PhD to develop that

#57

Post by RealityVoid »

NhanH wrote: post #9

> 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 read through the Github issue and can't find the prototype mentioned here. Can anyone link the PR/code if they know it please?

I was curious as well, I dug a bit and I found this:

https://github.com/cmuratori/refterm

I think he just went ahead and created a completely different terminal.

Also, some background, the original raiser of the PR is Casey Muratori, of Handmade Hero fame:

https://www.youtube.com/channel/UCaTznQhurW5AaiYPbhEA-KA

https://github.com/cmuratori/

https://caseymuratori.com/

Re: It takes a PhD to develop that

#58

Post by ribit »

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 render huge files with real-time syntax highlighting, browsers that can quickly layout much more complex text, and, obviously Linux and Mac terminal emulators that somehow have no issue whatsoever rendering large amount of colored text.

Re: It takes a PhD to develop that

#59

Post by dmitriid »

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…

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

Windows Terminal has none of that. And his refterm already has more features implemented correctly (such as proper handling of Arabic etc.) than Windows Terminal. See feature support: https://github.com/cmuratori/refterm#feature-support

Also see FAQ: https://github.com/cmuratori/refterm/blob/main/faq.md

Re: It takes a PhD to develop that

#60

Post by holoduke »

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…

Because a rule of thumb is to not focus too much on performance in the beginning of a project. Better a completed project with some performance issues, than a half product with hyper speed. The key thing with development is to find somekind of balance within all these attributes (stability, performance, loo, reusability etc) In case of FS simulator. Not sure what the motives were. Sure that they had some serious time constraints. I think they did an acceptable job there.
Post reply on HN