8 ms·

Looking at this, I’m reminded of early clang, which was often 5 or more times faster at compiling C++ than gcc, while handling maybe 95% of C++ code. While cla

Looking at this, I’m reminded of early clang, which was often 5 or more times faster at compiling C++ than gcc, while handling maybe 95% of C++ code. While clang is still in my experience faster than gcc, it turns out handling that last 5% correctly can knock a lot off your performance. Of course with terminals it might turn out you don’t need that last 5%, or you really can get all the way and keep the speed, but this isn’t the first project dedicated to making “the fastest terminal”.

jchw 3y ago
The way I see it, modern terminal emulators are kind of like multimedia applications, they've got a frame budget. Today a lot of them don't necessarily spend that budget wisely. I think there is a legitimate point here. Compilers could be faster, but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. In my opinion, not so for terminals: I'm pretty sure you could analyze the amount of time spent rendering in a terminal emulator and come to the conclusion that a lot of it is essentially wasted, with exception of a few more modern terminal emulators that considered this more deeply. This is in part due to the nature of the outputs of terminal emulators vs compilers; like for high throughput, it would be good if the terminal emulator spent as little time as possible processing things that won't ever actually make it to a frame. Compilers are mostly not interactive though, and don't have the luxury of deciding to simply not do something because nobody is looking.
- db48x 3y ago
  > but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html> All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
  - jchw 3y ago
    Yeah, I was talking about C++ specifically. I am extremely skeptical you can get that much better for C++ without sacrificing performance, correctness, etc. Rust is different. It has a completely different design for translation units and modules that C++ can't adopt without hard breaking changes, due to e.g. the way its macro system works. There are teams at all of Google, Microsoft, et al that spend time on C++ build performance. At this point, it's not even necessarily just about faster build times. Their builds could be measured in environmental impact at that scale.
    - thechao 3y ago
      I feel like there's room for C++ without headers or includes — a completely clean break.
      - db48x 3y ago
        That would be pretty interesting. Not quite as interesting as programming in Rust though :)
      - geertj 3y ago
        That’s what C++20 modules are designed for?
    - johntb86 3y ago
      Mold is substantially faster than other linkers [0], so that's evidence there's still room for improvement in the C++ compiler space. It does help that there are a lot of linker features that are only used in special environments (like bare-metal systems). [0]: https://www.gem5.org/project/2023/02/16/benchmarking-linkers.html https://www.gem5.org/project/2023/02/16/benchmarking-linkers...
      - jchw 3y ago
        Mold really is a big improvement, I'll give you that. (I'm a big fan of mold, to the point where I happily joined the Github Sponsors when it went more open recently.) But, the compilation stage is a tough nut to crack.
kzrdude 3y ago
Is it handling the 5% correctly or is it just a lot more optimization passes that make the difference?
- _a_a_a_ 3y ago
  That's a good question. I'd personally go with the last 1/2 of your sentence.
- ndesaulniers 3y ago
  I've spent a lot of time profiling clang when compiling the Linux kernel. For large C codebases, compile time is dominated by lexing and parsing, not optimization passes. Headers have become too crufty; they tend to only grow over time, resulting in an amplification attack on the lexer and parser. Lazy parsing is maybe interesting. There's a hazard related to the mangling of lambdas. Carbon has an interesting idea of not constructing an AST. I think we also need tools to help us automate header refactoring.
  - kzrdude 3y ago
    That's a surprise to me. That must be one epic mass of header files. It reminds me of the massive Fast kernel headers patchset by Ingo Molnar. I hope it got in. I don't know anything about it, just marvelled at the scope of it.
    - ndesaulniers 3y ago
      The profiler frequently surprises. Imagine 30 years of headers. They tend to grow and grow and become a tangled mess. Ingo's patch set did not. I asked what was being done to automate this so that we wouldn't backslide. I received no response. That said, I think that work is fascinating. I have an intern starting Monday that's going to start research into automating this.
audidude 3y ago
Author of the code in question here ... Not sure how this got off terminals and on to compilers, but here we are. Having written the profiler I used to optimize this (Sysprof), and a large portion of the OpenGL renderer that GTK uses, I know a thing or two about what code runs in the hot path from VTE. So I could target something that does enough of that to see what should be possible as a best case / upper bound. That's why I'm fairly confident that adding the rest of the features that VTE has (which is one of the most comprehensive terminal emulator code bases out there) wouldn't affect this particular test case. That said, I have no interest in doing that. I'd rather just go make VTE fast at drawing and call it a day. I have literally dozens of other projects in GNOME that require my time.
- CJefferson 3y ago
  Hi! I hope you are right, and also someone else will pick this up -- I've just seen an awful lot of projects over the years that provide a huge speedup for 90-95% of the functionality of other products, and very few manage to keep the speedup once they hit full functionality.
  - audidude 3y ago
    I really doesn't matter to be honest, because this was just to inform the theoretical upper bounds as part of my work to make VTE faster.

