Live data from Hacker News

It takes a PhD to develop that

blog.royalsloth.eu

371–380 of 429 posts

Re: It takes a PhD to develop that

#371
post #319

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.

Yes, the open source volunteers and random employees deserve it. They are responsible for all of microsoft's many sins, and we should find them online and tell them they are trash tier developers until they learn their lesson, right? Ok, sarcasm off. This attitude is utterly toxic. People who are ignorant of how fast their software could be do not deserve abuse from strangers.

> People who are ignorant of how fast their software could be do not deserve abuse from strangers.

That's not the only valid way to frame the situation. At some level, professional software developers have a responsibility to be somewhat aware of the harm their currently-shipping code is doing.

Re: It takes a PhD to develop that

#372
Maybe everyone needs their ansi.sys moment though. Back in the early 1990's, I, and probably half the programmers using DOS, rewrote the dos ansi.sys driver/TSR because its was _SLOW_. mostly IIRC because it was calling the BIOS text output, but also because it was a pretty solid implementation of the ANSI terminal/esc sequence "standard".

So, the first half took about an hour or two to handle output (just write a character at the right location in the framebuffer) and get the INT/TSR boilerplate right. Then for the next 20 hours fight with all the edge cases the cropped up with corrupted text in various TUI programs that were calling the DOS string functions. Then as the size+perf approached NANSI.sys (http://www.kegel.com/nansi/) give up...

Learning experience.

Re: It takes a PhD to develop that

#373

Earlier quoted context omitted.

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, "…

> How is a yes/no question aggressive? Have you stopped beating your wife? More relevantly, when the question is asked genuinely then - as you say - it's expressing an openness to learn. Sometimes it is asked rhetorically, dripping with sarcasm and derision. In that case, it is clearly not furthering our interest in productive, good-faith discussions. Far more often, it falls somewhere between those two and - especia…

If you're going to read emotional content into that "Am I missing something?", I think sarcasm and derision are not the most plausible options. In this case, it seems like incredulity is the more likely and appropriate reaction: because it seemed like the person asking the question was putting a lot more thought and effort into the discussion than the Microsoft developers who were not willing to seriously reconsider their off-the-cuff assumptions.

Re: It takes a PhD to develop that

#374

Earlier quoted context omitted.

Sometimes you don't know you have a performance problem until you have something to compare it to. Microsoft's greatest technical own goal of the 2010s was WSL 2. The original WSL was great in most respects (authentic to how Windows works; just as Windows NT has a "Windows 95" personality, Windows NT can have a "Linux" personality) but had the problem that filesystem access went through the Windows filesystem interfa…

WSL2 worked for me in a way that WSL1 did not and it had to do with build times while doing tutorial projects. I am not an expert, but my own experience was that it was a massive improvement.

Parent is not refuting that WSL2 performed better than WSL1, they're arguing that a reasonable response to WSL1 giving you slow build times might have simply been to use a VM instead.

Microsoft being Microsoft, they didn't want people like you to hop to VMware or VirtualBox and use a full, branded instance of Fedora or Ubuntu, because then you would realize that the next hop (moving to Linux entirely) was actually quite reasonable. So they threw away WSL1 and built WSL2. Obviously WSL2 worked better for you than WSL1, but you also did exactly what Microsoft wanted you to do, which is to their benefit, and not necessarily to yours.

Re: It takes a PhD to develop that

#375
post #319

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.

Yes, the open source volunteers and random employees deserve it. They are responsible for all of microsoft's many sins, and we should find them online and tell them they are trash tier developers until they learn their lesson, right? Ok, sarcasm off. This attitude is utterly toxic. People who are ignorant of how fast their software could be do not deserve abuse from strangers.

That said, there's only so much patience one can have...

Re: It takes a PhD to develop that

#376

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

That exact case seem a very appropriate scenario for clarifying? Microsoft kept saying something was difficult, whilst Casey knew that it was not, so really he was being polite by first confirming that there wasn't something he'd overlooked?

There's a difference between "inherently difficult" and "difficult to update this software package". My reading of this thread is that the MS devs are saying this will take them a lot of effort to implement in this app, not that the new implementation could be simpler than the existing implementation. Asking to rearchitect the application is an involved process which would take a lot of back-and-forth to explain the tradeoffs. The new architecture can be simple, but evaluating a new architecture and moving to it are not.

There's a point at which you've moved from "fix this bug" or "evaluate this new component" to "justify the existing design" and "plan a re-architecture".

Re: It takes a PhD to develop that

#377
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…

I started off programming doing web development working on an community run asynchronous game where we needed to optimize everything to run in minimal time and power to save on cost and annoyance. It was a great project to work on as a high schooler.

Then in college, I studied ECE and worked in a physics lab where everything needed to run fast enough to read out ADCs as quickly as allowed by the datasheet.

Then I moved to defense doing FPGA and SW work (and I moonlighted in another group consulting internally on verifcation for ASICs). Again, everything was tightly controlled. On a PCI-e transfer, we were allowed 5 us of maximum overhead. The rest of the time could only be used for streaming data to and from a device. So if you needed to do computation with the data, you needed to do it in flight and every data structure had to be perfectly optimized. Weirdly, once you have data structures that are optimized for your hardware, the algorithms kind of just fall into place. After that, I worked on sensor fusion and video applications for about a year where our data rates for a single card were measured in TB/s. Needless to say, efficiency was the name of the game.

After that, I moved to HFT. And weirdly, outside of the critical tick-to-trade path or microwave stuff, this industry has a lot less care around tight latencies and has crazy low data rates compared to what I'm used to working with.

So when I go look at software and stuff is slow, I'm just suffering because I know all of this can be done faster and more efficiently (I once shaved 99.5% of the run time off of a person's code with better data packing to align to cache lines, better addressing to minimize page thrashing, and automated loop unrolling into threads all in about 1 day of work). Software developers seriously need to learn to optimize proactively... or just write less shitty code to begin with.

