Opened 7 years ago
Last modified 3 years ago
#4601 new defect
C-code compilation times are too large for models with many state variables
| Reported by: | Francesco Casella | Owned by: | Martin Sjölund |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | Code Generation | Version: | |
| Keywords: | Cc: |
Description
The ScalableTestSuite contains several models with a moderately high number of state variables (up to 25600, as of today) and a very simple structure, such as a cascade connection of first order systems:
- CascadedFirstOrder
- SimpleAdvection
- AdvectionReaction
The C compilation times shown in the latest Hudson report show both good and bad news.
The good news is that at least the C compilation time scales linearly. The bad news is that, depending on the specific test case, the C compilation takes between 5 and 12 ms for each state variable. This means that a model with 50.000 state variables, which I think should be perfectly reasonable, would take between 4 and 10 minutes to compile the C sources.
It is true that C source splitting and parallel compilation can help a lot, but yet 10 ms is an awful lot of time for a modern 4 GHz processor. I wonder if such a time is really necessary for each state variable, if the expression of the corresponding derivative is something as simple as 1/T*(x[i-1]-x[i]).
Could we try to streamline the generated code to reduce this substantially, without too much effort?
Change History (8)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Note: The problem holds also for non-state variables but those tend to be optimized away more frequently.
comment:3 by , 7 years ago
Optimization of repetitive structures is of course an option if you do have such structures.
What I am a bit worried about is what would happen if you had unstructured (or much less structured) models with the same number of states. Even though we do not have such examples in the ScalableTestSuite, I would assume that they take at least as much time as it takes for these non-optimized "big single array" models. For a large building model, 10000 or 20000 states is not such an outlandish proposition.
If we could just slash the time by a factor two or three by generating a somewhat cleverer C code, that would already be great.
comment:5 by , 5 years ago
| Milestone: | 1.14.0 → 1.16.0 |
|---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0
comment:7 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
I think it would require some effort. If we had flattened the SimCode one additional step to know the indexes of each variable it would be a little easier. Basically what you would need to do is recognise the repetitive pattern and collapse the equations into a for-loop...
Perhaps we could have a backend module at the very end of compilation that did this collapsing and have a comparison function for expressions that ignored constant subscripts to collect the expressions.
Would it be OK to just translate this to an algorithm block?