2 ms·

You’re correct that it’s possible to trigger that performance issue without Rust. However, it doesn’t happen with idiomatic C or C++ code. C macros are too har

You’re correct that it’s possible to trigger that performance issue without Rust. However, it doesn’t happen with idiomatic C or C++ code. C macros are too hard to use for that. C++ templates are designed to expand into many small functions, as opposed to a single huge one. It was Rust complexity leaking over into the LLVM IR.

jcranmer 7y ago
At the scale of macro complexity that occurred in the Rust code, you would be dealing with autogenerated C/C++ code. Autogenerated C/C++ code of that complexity absolutely exists in practice. The problem here isn't Rust's complexity; it's autogeneration taken to the extremes without concern for its impact on compile time. The fact that Rust provides builtin macro syntax to do this autogeneration is of little importance, since it will happen just as frequently with external build tools in the C/C++ world.
derefr 7y ago
> C++ templates are designed to expand into many small functions, as opposed to a single huge one. ...so are Rust macros. The user was using Rust macros very non-idiomatically. Also, you don't use C macros to write (large amounts of) C. 90% of the world's generated C, by volume, comes from, I would say, one of two programs: autoconf (through m4), or yacc. And both autoconf check stanzas and yacc's inline C support are easy to screw up in ways that result in horrible code that makes compilers barf. Also, to be clear, you're conflating two things with the phrase "Rust complexity." This thread was originally about the difficulty of implementing a Rust compiler for a toolchain, which therefore makes "Rust's complexity" here refer specifically to the complexity of the static-analysis semantics of Rust that make writing a Rust compiler frontend difficult. The solution—relying on the existing rustc frontend for the "hard stuff", and just implementing your own compiler backend to target the embedded architecture—is not rebutted by a claim that you can write bad Rust code that makes the optimization passes of certain compilers choke. You wouldn't even be writing optimization passes. You'd be writing a backend. The optimization passes are universal. It's the job of the LLVM developers to ensure that they don't choke on things like this. And, despite the fact that 100,000-line functions are dumb, it's the LLVM development team's fault that the optimization passes were written in such a way that their time-complexity is superlinear in a way that stalls out when optimizing a function like that. It's not up to the Rust compiler authors to not emit that type of code, or to somehow prevent you from writing it; it's up to the LLVM devs to make their optimizer work, and work efficiently, for any "valid" code. Honestly, if anything, this code—if you could get it—would be a great integration test to submit to LLVM, for them to work towards passing.

jcranmer 7y ago

At the scale of macro complexity that occurred in the Rust code, you would be dealing with autogenerated C/C++ code. Autogenerated C/C++ code of that complexity absolutely exists in practice. The problem here isn't Rust's complexity; it's autogeneration taken to the extremes without concern for its impact on compile time. The fact that Rust provides builtin macro syntax to do this autogeneration is of little importance, since it will happen just as frequently with external build tools in the C/C++ world.

derefr 7y ago

> C++ templates are designed to expand into many small functions, as opposed to a single huge one. ...so are Rust macros. The user was using Rust macros very non-idiomatically. Also, you don't use C macros to write (large amounts of) C. 90% of the world's generated C, by volume, comes from, I would say, one of two programs: autoconf (through m4), or yacc. And both autoconf check stanzas and yacc's inline C support are easy to screw up in ways that result in horrible code that makes compilers barf. Also, to be clear, you're conflating two things with the phrase "Rust complexity." This thread was originally about the difficulty of implementing a Rust compiler for a toolchain, which therefore makes "Rust's complexity" here refer specifically to the complexity of the static-analysis semantics of Rust that make writing a Rust compiler frontend difficult. The solution—relying on the existing rustc frontend for the "hard stuff", and just implementing your own compiler backend to target the embedded architecture—is not rebutted by a claim that you can write bad Rust code that makes the optimization passes of certain compilers choke. You wouldn't even be writing optimization passes. You'd be writing a backend. The optimization passes are universal. It's the job of the LLVM developers to ensure that they don't choke on things like this. And, despite the fact that 100,000-line functions are dumb, it's the LLVM development team's fault that the optimization passes were written in such a way that their time-complexity is superlinear in a way that stalls out when optimizing a function like that. It's not up to the Rust compiler authors to not emit that type of code, or to somehow prevent you from writing it; it's up to the LLVM devs to make their optimizer work, and work efficiently, for any "valid" code. Honestly, if anything, this code—if you could get it—would be a great integration test to submit to LLVM, for them to work towards passing.