5 ms·

Smaller? Yes. Faster? Almost certainly not. It really doesn't make sense to optimize anything in a bootstrapping compiler. Usually the only code that will ever

Smaller? Yes. Faster? Almost certainly not. It really doesn't make sense to optimize anything in a bootstrapping compiler. Usually the only code that will ever be compiled by this compiler will be rustc itself. And rustc doesn't need to run fast - just fast enough to recompile itself. So, the output also probably won't have any optimisations applied either.

nijaar 2y ago
if it is smaller, doesn't it mean that it has less code to execute hence should it be faster? Trying to understand better -- this is something completely new for me
- duped 2y ago
  Not necessarily, in fact one of the most important optimizations for compilers is inlining code (copy-pasting function bodies into call sites) which results in more code being generated (more space) but faster wallclock times (more speed). Most optimizations tradeoff size for speed in some way, and compilers have flags to control it (eg -Os vs -O3 tells most C compilers to optimize for size instead of speed). Where optimizing for size is optimizing for speed is when it's faster (in terms of wall clock time) for a program to compute data than to read it from memory, disk, i/o etc, because i/o bandwidth is generally much slower than execution bandwidth. That means the processor does more work, but it takes less time because it's not waiting for data to load through the cache or memory.
  - nijaar 2y ago
    great explanation. thank you!
- josephg 2y ago
  Why would a program run faster just because it’s smaller?
  - FullyFunctional 2y ago
    Example: this is a small program int main() { for(;;); }
    - josephg 2y ago
      Oh, I suppose I’m imagining two implementations that both do the same work. (Like two rust compilers). Eg, quicksort vs bubble sort. Quicksort is usually more code but faster. Or a linked list vs a btree. The linked list is less code, but the btree will be faster. Or substring search, with or without simd. The simd version will be longer and more complex, but run faster. Even in a for loop - if the compiler unrolls the loop, it takes up more code but often runs faster. If you have two programs that both do the same work, and one is short and simple, I don’t think that tells you much about which will run faster.

nijaar 2y ago

if it is smaller, doesn't it mean that it has less code to execute hence should it be faster? Trying to understand better -- this is something completely new for me

duped 2y ago
Not necessarily, in fact one of the most important optimizations for compilers is inlining code (copy-pasting function bodies into call sites) which results in more code being generated (more space) but faster wallclock times (more speed). Most optimizations tradeoff size for speed in some way, and compilers have flags to control it (eg -Os vs -O3 tells most C compilers to optimize for size instead of speed). Where optimizing for size is optimizing for speed is when it's faster (in terms of wall clock time) for a program to compute data than to read it from memory, disk, i/o etc, because i/o bandwidth is generally much slower than execution bandwidth. That means the processor does more work, but it takes less time because it's not waiting for data to load through the cache or memory.
- nijaar 2y ago
  great explanation. thank you!
josephg 2y ago
Why would a program run faster just because it’s smaller?
- FullyFunctional 2y ago
  Example: this is a small program int main() { for(;;); }
  - josephg 2y ago
    Oh, I suppose I’m imagining two implementations that both do the same work. (Like two rust compilers). Eg, quicksort vs bubble sort. Quicksort is usually more code but faster. Or a linked list vs a btree. The linked list is less code, but the btree will be faster. Or substring search, with or without simd. The simd version will be longer and more complex, but run faster. Even in a for loop - if the compiler unrolls the loop, it takes up more code but often runs faster. If you have two programs that both do the same work, and one is short and simple, I don’t think that tells you much about which will run faster.