4 ms·

There are fast compilers. Go is an example. Delphi was another very fast compiler. AOT compilers that are slow, are slow because they spend a lot of time optim

There are fast compilers. Go is an example. Delphi was another very fast compiler. AOT compilers that are slow, are slow because they spend a lot of time optimizing code that isn't particularly important (but they have no way to know that). A good way to see this is by taking a large-ish Java program that does the same thing as a large-ish C++ or Rust program, and comparing the compile times. The Java program will compile much faster, but runtime performance will be roughly comparable post-warmup (unless the program is very sensitive to memory locality, as Java doesn't currently have value types). The reason is that the Java -> bytecode compilation is very simple and involves almost no optimization work, and then the rest of the compile is done at runtime, but it's all profile guided so only the parts of the app that actually benefit from optimization get it.

brundolf 4y ago
> because they spend a lot of time optimizing code that isn't particularly important This is a pretty loaded and weird thing to say. You're right that optimization accounts for a major chunk of the time, but compilers are often slow while optimizing code that is important
- ender341341 4y ago
  I think they're saying that for the vast majority of code it doesn't matter to optimize as the actual time to run the code is trivial compared to waiting on network calls and the like.
  - brundolf 4y ago
    I've never seen any evidence (or even anecdotes, until now) saying this is true. It could be, who knows, but it's a weird thing to assert out of the blue in this kind of conversation, especially when just "doing optimizations [important or not] is a major contributor" is widely-accepted as true and is enough to answer the OP's question
    - layer8 4y ago
      Hotspot JIT compilers rely on that. They only compile and optimize code where significant CPU time is spent (hotspots). The majority of code usually remains unJITed.
      - brundolf 4y ago
        I guess the crux is that "important" is relative. JIT compilers (especially hot-spot optimizing ones) are most commonly used for high-level languages like JavaScript, which have a different definition of "important to performance" than eg. systems languages. The OP is talking about compilers that produce binaries, so I think the relevant definition of "important" is that of systems languages, not of the typical JITed language
        layer8 4y ago
        I was thinking of Java and C#, which are widely deployed for desktop and backend applications, as well as on mobile (Android specifically), and which are quite competitive with C for application performance.
    - mike_hearn 4y ago
      e.g. code that is only ever executed once is a large proportion of many programs (init codepaths etc), but it doesn't make much difference to spend time optimizing it.
  - Am4TIfIsER0ppos 4y ago
    What if I don't make any network calls and I also don't want to wait for `div` to complete when `shr` would do?
mikewarot 4y ago
Lazarus/Free Pascal includes its own sources, and takes about 3 minutes to rebuild everything, if I recall correctly. It's single pass recursive descent compiler, with no macros. It doesn't have separate header files, and auto-manages dependencies, so there isn't a need for make. Units get compiled once, no matter how often they are used.
AussieWog93 4y ago
>Delphi was another very fast compiler. My old manager used to love this language. Apparently back in the late 90s he was compiling serious pieces of software in a few seconds. The first demo app he compiled finished so quickly he thought something had actually gone wrong.
- layer8 4y ago
  Turbo C/Delphi/Pascal compiled so fast, and incrementally, that you could usually instantly run your program after an edit.
- rgmerk 4y ago
  We work on a Delphi application still (monolithic internal platform for a company in the financial industry). Our multi-million line main application builds in about a minute. The IDE is a buggy POS though.
User23 4y ago
> Java doesn't currently have value types It's been a while, but I don't think this is true. Java does have unboxed value types in arrays, and you can use them for decently cache efficient computation.

brundolf 4y ago

> because they spend a lot of time optimizing code that isn't particularly important This is a pretty loaded and weird thing to say. You're right that optimization accounts for a major chunk of the time, but compilers are often slow while optimizing code that is important

ender341341 4y ago
I think they're saying that for the vast majority of code it doesn't matter to optimize as the actual time to run the code is trivial compared to waiting on network calls and the like.
- brundolf 4y ago
  I've never seen any evidence (or even anecdotes, until now) saying this is true. It could be, who knows, but it's a weird thing to assert out of the blue in this kind of conversation, especially when just "doing optimizations [important or not] is a major contributor" is widely-accepted as true and is enough to answer the OP's question
  - layer8 4y ago
    Hotspot JIT compilers rely on that. They only compile and optimize code where significant CPU time is spent (hotspots). The majority of code usually remains unJITed.
    - brundolf 4y ago
      I guess the crux is that "important" is relative. JIT compilers (especially hot-spot optimizing ones) are most commonly used for high-level languages like JavaScript, which have a different definition of "important to performance" than eg. systems languages. The OP is talking about compilers that produce binaries, so I think the relevant definition of "important" is that of systems languages, not of the typical JITed language
      - layer8 4y ago
        I was thinking of Java and C#, which are widely deployed for desktop and backend applications, as well as on mobile (Android specifically), and which are quite competitive with C for application performance.
  - mike_hearn 4y ago
    e.g. code that is only ever executed once is a large proportion of many programs (init codepaths etc), but it doesn't make much difference to spend time optimizing it.
- Am4TIfIsER0ppos 4y ago
  What if I don't make any network calls and I also don't want to wait for `div` to complete when `shr` would do?

mikewarot 4y ago

Lazarus/Free Pascal includes its own sources, and takes about 3 minutes to rebuild everything, if I recall correctly. It's single pass recursive descent compiler, with no macros. It doesn't have separate header files, and auto-manages dependencies, so there isn't a need for make. Units get compiled once, no matter how often they are used.

AussieWog93 4y ago

>Delphi was another very fast compiler. My old manager used to love this language. Apparently back in the late 90s he was compiling serious pieces of software in a few seconds. The first demo app he compiled finished so quickly he thought something had actually gone wrong.

layer8 4y ago
Turbo C/Delphi/Pascal compiled so fast, and incrementally, that you could usually instantly run your program after an edit.
rgmerk 4y ago
We work on a Delphi application still (monolithic internal platform for a company in the financial industry). Our multi-million line main application builds in about a minute. The IDE is a buggy POS though.

User23 4y ago

> Java doesn't currently have value types It's been a while, but I don't think this is true. Java does have unboxed value types in arrays, and you can use them for decently cache efficient computation.