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

Xi-Editor Retrospective

raphlinus.github.io

Post reply on HN
Print view View original

151–160 of 162 posts

Re: Xi-Editor Retrospective

#151

Post by hyperion2010 »

> Looking back, I see much of the promise of modular software as addressing goals related to project management, not technical excellence.

I couldn't find this point discussed elsewhere in the comments. I think this is one of the most important sentences in the whole article. I know this is essentially just another perspective on Conway's law, but I think it is important to identify factors like this early in a project if at all possible so that human factors around development can be factored out of engineering decisions.

I think that this is especially critical for open projects that want to achieve long term sustainability. Open communities don't have the resources to maintain all the packages, even if they use the same build system and follow the same pattern, even if most of the maintenance can be automated, some human being still has to deal each of those systems separately because they are part of the environment surrounding that individual part of the project.

Re: Xi-Editor Retrospective

#152

Post by ARussell »

blub wrote: post #22

Am I the only one on HN which thought this was a bad idea all around from the beginning? I remember that people were very enthusiastic back then because of the Rust hype and the author's pedigree, so critics were quickly silenced. For me, picking Rust and the JSON-based IPC were huge red flags and this post-mortem confirms that. But what I find odd is that many are still not willing to accept the conclusion that usin…

No, you're not. But I'd not say something beforehand, because there's nothing wrong with such a project succeeding if that's what ended up happening. Being able to say "I told you so" isn't worth it.

Although I personally think Rust is fine. It's just that I thought the frontend and backend split is too complex. I am looking for something simpler than neovim, personally, and xi didn't tick that box for me.

Re: Xi-Editor Retrospective

#153

Post by Myrmornis »

Myrmornis wrote: post #143
fluffything wrote: post #137

Earlier quoted context omitted.

> 2d rendering used to be hella fast without the gpu. Right? Define Hella fast. If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff. The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to r…

> there is no system today where you press a key and that key appears on your screen in less than 8ms. Xi achieves ~16ms on the right platforms How does one measure this? Say for the text editor I'm using (Emacs) or for Chrome/Google Docs?

Looks like this post is relevant: https://thume.ca/2020/05/20/making-a-latency-tester/

Re: Xi-Editor Retrospective

#154

Post by archagon »

Thank you for these fantastically in-depth and introspective blog posts! It’s a pleasure to observe how a single, experimental project can spawn a dozen different research branches, and it’s something to aspire to in my own work. (I have probably missed many such opportunities due to laziness and lack of curiosity.)

Re: Xi-Editor Retrospective

#155

Post by raphlinus »

archagon wrote: post #154

Thank you for these fantastically in-depth and introspective blog posts! It’s a pleasure to observe how a single, experimental project can spawn a dozen different research branches, and it’s something to aspire to in my own work. (I have probably missed many such opportunities due to laziness and lack of curiosity.)

Glad you enjoy them! I certainly plan to continue writing.

Re: Xi-Editor Retrospective

#156

Post by kllrnohj »

taeric wrote: post #145
raphlinus wrote: post #105

Earlier quoted context omitted.

Very likely, the specific thing you're experiencing is poorly-engineered switching between integrated and discrete GPUs. It's not a mac-only problem, see this thread for a somewhat horrifying story (follow last link): https://www.reddit.com/r/gigabyte/comments/91ld3o/aero_15x_d... A good intro to layout transitions is: https://www.gamasutra.com/blogs/EgorYusov/20181211/332596/Ta... The number of copies required to ge…

This all makes sense. But I would have imagined my machine can perform several hundred copies in the time it used to take to do one. Haven't memory speeds progressed a fair bit? Such that I agree it would be better to do dirty tracking and sending just a small update to the screen. But the tricks to do that should be a lot easier than they used to be. The gpu thing in my Mac is amusing just because if I run intellij,…

> Haven't memory speeds progressed a fair bit?

Not really, no. Over the last 15 years CPU memory bandwidth has increased around ~10x. Meanwhile monitor resolutions have also increased around ~10x. Meaning per-pixel CPU bandwidth has been flat over the years or even regressing a little bit. Laptops have become more common yet they also lag on memory speeds, or sometimes are even just single channel. Yet they also tend to have the highest resolution displays, not a great mix if you're trying to make CPU rendering still be viable.

As for your Mac issues I think you just have a broken computer. Software shouldn't be designed with the expectation that it'll be used on broken systems, that's not a realistic design constraint.

Re: Xi-Editor Retrospective

#157

Post by taeric »

kllrnohj wrote: post #156
taeric wrote: post #145

Earlier quoted context omitted.

This all makes sense. But I would have imagined my machine can perform several hundred copies in the time it used to take to do one. Haven't memory speeds progressed a fair bit? Such that I agree it would be better to do dirty tracking and sending just a small update to the screen. But the tricks to do that should be a lot easier than they used to be. The gpu thing in my Mac is amusing just because if I run intellij,…