jchw 3y ago

The way I see it, modern terminal emulators are kind of like multimedia applications, they've got a frame budget. Today a lot of them don't necessarily spend that budget wisely. I think there is a legitimate point here. Compilers could be faster, but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. In my opinion, not so for terminals: I'm pretty sure you could analyze the amount of time spent rendering in a terminal emulator and come to the conclusion that a lot of it is essentially wasted, with exception of a few more modern terminal emulators that considered this more deeply. This is in part due to the nature of the outputs of terminal emulators vs compilers; like for high throughput, it would be good if the terminal emulator spent as little time as possible processing things that won't ever actually make it to a frame. Compilers are mostly not interactive though, and don't have the luxury of deciding to simply not do something because nobody is looking.

db48x 3y ago
> but at this point they've become optimal enough that a lot of the improvements would be trade-offs for something else. I don’t think that there’s any evidence that this is true. In fact, the performance of the Rust compiler has continually improved over the last five years while _adding_ new features, and not by removing anything. <https://perf.rust-lang.org/dashboard.html https://perf.rust-lang.org/dashboard.html> All a C++ compiler needs to do to get similar results is to have a team that does nothing but performance work, and is actually rewarded for it.
- jchw 3y ago
  Yeah, I was talking about C++ specifically. I am extremely skeptical you can get that much better for C++ without sacrificing performance, correctness, etc. Rust is different. It has a completely different design for translation units and modules that C++ can't adopt without hard breaking changes, due to e.g. the way its macro system works. There are teams at all of Google, Microsoft, et al that spend time on C++ build performance. At this point, it's not even necessarily just about faster build times. Their builds could be measured in environmental impact at that scale.
  - thechao 3y ago
    I feel like there's room for C++ without headers or includes — a completely clean break.
    - db48x 3y ago
      That would be pretty interesting. Not quite as interesting as programming in Rust though :)
    - geertj 3y ago
      That’s what C++20 modules are designed for?
  - johntb86 3y ago
    Mold is substantially faster than other linkers [0], so that's evidence there's still room for improvement in the C++ compiler space. It does help that there are a lot of linker features that are only used in special environments (like bare-metal systems). [0]: https://www.gem5.org/project/2023/02/16/benchmarking-linkers.html https://www.gem5.org/project/2023/02/16/benchmarking-linkers...
    - jchw 3y ago
      Mold really is a big improvement, I'll give you that. (I'm a big fan of mold, to the point where I happily joined the Github Sponsors when it went more open recently.) But, the compilation stage is a tough nut to crack.

kzrdude 3y ago

Is it handling the 5% correctly or is it just a lot more optimization passes that make the difference?

_a_a_a_ 3y ago
That's a good question. I'd personally go with the last 1/2 of your sentence.
ndesaulniers 3y ago
I've spent a lot of time profiling clang when compiling the Linux kernel. For large C codebases, compile time is dominated by lexing and parsing, not optimization passes. Headers have become too crufty; they tend to only grow over time, resulting in an amplification attack on the lexer and parser. Lazy parsing is maybe interesting. There's a hazard related to the mangling of lambdas. Carbon has an interesting idea of not constructing an AST. I think we also need tools to help us automate header refactoring.
- kzrdude 3y ago
  That's a surprise to me. That must be one epic mass of header files. It reminds me of the massive Fast kernel headers patchset by Ingo Molnar. I hope it got in. I don't know anything about it, just marvelled at the scope of it.
  - ndesaulniers 3y ago
    The profiler frequently surprises. Imagine 30 years of headers. They tend to grow and grow and become a tangled mess. Ingo's patch set did not. I asked what was being done to automate this so that we wouldn't backslide. I received no response. That said, I think that work is fascinating. I have an intern starting Monday that's going to start research into automating this.

audidude 3y ago

Author of the code in question here ... Not sure how this got off terminals and on to compilers, but here we are. Having written the profiler I used to optimize this (Sysprof), and a large portion of the OpenGL renderer that GTK uses, I know a thing or two about what code runs in the hot path from VTE. So I could target something that does enough of that to see what should be possible as a best case / upper bound. That's why I'm fairly confident that adding the rest of the features that VTE has (which is one of the most comprehensive terminal emulator code bases out there) wouldn't affect this particular test case. That said, I have no interest in doing that. I'd rather just go make VTE fast at drawing and call it a day. I have literally dozens of other projects in GNOME that require my time.

CJefferson 3y ago
Hi! I hope you are right, and also someone else will pick this up -- I've just seen an awful lot of projects over the years that provide a huge speedup for 90-95% of the functionality of other products, and very few manage to keep the speedup once they hit full functionality.
- audidude 3y ago
  I really doesn't matter to be honest, because this was just to inform the theoretical upper bounds as part of my work to make VTE faster.