Performance
#509
Replies: 6 comments 11 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
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.
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. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I noticed that we frequently parse repetitive values in functions like |
Beta Was this translation helpful? Give feedback.
10 replies
-
|
So if you initialize them separately they will be independent. However, if you initialize the object, then change/mutate it, you still only have one object. What you are suggesting is looking like an immutable class. This wouldn't be impossible to work with, but there's a lot of extra code to store the new instance. In [1]: import montepy
In [2]: nukeA = montepy.Nuclide("1001.70c")
In [3]: nukeB = montepy.Nuclide("1001.80c")
In [4]: hex(id(nukeA))
Out[4]: '0x7f5c1cc1be30'
In [5]: hex(id(nukeB))
Out[5]: '0x7f5c1f31f8f0'
In [6]: nukeB = nukeA
In [7]: id(nukeA) == id(nukeB)
Out[7]: True
In [8]: nukeA.library = "80c"
In [9]: nukeA
Out[9]: Nuclide('H-1.80c')
In [10]: nukeB
Out[10]: Nuclide('H-1.80c')@kordusas do you want to go through the profiling data and the type of arguments that the functions take to identify memoization candidates in #675? Quick thoughts on functions that won't effectively memoize:
|
Beta Was this translation helpful? Give feedback.
-
|
yeah I can take a look. |
Beta Was this translation helpful? Give feedback.
-
|
Yes |
Beta Was this translation helpful? Give feedback.
-
|
havent really found anything else worthy to invest in (beyond |
Beta Was this translation helpful? Give feedback.
-
|
Which we can think about ways to reduce the cost of the object creation. One thing I noticed is we do a lot of |
Beta Was this translation helpful? Give feedback.
-
|
To better inform optimizations here are some of the more recent performance data. These were taken from reading+parsing > 2,000 input files from ICSBEP and IRPhE. These data are for version 0.5.3. This is from p = pstats.Stats('prof/0.5.3_combined.prof')
p.strip_dirs()
p.sort_stats(SortKey.TIME, SortKey.CUMULATIVE).print_stats(100)Results: |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Similarly here are the results for the same profiling with |
Beta Was this translation helpful? Give feedback.
-
Update on PrioritiesAfter a lot of thought these are the optimization directions we will be pursuing and their corresponding priority:
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
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:
Once again, thanks for all the work,
Davide
Beta Was this translation helpful? Give feedback.
All reactions