> Haven't memory speeds progressed a fair bit? Not really, no. Over the last 15 years CPU memory bandwidth has increased around ~10x. Meanwhile monitor resolutions have also increased around ~10x. Meaning per-pixel CPU bandwidth has been flat over the years or even regressing a little bit. Laptops have become more common yet they also lag on memory speeds, or sometimes are even just single channel. Yet they also tend…

Agreed on my computer being broken. Only brought it up as evidence that not all apps are using the gpu. (And even then, I am not positive that is right.)

Re: Xi-Editor Retrospective

#158

Post by fluffything »

taeric wrote: post #142
fluffything wrote: post #137

Earlier quoted context omitted.

> 2d rendering used to be hella fast without the gpu. Right? Define Hella fast. If you want 16ms text rendering (~60 Hz) you pretty much need a GPU today. If you want 8ms (120Hz) text rendering, there is just no CPU that can handle it today with an OS running next to your text editor doing other stuff. The whole point of Xi was being able to edit huge files (Tb size) on 8k displays at over 120 Hz, and being able to r…

Do you have good benchmarks going over this? Still feels ridiculous. I have a multi core machine running at speeds well above my comprehension and you are saying they can't render simple 2d primitives at speed? That just blows my mind. What are they spending the time on? I get that rendering a full display from scratch could be slow. But updating a single key press should not be. Scrolling? Sure. I guess. But even th…

https://thume.ca/2020/05/20/making-a-latency-tester/

> I have a multi core machine running at speeds well above my comprehension and you are saying they can't render simple 2d primitives at speed? That just blows my mind. What are they spending the time on?

Moving memory from RAM to the CPU, doing stuff in the CPU, moving the results back to RAM, moving those results from RAM to the GPU, etc.

The CPU is fast, but moving memory around is not, so the CPU and the GPU just end up doing nothing most of the time, waiting for memory most of the time.

---

Raph's blog (linked at the top), has a bunch of articles about rendering latency. But just google about typing latency, there are a couple of projects and tools that measure the time between a physical keystroke is pressed, and the letter being rendered on the screen (end-to-end). Beyond the memory copies, what usually happens is also: an interrupt is triggered on the CPU, the kernel might take some time to context switch to catch it, context switching requires saving all registers, and restoring them, and registers have exploded in size over time (e.g. with AVX-512 you need to save quite a bit of memory), then the kernel notifies the application, which needs to do something with the key press, like scheduling a render into a frame buffer, etc.

So there are just quite a bit of bounces from here to there in the system, most of which deal with memory latencies, and memory latencies is the part of the system that hasn't been getting much faster over the last 30 years.

Re: Xi-Editor Retrospective

#159

Post by pjmlp »

saagarjha wrote: post #119
raphlinus wrote: post #81

Earlier quoted context omitted.

Yes. In this discussion and on Reddit, people still talk about binary vs textual as the source of the problem, but I've argued (based on empirical data) that the lexical details are not the reason for the performance problems. Also, Swift is marketed as a fast language (also based on LLVM), yet in my measurements it's 20x to 50x slower than Rust for JSON processing. I found that surprising. Would you not?

Swift’s slowness is kind of unfortunate, although I hear that there is work being gone to remove a lot of the lifetime cruft that was going in behind the scenes to make it slow. And unfortunately I think the primary motivation for Swift’s performance is driven by its primary application, which is UI development, so “good enough” performance usually works…

WWDC has a couple of talks regarding runtime improvements, and low level coding including unsafe style coding with Swift.

Re: Xi-Editor Retrospective

#160

Post by blub »

kllrnohj wrote: post #63
blub wrote: post #22

Am I the only one on HN which thought this was a bad idea all around from the beginning? I remember that people were very enthusiastic back then because of the Rust hype and the author's pedigree, so critics were quickly silenced. For me, picking Rust and the JSON-based IPC were huge red flags and this post-mortem confirms that. But what I find odd is that many are still not willing to accept the conclusion that usin…

> For me, picking Rust and the JSON-based IPC were huge red flags and this post-mortem confirms that. But what I find odd is that many are still not willing to accept the conclusion that using Rust for a UI-intensive app is a bad idea. This postmortem says Rust was, and still is, a great fit for the problem domain for which it was used. Where do you reach the conclusion that Rust is bad for UI-intensive apps? That cl…

How does the claim that it's a great fit reconcile with the fact that the project which was supposed to prove the said great fit was shut down? In the end real world is the only yardstick by which projects can be reasonably measured.

However if we want to remain positive, we could say like Edison that this project did not fail and is merely attempt 1 of 10000 at learning how not to build UI apps with Rust. :)

> Where do you reach the conclusion that Rust is bad for UI-intensive apps? I've reached that conclusion by applying logic and looking at the state of Rust and its capabilities as a language and the scarcity of UI apps built in Rust.

Post reply on HN