5 ms·

Ugh Crystal is so beautiful and sorry to make this typical complaint but I wish the compile time was 1/10th of what it is. The dev cycle loop is just not there

Ugh Crystal is so beautiful and sorry to make this typical complaint but I wish the compile time was 1/10th of what it is. The dev cycle loop is just not there for me but the language is incredible.

trevyn 5y ago
Does Crystal benefit from these new M1 beasts? My Rust compile times became much more pleasant.
- fwip 5y ago
  LLVM implements fewer optimization passes for ARM, so it's doing less work than compiling for x86.
  - yjftsjthsd-h 5y ago
    Does that hurt performance of the output?
    - cute_boi 5y ago
      There is high probability that it can hurt runtime perf. Because less passes means less optimization (in general)
    - omaranto 5y ago
      Well, if it didn't, they could optimize the compiler by removing those optimizations. :)
      - makapuf 5y ago
        That was(is?) the benchmark for gcc optimizations: it has to pay for itself on the compiler: if the resulting compiler code is faster but the added compilation time is even greater, it s not worth it.
        KMag 5y ago
        I think I first heard of this criterion being used by Niklaus Wirth for Pascal and Oberon compilers.
      - KMag 5y ago
        I think it's pretty clear the GP was asking if the optimizations implemented for x86 that aren't implemented for aarch64 would actually improve performance of generated aarch64 code. It's a question about CPU architecture/microarchitecture. That's a different question as to if the optimizations improve performance of generated x86 code. For instance, I imagine the x86_64 register allocation does some variant on graph coloring for register allocation, with an additional pass to assign lettered registers (rax, rbx, etc.) to the most heavily used registers, since using higher numbered registers requires a REX prefix byte. In addition, many instructions have more compact encodings when eax/rax is the destination register. At a minimum, excess REX prefixes take up instruction cache space. There's no parallel for aarch64, so there's no sense in implementing logic to try and make sure the low-numbered aarch64 registers are used more. (Though, on 32-bit ARM with Thumb/Thumb2, only a subset of registers are available, so there is a similar optimization for 32-bit ARM targets that support Thumb/Thumb2 when optimizing for space.) I imagine there are better examples, but my point is that some optimizations are useless on some architectures.
        omaranto 5y ago
        > I think it's pretty clear the GP was asking if the optimizations implemented for x86 that aren't implemented for aarch64 would actually improve performance of generated aarch64 code. Oh, of course! That must be what was meant. Sorry.
- yxhuvud 5y ago
  Compile times on M1 seems to be fairly nice yes, according to those that have tested. But it is still perhaps not what one could wish it to be. So far most of the efforts in the compiler seems to be around making it correct, rather than faster.

Ugh Crystal is so beautiful and sorry to make this typical complaint but I wish the compile time was 1/10th of what it is. The dev cycle loop is just not there for me but the language is incredible.

trevyn 5y ago

Does Crystal benefit from these new M1 beasts? My Rust compile times became much more pleasant.

fwip 5y ago
LLVM implements fewer optimization passes for ARM, so it's doing less work than compiling for x86.
- yjftsjthsd-h 5y ago
  Does that hurt performance of the output?
  - cute_boi 5y ago
    There is high probability that it can hurt runtime perf. Because less passes means less optimization (in general)
  - omaranto 5y ago
    Well, if it didn't, they could optimize the compiler by removing those optimizations. :)
    - makapuf 5y ago
      That was(is?) the benchmark for gcc optimizations: it has to pay for itself on the compiler: if the resulting compiler code is faster but the added compilation time is even greater, it s not worth it.
      - KMag 5y ago
        I think I first heard of this criterion being used by Niklaus Wirth for Pascal and Oberon compilers.
    - KMag 5y ago
      I think it's pretty clear the GP was asking if the optimizations implemented for x86 that aren't implemented for aarch64 would actually improve performance of generated aarch64 code. It's a question about CPU architecture/microarchitecture. That's a different question as to if the optimizations improve performance of generated x86 code. For instance, I imagine the x86_64 register allocation does some variant on graph coloring for register allocation, with an additional pass to assign lettered registers (rax, rbx, etc.) to the most heavily used registers, since using higher numbered registers requires a REX prefix byte. In addition, many instructions have more compact encodings when eax/rax is the destination register. At a minimum, excess REX prefixes take up instruction cache space. There's no parallel for aarch64, so there's no sense in implementing logic to try and make sure the low-numbered aarch64 registers are used more. (Though, on 32-bit ARM with Thumb/Thumb2, only a subset of registers are available, so there is a similar optimization for 32-bit ARM targets that support Thumb/Thumb2 when optimizing for space.) I imagine there are better examples, but my point is that some optimizations are useless on some architectures.
      - omaranto 5y ago
        > I think it's pretty clear the GP was asking if the optimizations implemented for x86 that aren't implemented for aarch64 would actually improve performance of generated aarch64 code. Oh, of course! That must be what was meant. Sorry.
yxhuvud 5y ago
Compile times on M1 seems to be fairly nice yes, according to those that have tested. But it is still perhaps not what one could wish it to be. So far most of the efforts in the compiler seems to be around making it correct, rather than faster.