Performance

[dodu94]

Hello everyone,
first of all I would like to thank the devs for the work they did in the last month or so to promptly solve all the issues that I opened. I was finally able to successfully parse (at least without breaking) MCNP models created with our typical workflows here at Fusion For Energy.

As you may remember, my plan is to eventually substitute numjuggler with montepy as the parsing engine of F4Enix but I am afraid that until parsing performance is improved this may be out of the question. In fact, I noticed an increase of around x30 going from F4Enix (which already is a x2 increase in time with respect to numjuggler) to montepy parsing.

Even if comparing numjuggler to montepy is not fair since the latter is a much more complete and robust parser, still this means that for inputs like E-lite we would increase the parsing times from roughly 10 minutes to something like 5 hours, which is not viable. (I did not have time to test this myself, just extrapolated the times from other tests I performed on smaller models).

I would like to start this discussion to:

• understand from devs how high in the project priorities is improving performance (I guess you'd like to consolidate more first)
• understand if this improvement in performance is key only for us or also for other projects (it seems from Integrate MontePy as a backend parser for openmc_mcnp_adapter #394 that we are not the only ones)
• get opinions from the devs on which would be the best approach to tackle this issue (parallelization of the semantic parsing once the cards/inputs have been individuated? rewriting some core functions in RUST?).

Once again, thanks for all the work,
Davide

[tjlaboss]

Related: #137, #153, #382.

The parsing operations should be relatively straightforward to parallelize. MontePy is currently CPU-bound for our applications and could take advantage of multiprocessing. The more difficult and more interesting question is what makes makes the parsing so slow.

The first thing for the development team to do is #137 and figure out where the time is being spent. I've done some preliminary profiling on one of my test reactor models with a fairly complicated geometry and about 1000 depleted materials, with all their fission products and such.

Calls to sly only took about 10% of the runtime. Switching to a compiled engine for that would help a little bit. The heavy hitters were actually updating material pointers, and the make_prop_val_node / make_prop_pointer utilities. I've posted more on #137.

[MicahGale]

I'm really disappointed you are seeing ~5 hours for parsing, and that is really untenable for adoption, and really needs to be fixed prior to it being viable something on the scale of ITER. Side note: are there any public versions of the ITER model available? It would be nice if we could do some profiling of this model on our own.

• As for priorities: that's a complicated matter. Currently development has followed the principles:

  1. Make it work.
  2. Make it robust.
  3. Make it fast.

• So performance obviously hasn't been a priority in the past. What the priorities are going forward is complicated as we currently have no funding. So on the one hand we can say the priority is whatever we want, but on the other hand, being a top priority with $0 doesn't get much done still. Personally I think performance is being more of a priority, but feature development still needs to happen, especially for tally support (Draft: Implement Tallies! - [opened] #324).

• You brought up a good point. I don't think implementing Integrate MontePy as a backend parser for openmc_mcnp_adapter #394 will be tenable until performance is improved for a good value proposition, especially since openmc_mcnp_adapter seems to be mostly used by the fusion community.

• @tjlaboss has brought up good points. I think ultimately optimization needs to be data driven, and focus on low-hanging fruit. Just opining now: the least to most difficult optimizations will be:

  1. Fixing simple bottlenecks with hashing and moving from O(N) to O(1) when possible. (I think there might be a case where there might be an O(N^2) operation.
  2. parallelizing the parsing step.
  3. Switching to a compiled parsing engine (Consider alternatives to SLY long term for backend parser #432).

It sounds like you (@dodu94) are serious about pursuing MontePy for F4E. There might be some opportunities for collaboration on this development.

P.S. I'll hop over to #137 to add my 2 cents.

[MicahGale]

I started playing around with profiling and making big models with MontePy, and it is going really slowly. I think performance is a top priority for the next month at least now.