*Happy to pay someone to spend time investigating this The context is @peremato trying to present a Julia case for detector simulation used at e.g. CERN (the LHC) and other accelerator/medical research places: https://indico.cern.ch/event/1202075/contributions/5056320/attachments/2511955/4317921/Geo…

Hunting allocation opened 05:02PM - 19 Aug 22 UTC (UTC) [Moelf] Moelf if I run through `--track-allocation=user`, the only allocation I see is: ```ju … l…

thanks for the information, no comments is useless when we have no idea what to try next! [image] Tomas_Pevny: We then change the representation to a (Named)Tuple of vectors right, but in our case, Agent have sub-fields that is different type of Agents (because Geometry can mutually nest eac…

Then I do not know, sorry. Seems like the only solution would be to decrease variability in types, if possible.

[image] jling: the function we call inside the loop is recursive Purely anecdotal information here, but one time I wrote a recursive function, and it was slow. I rewrote the function using a while loop, and it was fast. :slight_smile: So, perhaps your real issue here is using recursion.

yeah ideally, but if you look at the code, just grep for distanceToIn and distanceToOut and inside( you will know why it’s not as simple as “just don’t use recursion”

You actually found one, :partying_face:

For an outsider reading this with curiosity about takeaways for similar problems, would you mind sharing what, if any, general solution strategy you found? I tried reading through the branch diffs in Hunting allocation · Issue #1 · peremato/Geom4hep · GitHub to follow, but I got a bit lost in the d…

For another take on this topic, see https://j-fu.github.io/marginalia/julia/unionize/

so here’s the problem: non of the examples mentioned above including yours (which looks very nice btw) have MUTUALLY recursiveness among types and the function f() if our case were like this, we’d easily just write a sumup_f_manual and re-write the whole workload as an explicit loop

It seems to me that there are a few issues with your boolean type: Nested Parametric Type Explosion: There are 8 primitive types and 11 parametric types if you include the 3 boolean types(Union, Subtraction, and Intersection). Looking at the CMS2018 file it looks like there is typically at leas…

this is great I guess @peremato has seen the Tips page but decided to implement according to the C++ design as a first draft; but yeah, we should try to fix both points

Allocation and slow down when # of types involved increase (slower than C++ virtual methods)

General Usage Performance

Topic		Replies	Views
Disabling allocations Performance	50	6124	December 10, 2020
Update on single dispatch benchmark comparison to C++ Performance cxx , benchmark	19	3210	February 13, 2021
Speed of multiple dispatch Performance	14	1317	November 27, 2023
Union splitting vs C++ Performance	22	4443	July 9, 2021
How slow is runtime dispatch, anyway? Benchmark attempts Performance	8	500	January 15, 2025

Allocation and slow down when # of types involved increase (slower than C++ virtual methods)

Related topics