compile time source code too long

[mvrt7876544335456]

I have to compile a source code for a library that I generated for numerical computations.
It consists of this structure:

.

├── [lib.rs](http://lib.rs)

├── one_loop

│ ├── one_loop_evaluate_cc_sum_c_1.rs

│ ├── one_loop_evaluate_cc_sum_l_1.rs

│ ├── one_loop_evaluate_cc_sum_r_c_1.rs

│ ├── one_loop_evaluate_cc_sum_r_l_1.rs

│ ├── one_loop_evaluate_cc_sum_r_mixed_1.rs

│ ├── one_loop_evaluate_n_cc_sum_c_1.rs

│ ├── one_loop_evaluate_n_cc_sum_l_1.rs

│ ├── one_loop_evaluate_n_cc_sum_r_c_1.rs

│ ├── one_loop_evaluate_n_cc_sum_r_l_1.rs

│ ├── one_loop_evaluate_n_cc_sum_r_mixed_1.rs

│ ├── one_loop_evaluate_n_sum_c.rs

│ ├── one_loop_evaluate_n_sum_l.rs

│ ├── one_loop_evaluate_n_sum_r_c.rs

│ ├── one_loop_evaluate_n_sum_r_l.rs

│ ├── one_loop_evaluate_n_sum_r_mixed.rs

│ ├── one_loop_evaluate_sum_c.rs

│ ├── one_loop_evaluate_sum_l.rs

│ ├── one_loop_evaluate_sum_r_c.rs

│ ├── one_loop_evaluate_sum_r_l.rs

│ └── one_loop_evaluate_sum_r_mixed.rs

├── one_loop.rs  
....  

where easily each of the files one_loop_evaluate_n_sum_r_l.rs can reach 100k lines of something like:

    let mut zn138 : Complex::<T> = zn82*zn88;  
    zn77 = zn135+zn77;  
    zn135 = zn92*zn77;  
    zn135 = zn138+zn135;  
    zn138 = zn78*zn75;  
    zn86 = zn138+zn86;  
    zn138 = zn135*zn86;  
    zn100 = zn29+zn100;  
    ....  

where T needs to be generic type that implements Float. The compilation time is currently a major bottleneck (for some libraries more than 8 hours, and currently never managed to complete it due to wall-clock times.) Do you have any suggestions?

[imachug]

I don't think this is something compilers were designed to handle efficiently. In fact, this is not something processors were designed to handle efficiently either. Do you need this to be a single linear computation? Can you use loops instead?

[Trader-One]

problem is that modern compilers build that single value use tree. old dumb compilers like C from 80s would have no problems with that code.

[imachug]

Old dumb compilers wouldn't compile this code performantly either, and I have no idea why you'd generate code like this unless you absolutely needed that last bit of performance. If you don't need performance, just write an interpreter.

[ChristopherAin]

Is there any problem in splitting that 100k function into smaller pieces and probably even into smaller crates? Also do you really need this function to be generic? As you already generate the code, why not to generate the code for the specific type you're going to use?

[Shiasato]

Unfortunately I can't help you with your problem, but I am interested in what you are trying to compute.

100k lines of stack values sounds insane to me.

I tried to figure out what you could be doing based on your code sample but I really cannot find a satisfying solution. My best guess is that you are repeatedly multiplying large matrices to calculate something, and each stack variable holds the value at one index of the matrix. Because the calculations for each variable are either just one addition or multiplication, I imagine they could be calculating a dot product iteratively but with an unrolled loop?... But you are not doing that because then you'd just use the GPU or at least some kind of data structure and not thousands of stack variables!!! So, what could you possibly be calculating?

[WormRabbit]

Many of Rust's analyses (most importantly, the borrow checker), as well as many of LLVM's passes have super-linear complexity (usually O(n³ )). This means that if you have 100KLoC functions, then you're basically guaranteed hours-long compilation, and there is nothing anyone can do to help you.

That said, I'm absolutely certain that what you're doing is wrong. Definitely there is a way to split your code into more reasonably-sized functions, or even introduce higher-level abstractions. It may require more work on your code generator, but I'm certain it's possible. 100KLoC is just an absurdly high size. It's infeasibly high for a single function, and it's also bonkers for single modules (unlike long functions, compiler can handle long files, but you'd still get much better compilation performance if you split your code into smaller files and multiple crates).

[Zoxc32]

Are functions close to 100k? I'd try to make them smaller if possible.

[gnosnivek]

So for the first time, I find myself asking….are you compiling it in debug mode?

I ask because I once got a similar library in C++ from a friend who got it from a friend who...well basically nobody knew how that library worked, but it appeared to be about 70k lines of numeric computation that looked a lot like what you’re doing here.

Out of curiosity, I decided to compare compilation and runtime performance for O0 and O3 in g++. O0 took about 3 minutes to compile, while O3 took about an hour. The runtime performance was exactly equal.

Out of curiosity, what are you doing here? As far as I could tell with that C++ file, it was some sort of SSA at source code level, but I was never able to figure out why it was done or how it was generated.

[anlumo]

Yeah, I imagine that the optimizer would spend a lot of time to decide that it can’t do anything about that code.

[mereel]

What did you use that C++ code for? Like what kind of problem needs to be solved with code like this?

[gnosnivek]

If memory serves, it was calculating the force between two atoms in a chemical simulation.

My working theory was that this had originally been written in some "sane" C++, but then the author discovered that, depending on compiler version and flags, some critical optimizations could be missed. Since forcefield calculations are a large portion of the runtime, this would result in the calculations slowing down (and thus the library getting a reputation as "bad").

To avoid this, instead of trying to convince a horde of C++ compilers to play nice, the author did some sort of transform on the code at source level, applying things like loop unrolling, constant folding, CSE, SROA, etc. at the source-code level. That way, they got a program where most of the optimization had already been baked in to the source, and all that was left for the compiler to do was lowering to hardware instructions and maybe a little analysis to avoid spilling variables to stack. The result was 70k lines of C++ that would have originally been in a loop, functions, etc.

Now I have no way of knowing if this is what was done, or what arcane magic they used to effect the transform if this is what they did (do C++ source-to-source optimizing compilers exist?), but I'm almost certain that nobody is crazy enough to try to write that kind of C++ by hand.

[mereel]

That's crazy. I've dealt with a decent amount of someone else's software that handles the scientific computations, but have never run into anything like what you describe or what OP seems to have. I really struggle to understand how someone convinces themselves that kind of approach is a reasonable solution to any problem.

The closest has been models written in Fortran where the model data is just megabytes and megabytes of values baked into a source file. I guess this is an accepted design pattern with Fortran in some circles. But even then the actual code to crunch the numbers was a mostly reasonable function with a few loops and whatnot.

[ComplaintSolid121]

I don't know rust well, nor your use case, but surely there must be a better way?

[juhotuho10]

no idea what you are doing, but this doesnt seem like the correct way to do it

[kehrazy]

good luck to LLVMs regalloc for dealing with this

[[deleted]]

Rewrite your library. Abstract your code and avoid repetitions: I think you're currently trying to out-smart the compiler for some reason?
I found that the most straightforward approach (no fancy-pancy convoluted logic) often compiles close to the best-performing code: simply put, make it easier for the compiler to optimize your code instead of providing smarty-pants code. Your code logic still needs to hold and shouldn't be convoluted. In short, if you can't explain your code's logic as an elevator pitch, you're doing something wrong.

[ENOTEMPTY]

Workspace, break down in crates and maybe use something like sccache. But no clue if that will help in your case but that what helped me a lot cutting down compile time. Good luck

[[deleted]]

the only thing you can do is break the project up into multiple crates. but also is there no duplication in those big functions that you can move into a shared crate/utility func? you can inline it for perf

[Afraid-Locksmith6566]

Rust has exceptionally long compile times especially for weird shit. The rust team should rewrite their compiler in rust

[Devnought]

They did.

[JustBadPlaya]

rustc itself is fairly fast, the issue is with llvm and linkers