11–20 of 69 posts
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html
That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
This is sort of off topic, but the fact that every change to the source requires (on my machine) 3-4 full seconds to recompile, without optimization, is indicative of the compiler performance problems that remain my main roadblock with Rust.
Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html
Also, the language was quite simple. With large, complex programs, the most time-consuming stage was in the linking of the final binary.
If you want a similarly fast compiler today, look at Go.
Earlier quoted context omitted.
Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html
They also didn't have the zero-cost memory safety abstractions that Rust has. Nor did they do much optimization. That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
I'm not really a fan of Go but waiting for the compiler can be a pretty significant productivity killer on larger projects. Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming language design.
Earlier quoted context omitted.
Turbo Pascal and Delphi had incredibly fast compilers. Why can't we make fast compilation a required feature today? We should never have to wait for the compiler/linker. http://prog21.dadgum.com/47.html
They also didn't have the zero-cost memory safety abstractions that Rust has. Nor did they do much optimization. That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
No, but it is was better than what C and C++ have.
> Nor did they do much optimization.
I don't use them since the late 90's, but they used to be comparable to contemporary C and C++ MS-DOS/Windows compilers.
Earlier quoted context omitted.
They also didn't have the zero-cost memory safety abstractions that Rust has. Nor did they do much optimization. That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
How optimistic are you that the compilation speed can be significantly increased? Are there a lot of easy optimizations available or is this just the price paid for extra compile time safety? I'm not really a fan of Go but waiting for the compiler can be a pretty significant productivity killer on larger projects. Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming…
The vast majority of compile time for optimized builds (80%-90%) is spent in code generation and optimization in LLVM.
For unoptimized builds, most of the compile time is spent in the typechecker doing type unifications for method lookup. With some optimizations to quickly reject method candidates I suspect this can be greatly improved.
Incremental compilation for the fast turnaround is being worked on and there has been significant progress, to address comex' complaint.
> Their fast compilation times are a pretty big selling point for what is (IMO) an otherwise underwhelming language design.
Go 6g/8g also doesn't do much optimization by comparison to GCC/LLVM. (Rust uses LLVM.)
Earlier quoted context omitted.
They also didn't have the zero-cost memory safety abstractions that Rust has. Nor did they do much optimization. That said, we're working on compilation speed. The focus so far has been getting the language in shape and runtime performance of the generated code, not compilation speed (although we've picked most of the low-hanging fruit in compilation speed anyway).
> They also didn't have the zero-cost memory safety abstractions that Rust has. No, but it is was better than what C and C++ have. > Nor did they do much optimization. I don't use them since the late 90's, but they used to be comparable to contemporary C and C++ MS-DOS/Windows compilers.
There has been an enormous difference in the quality of optimization and code generation since the 1990s, when single-pass compilers such as Turbo Pascal and Delphi were common. At that time you usually went straight from AST to machine code, doing some peephole optimizations along the way, but this is unacceptable today if you want to compete with modern C and C++ compilers (or even Java HotSpot). The introduction of SSA (and along with it GVN, SROA, SCCP, etc.) was a big deal.