Compilation speed makes go nice. Zig should end up being king here depending on comptime use (ie: lack of operators can be overcome by using comptime to parse formulae strings for things like geometric algebra).
Rust compiler performance
121–130 of 264 posts
Re: Rust compiler performance
#122Earlier quoted context omitted.
Macros themselves are a terrible hack to work around support for proper reflection. The entire Rust ecosystem would be reshaped in such fascinating ways if we had support for reflection. I'd love to see this happen one day.
> Macros themselves are a terrible hack to work around support for proper reflection. No, I'm not sure where you got this idea. Macros are a disjoint feature from reflection. Macros exist to let you implement DSLs and abstract over syntax.
If you look at how macros are mostly used, though, a lot of that stuff could be replaced directly with reflection. Most derive macros, for example, aren't really interested in the syntax of the type they're deriving for, they're interested in its shape, and the syntax is being used as a proxy for that. Similarly, a lot of macros get used to express relationships between types that cannot be expressed at the type system level, and are therefore expressed at a syntactic level - stuff like "this trait is derived for all tuples based on a simple pattern".
There are also proc macros just for creating DSLs, but Rust is already mostly expressive enough that you don't really need this. There are some exceptions, like sqlx, that really do embed a full, existing DSL, but these are much rarer and - I suspect - more of a novelty than a deeply foundational feature of Rust.
Re: Rust compiler performance
#123Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.
Re: Rust compiler performance
#124Earlier quoted context omitted.
This is an oversimplification. Automatic polymorphization is blocked on several concerns, e.g. dyn safety (and redesigning the language to make it possible to paper over the difference between dyn and non-dyn safe traits imposes costs on the static use case), and/or obscure LLVM implementation deficiencies (which was the blocker for the last time I proposed a Swift-style ABI to address this). Procedural macros don't…
AIUI, "Swift-style" ABI mechanisms are heavily dependent on alloca (dynamically-sized allocations on the stack) which the Rust devs have just proposed backing out of a RFC for (i.e. give up on it as an approved feature for upcoming versions of Rust) because it's too complex to implement, even with existing LLVM support for it.
Indeed, an alloca-heavy ABI was what I proposed, and I'm aware that the Rust devs have backed away from unsized locals, but these are unrelated. I was never totally clear on the specific LLVM-related problem with the former (it can't be totally insurmountable, because Swift), but people more knowledgeable in LLVM than I seemed uneasy about the prospect. As for the latter, it's because the precise semantics of unsized locals are undetermined, and it's not clear how to specify them soundly (which carries a lot of weight coming from Ralf Jung).
Re: Rust compiler performance
#125Earlier quoted context omitted.
> Macros themselves are a terrible hack to work around support for proper reflection. No, I'm not sure where you got this idea. Macros are a disjoint feature from reflection. Macros exist to let you implement DSLs and abstract over syntax.
If you look at how macros are mostly used, though, a lot of that stuff could be replaced directly with reflection. Most derive macros, for example, aren't really interested in the syntax of the type they're deriving for, they're interested in its shape, and the syntax is being used as a proxy for that. Similarly, a lot of macros get used to express relationships between types that cannot be expressed at the type syst…
I'm not intending to say that reflection is useless, but rather to say that judging macros harshly due to not being reflection would be incorrect.
Re: Rust compiler performance
#126Earlier quoted context omitted.
AIUI, "Swift-style" ABI mechanisms are heavily dependent on alloca (dynamically-sized allocations on the stack) which the Rust devs have just proposed backing out of a RFC for (i.e. give up on it as an approved feature for upcoming versions of Rust) because it's too complex to implement, even with existing LLVM support for it.
Indeed, an alloca-heavy ABI was what I proposed, and I'm aware that the Rust devs have backed away from unsized locals, but these are unrelated. I was never totally clear on the specific LLVM-related problem with the former (it can't be totally insurmountable, because Swift), but people more knowledgeable in LLVM than I seemed uneasy about the prospect. As for the latter, it's because the precise semantics of unsized…
Why does it have to be soundly specified though? Why not just provide an unsafe feature that works the same as existing C/LLVM, and "leave no room for a lower-level language"?
The safe featureset around it can always come later if the issues around how to specify it are worked out.
Re: Rust compiler performance
#127> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it. This is an unfort…
I was working on a zig project recently that uses some complex comptime type construction. I had bumped to the latest dev version from 0.13, and I couldn't believe how much improvement there has been in this area. I am very appreciative of really fast iteration cycles.
Re: Rust compiler performance
#128Earlier quoted context omitted.
Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).
I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust
I think you're missing the point of my comparison. Rust has a lot more going on than Go, so it feels unfair.
Re: Rust compiler performance
#129Earlier quoted context omitted.
> Why can't Cargo have a system like PyPI where library author uploads compiled binary Unless you have perfect reproducible builds, this is a security nightmare. Source code can be reviewed (and there are even projects to share databases of already reviewed Rust crates; IIRC, both Mozilla and Google have public repositories with their lists), but it's much harder to review a binary, unless you can reproducibly recrea…
I don’t think it’s that much of a security nightmare: the basic trust assumption that people make about the packaging ecosystem (that they trust their upstreams) remains the same whether they pull source or binaries. I think the bigger issues are probably stability and size: no stable ABI combined with Rust’s current release cadence means that every package would essentially need to be rebuilt every six weeks. That’s…
> remains the same whether they pull source or binaries.
I don't think that's exactly true, it's definitely _easier_ to sneak something into a binary without people noticing than it is to sneak it into rust source, but there hasn't been an underhanded rust competition for a while so I guess it's hard to be objective about that.
Re: Rust compiler performance
#130>[...] this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times Yeah pretty much. C++ is a lot worse when you consider the practical time spent vs compilation benchmarks. In most C++ projects I've seen/worked on, there were one or sometimes more code generators in the toolchain which slowed things down a lot. And it looks…
>And it looks even more dire when you want to add clang-tidy in the mix. It can take like 5 solid minutes to lint even small projects.
And running all tests with sanitizers, just to get some runtime checks of what Rust excludes at compile time.
I love Rust for the fast compile times.