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

411–420 of 429 posts

Re: It takes a PhD to develop that

#411

Post by CapsAdmin »

skytreader wrote: post #310
crispyambulance wrote: post #285

Earlier quoted context omitted.

I think the comment below in the github thread sums up the attitude of the developer. It's definitely not a "neutral" attitude. It's somewhat chip-on-shoulder and somewhat aggressive. > Setting the technical merits of your suggestion aside though: peppering your comments with clauses like “it’s that simple” or “extremely simple” and, somewhat unexpectedly “am I missing something?” can be read as impugning the reader.…

Man, if we start taking issue with "Am I missing something?", how can we have productive, good-faith discussions? The only attitude I can associate with that is openness to learn, a genuine curiosity. How is a yes/no question aggressive? At that point the maintainers had two possible responses: 1. Yes you are missing that ... 2. No that is the complete picture. But they chose to side channel to a third possibility, "…

I do get the sense that the "feel" in his writing eventually becomes more like "what are you guys smoking, this should be simple!"

It's not just "Am I missing something?"

It's:

"Am I missing something? Why is all this stuff with "runs of characters" happening at all? Why would you ever need to separate the background from the foreground for performance reasons? It really seems like most of the code in the parser/renderer part of the terminal is unnecessary and just slows things down. What this code needs to do is extremely simple and it seems like it has been massively overcomplicated."

Perhaps frustrated that they don't really seem to be on the same technical page?

I tend to think these things can go both ways. I feel pointing out someone's frustration in writing tends to make things worse. Personally I would just ignore it in this case.

Re: It takes a PhD to develop that

#412

Post by justin66 »

zibzab wrote: post #275
jameshart wrote: post #263

Earlier quoted context omitted.

And to be clear, Microsoft probably has plenty of people capable of writing this kind of code. They just aren’t working on console. In fact, consider the hypothetical of: what if Microsoft had hired Casey Muratori. Do you imagine they’d have put him on the console team? I mean the Windows console, not the X Box console, or the Minecraft console.

Microsoft has _Micheal Abrash_. He wrote The Book on rendering performance. Michael's super optimized x86 assembly routines for lighting and texturing is the reason we can run Quake on toasters. Anyway, I don't think they should hire Casey. Specially after that demonstration of not understanding the big-picture and not being a team player...

> Microsoft has _Micheal Abrash_.

Michael Abrash left Microsoft 19 years ago.

Re: It takes a PhD to develop that

#413

Post by cyber_kinetist »

cyber_kinetist wrote: post #167
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 record…

Damn, my brain died while writing that one.

Re: It takes a PhD to develop that

#414

Post by baobabKoodaa »

jstimpfle wrote: post #406
baobabKoodaa wrote: post #364

Earlier quoted context omitted.

> Algorithm "skills" are probably overrated in the sense that people can memorize textbook algorithms and their analyses all they want ... Memorizing algorithms has very little to do with algorithm skills. You can memorize any algorithm textbook you like, then go take part in an algorithm competition and see how far that will get you (spoiler alert: not far). If you are good at algorithms, you have the ability to con…

> In this case things weren't nuanced and complicated and whatnot justifying a 40x performance drop when rendering colored text. In this case things really were simple: turns out this was just a horribly inefficient solution (like Many products written by Microsoft are). My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To…

> My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To clarify, in practice, what you use 90% of the time are plain arrays and indices / pointers. Occasionally you'll use a hashmap to lookup (distributed) or cache something.

This doesn't make any sense. It sounds like you're implying that algorithms are not... using plain arrays and pointers? But that's exactly how algorithms are usually constructed. Even the HashMaps you mentioned are typically implemented by using arrays and pointers. If you use arrays and pointers to write something that, let's say, has O(n^3) time complexity when the same operation could be written with O(n) time complexity, then you have an algorithm problem.

> Performance drops in the real world are most often explained by lack of understanding what certain library calls do, lack of understanding what are their performance characteristics, and/or lack of understanding what needs to be done to satisfy the requirements, or what the requirements should even be.

This is such a weak excuse. If you don't understand why a library call is crushing your performance, then stop using that library. People typically use libraries to do the tiniest of tasks, tasks that could often be solved with custom code that can be written in an hour. As the result of this attitude we have terminals that have performance issues... for rendering colored text. That's insane! Sometimes it feels like this whole field is just people gluing together pieces made by other people, with no understanding whatsoever about how everything works. There's no excusing for this behavior.

Re: It takes a PhD to develop that

#415

Post by trulyme »

mkr-hn wrote: post #230
moffkalast wrote: post #220

Earlier quoted context omitted.

Well given how absurdly big the difference is, and the main thing he did was render on demand instead of 7000fps I think he has a good reason to be condescending and they totally deserve it for wasting millions of people's time with this shit.