Re: It takes a PhD to develop that

#378
post #358
post #196

Earlier quoted context omitted.

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

Knuth's statement was basically "use a profiler and optimize the hot path instead of trying to optimize with your intuition", which is great advice. Most people heard "don't optimize at all". Something that you can derive from that advice is "have a hot path to optimize". I've seen a few programs that aren't trivial to optimize because the work is distributed everywhere.

I'm what most people call a FPGA Engineer though I work all the way from boards/silicon to cloud applications. The number of times I've been asked to consult on something in the software world on performance, where the answer to how to do it write was me telling them "rm -rf $PROBLEMATIC_CODE" and then go rewrite it with a good algorithm, is way too damn high. Also, the number of times someone asked me to accelerate something on an FPGA only for me to go implement it run on a GPU in about 2-3 days using SYCL + OpenCL is insane. Sure, I could get another 2x improvement... or we can accept the 1,000x improvement I just gave you at a much lower price.

Re: It takes a PhD to develop that

#379
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'…

From the refterm README: refterm is designed to support several features, just to ensure that no shortcuts have been taken in the design of the renderer. As such, refterm supports: * Multicolor fonts * All of Unicode, including combining characters and right-to-left text like Arabic Glyphs that can take up several cells * Line wrapping * Reflowing line wrapping on terminal resize * Large scrollback buffer * VT codes…

The really hard part of writing a terminal emulator, at least from my experience working on Alacritty, is fast scrolling with fixed regions (think vim).

Plently of other parts of terminal emulators are tricky to implement performantly, ligatures are one Alacritty hasn't got yet.

Re: It takes a PhD to develop that

#380
post #163
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…

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…

I’m fairly sure noone in question wrote a new font renderer, but just rendered all available fonts upfront with a system library, and uploaded it to the GPU and let it use it as a bitmap.

Text rendering is still done mostly on the CPU side in the great majority of applications, since vector graphics are hard to do efficiently on GPUs.

Post reply on HN