5 ms·

Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of pars

Unicode validation runs at gigabytes per second. Text rendering is a tiny, tiny subset of game rendering. Not sure about highlighting, sounds like a mix of parsing and game rendering, so that's likely again to be one process that can run at gigabytes per second and another process that is a tiny subset of a process that often runs at 240Hz these days. Autocomplete, no clue, probably this could also be fast? You're like doing a lookup into an inverted index or a hash table or a range tree or something? So it takes like less than 3 microseconds to decide what the contents of the box should be? Oh, it doesn't, because you decided the way this should work is that several different processes should communicate with each other using JSON-RPC just to figure out what goes in the autocomplete box? Yeah, okay, sounds like a problem with the design then. Notably World of Warcraft does not send json over sockets between multiple local processes to decide how wide the nonempty part of each mob's health bar should be every single frame, and maybe one day we could try to figure out whether there's a reason for that.

Ygg2 4y ago
>Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.
- anonymoushn 4y ago
  > Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. I've been writing this sort of parser lately and I don't think people's fear of this stuff is at all proportional to the actual level of difficulty. Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0]. If you didn't use an off-the-shelf implementation, you would need 2 implementations of your inner loops to you target ~all x86 machines + M1 macs or 3 if want to go slightly faster on the vast majority of x86 machines that have AVX2 without dropping support for those x86 machines that have a bunch of SSE extensions but not AVX2. > Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. I'm arguing that IPC is suboptimal for use cases that do not need IPC. > Even text editors that forgo LSP have speed issues, unrelated to JSON. I'm arguing that this is probably not due to the essential complexity of text editors. As an unrelated toy example of the sort of thing that I'm talking about, recently I'm playing a game in which people implement somewhat fast wordcounts[1]. The reference solution uses std::iostream to put space-delimited strings into a std::unordered_map, then gets them all out into a std::vector and std::sorts them. This implementation works at about 33MB/s for large inputs. It's generally a lot more efficient than the sort of code you'd commonly find in a larger code base just because libstdc++ isn't as slow lots of other things and it uses vaguely correct data structures and algorithms. It seems like someone who never looks at any assembly listings and never uses a profiler but sort of has some vague idea of what data oriented design is could easily come up with a solution that processes large inputs at 200MB/s even if they are paying some minor overhead for the JVM, the CLR, the Go runtime, or something like that. [0]: https://github.com/cyb70289/utf8 https://github.com/cyb70289/utf8 [1]: https://easyperf.net/blog/2022/05/28/Performance-analysis-and-tuning-contest-6 https://easyperf.net/blog/2022/05/28/Performance-analysis-an...
  - Ygg2 4y ago
    > Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0] Problems with that: - You still need a fallback and to deal with different archs. - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. > I'm arguing that this is probably not due to the essential complexity of text editors. Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity.
    - anonymoushn 4y ago
      > - You still need a fallback and to deal with different archs. Yes. That's 2->3 implementations or 3->4 implementations to target everything instead of only SSE and NEON or only SSE, AVX2, and NEON. But one of them can be the implementation you already had. > - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. I agree, but as I said above I think the level of difficulty is a lot lower than people expect. > - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. This is a common misconception which I think is better addressed by Daniel Lamire here: https://github.com/rust-lang/rust/issues/68455#issuecomment-658352503 https://github.com/rust-lang/rust/issues/68455#issuecomment-... > - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. I don't think so, because games don't usually use GPGPU. They usually do all of their layout stuff and game logic including lots of matrix math on the CPU and use the GPU for deciding what colors pixels ought to be. This is something a text editor has to use a GPU for too, even if the dev doesn't end up knowing about it. > Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity. I posted about whether they are slow due to the essential complexity of the things ultimately being computed and used for text editor features or for some other reason.
      - 4y ago

Ygg2 4y ago

>Code validation runs at gigabytes per second. You sure about that? I remember UTF8 validation being a major source of slowdown when parsing XML in Rust. Branches kill CPU perf. And UTF8 has branch on every non ASCII char. Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. Even text editors that forgo LSP have speed issues, unrelated to JSON.

anonymoushn 4y ago
> Nvm. Those methods use SIMD tricks, which while neat are hard to generalize. I've been writing this sort of parser lately and I don't think people's fear of this stuff is at all proportional to the actual level of difficulty. Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0]. If you didn't use an off-the-shelf implementation, you would need 2 implementations of your inner loops to you target ~all x86 machines + M1 macs or 3 if want to go slightly faster on the vast majority of x86 machines that have AVX2 without dropping support for those x86 machines that have a bunch of SSE extensions but not AVX2. > Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON. I'm arguing that IPC is suboptimal for use cases that do not need IPC. > Even text editors that forgo LSP have speed issues, unrelated to JSON. I'm arguing that this is probably not due to the essential complexity of text editors. As an unrelated toy example of the sort of thing that I'm talking about, recently I'm playing a game in which people implement somewhat fast wordcounts[1]. The reference solution uses std::iostream to put space-delimited strings into a std::unordered_map, then gets them all out into a std::vector and std::sorts them. This implementation works at about 33MB/s for large inputs. It's generally a lot more efficient than the sort of code you'd commonly find in a larger code base just because libstdc++ isn't as slow lots of other things and it uses vaguely correct data structures and algorithms. It seems like someone who never looks at any assembly listings and never uses a profiler but sort of has some vague idea of what data oriented design is could easily come up with a solution that processes large inputs at 200MB/s even if they are paying some minor overhead for the JVM, the CLR, the Go runtime, or something like that. [0]: https://github.com/cyb70289/utf8 https://github.com/cyb70289/utf8 [1]: https://easyperf.net/blog/2022/05/28/Performance-analysis-and-tuning-contest-6 https://easyperf.net/blog/2022/05/28/Performance-analysis-an...
- Ygg2 4y ago
  > Looks like you can use this sort of technique on ~every CPU someone might plausibly be using as a laptop to write code on[0] Problems with that: - You still need a fallback and to deal with different archs. - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. > I'm arguing that this is probably not due to the essential complexity of text editors. Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity.
  - anonymoushn 4y ago
    > - You still need a fallback and to deal with different archs. Yes. That's 2->3 implementations or 3->4 implementations to target everything instead of only SSE and NEON or only SSE, AVX2, and NEON. But one of them can be the implementation you already had. > - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD. I agree, but as I said above I think the level of difficulty is a lot lower than people expect. > - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands. This is a common misconception which I think is better addressed by Daniel Lamire here: https://github.com/rust-lang/rust/issues/68455#issuecomment-658352503 https://github.com/rust-lang/rust/issues/68455#issuecomment-... > - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again. I don't think so, because games don't usually use GPGPU. They usually do all of their layout stuff and game logic including lots of matrix math on the CPU and use the GPU for deciding what colors pixels ought to be. This is something a text editor has to use a GPU for too, even if the dev doesn't end up knowing about it. > Today's code editors are less text editors and more databases of ASTs. They very much are complex by necessity. I posted about whether they are slow due to the essential complexity of the things ultimately being computed and used for text editor features or for some other reason.
    - 4y ago