See also: the blinking cursor in Visual Studio Code. Here's a thread on it with other examples: https://news.ycombinator.com/item?id=13940014 They fixed it, but it was a sign of the times. Everything we've used over the decades had to be re-implemented for the web and stuff like Electron, and the people doing the implementing use such powerful machines that they don't even notice a simple blinking cursor devouring CP…

This! Developers at MS (edit: and elsewhere) should be forced to use their brainwork on low-end machines at least two days a week.

Or not - regardless of what MS employee claimed, Linux terminals performance is more than adequate.

Edit: I am speaking of Linux, not WSL, of course.

Re: It takes a PhD to develop that

#416

Post by jstimpfle »

baobabKoodaa wrote: post #414
jstimpfle wrote: post #406

Earlier quoted context omitted.

> In this case things weren't nuanced and complicated and whatnot justifying a 40x performance drop when rendering colored text. In this case things really were simple: turns out this was just a horribly inefficient solution (like Many products written by Microsoft are). My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To…

> My original point was that the reason for the performance drop likely wasn't related to algorithms. In practice, algorithms rarely are the issue. To clarify, in practice, what you use 90% of the time are plain arrays and indices / pointers. Occasionally you'll use a hashmap to lookup (distributed) or cache something. This doesn't make any sense. It sounds like you're implying that algorithms are not... using plain…

No need to get condescending.

> It sounds like you're implying that algorithms are not... using plain arrays and pointers?

Ok, but no, I did not mean to imply that. What I mean is that most programs are either straightforward linear scans over whole arrays, or working on data that was specifically requested by some index requested by a separate entity. Using a hashmap to lookup items faster is almost at the ceiling of complexity of most real-world programs.

And really, that's sufficient to do most things at max speed. "Algorithms" (meaning stuff like interval trees, Fenwick trees, LCA computation, square root decomposition...) is irrelevant academic exercise for the vast majority of applications (including kernels and games).

At the stage of using the most optimal algorithm (which is probably so simple that it doesn't deserve that name) we're still frequently dealing with factors of 10x to 1000x of inefficiencies - optimal code from an algorithms / asymptotic standpoint but just badly implemented.

> Sometimes it feels like this whole field is just people gluing together pieces made by other people, with no understanding whatsoever about how everything works.

That's exactly how it is. To people who want to do better I recommend to check out programmers like Casey Muratori (original poster of the github issue), and to check out Handmade Network community for example.

> There's no excusing for this behavior.

They didn't know better. Not particularly flattering though.

Re: It takes a PhD to develop that

#417

Post by PicassoCTs »

The problem with the excuse parade is, that it has to justify itself. They have to be special, the avant-garde, selected through countless interviews to live well inside the castle. If some wandering apprentice can outperform them, the hot air escape from the "rockstar" developer, wrestling with complex code sitting inside the compound of a FAMG firm.

Then nothing remains, but embarrassed silence. And the question, why this people are paid for, if they waste the customers money, aka performance of the customers computational platform and the outcome is so sub-par. Which is why they are sitting all in one huge meeting today.

Re: It takes a PhD to develop that

#418

Post by fouric »

l30n4da5 wrote: post #360
vermilingua wrote: post #187

Earlier quoted context omitted.

But it isn't an edge case! It's not an edge case, if it isn't a use case! This is an edge case as much as building a rasterizer directly into the terminal is an "edge case".

> But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.

Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be".

The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts.

That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.

Re: It takes a PhD to develop that

#419

Post by fouric »

tjalfi wrote: post #385
thih9 wrote: post #26

Earlier quoted context omitted.

This seems referenced in the repo itself, see the “feature support” section [1]. That being said, is anyone aware of a significant missing feature that would impact performance? [1]: https://github.com/cmuratori/refterm#feature-support

Screen reader support[0] may have a noticeable performance cost. [0] https://github.com/microsoft/terminal/issues/10528#issuecomm...

Can you explain how screen reader support could possibly have a noticeable performance cost?

The screen reader code should be doing absolutely nothing if it's not enabled - and even if it is, I can't imagine how it could affect performance anyway. For plain text, such as a terminal, all it does is grab text and parse into words (and then the part where it reads the words, but that's separate from the terminal) - I don't see how this is any more difficult than just taking your terminal's array of cell structs, pulling out the characters into a dynamic array, and returning a pointer to that.

Re: It takes a PhD to develop that

#420

Post by fouric »

chenglou wrote: post #122

In case this isn't clear, RefTerm is: 1. Faster in every case tested 2. More fully-featured, including i18n 3. Easier to read and maintain (see for yourself) 4. Shorter 5. Using existing libs, aka interops well ...So none of these typical hand-wavy dismissals apply: 1. "Is it really faster for edge cases" 2. "He probably didn't implement certain features like Arabic and Chinese" 3. "Businesses just wants enough" 4. "…

I don't think dismissal 1 applies anyway - even if RefTerm didn't implement, say, variable-width fonts - you could just build a terminal that uses RefTerm's fast algorithms for the common case, then falls back to the Windows Terminal's slower algorithms for the more general case.
Post reply on HN