WIP: Propagation performance using AnyFieldCell

Performance of the Steppers can be increased by not using AnyFieldCell. This is based upon !366 (merged). I only tried out the change in EigenStepper and I see about 20% less runtime averaged over 10 executions.

Results:
exe                            average     stdev      min      rel
-----------------------------  -------  --------  -------  -------
build_concreteFieldCell/Int... 10.4471  0.167758  10.2536  100.00%
build_anyFieldCell/Integrat... 12.5926  0.214441  12.3577  120.54%

What do you think?

@asalzbur abstract?

changed the description

changed target branch from master to ACTS-391_Curvilinear_to_AtaPlane_vice_cersa

changed title from WIP: Resolve External Issue to WIP: Propagation performance using AnyFieldCell

I like this. Did you check with different maps ? @jhrdinka can help you here.

P.S.: the slc6 dbg unit test failure appears here now as well, before I merged the propagation updates ...

P.P.S: look into your mailbox.

@asalzbur Well this is based on your branch underlying !366 (merged) so it makes sense that the unit test failure also appears here, right?

Didn't switch out the maps yet, but I can try that out next and measure again

Right.

This makes me wish all the more that I could somehow manage to allocate some time in order to investigate the performance of the new type-erasure-heavy InterpolatedBFieldMap... Unfortunately, that's not possible for me in the medium term (say, before next year).

I dug around a bit, and compared direct Grid access to access through AnyGrid, and I was seeing about 10% performance difference. I'm currently implementing a SurfaceArray that also uses the Grid. I guess here the performance penalty is not as bad, because the lookup is not done as often.

Right now it is my understanding that we either need type erasure, or we infect the code all the way up the library user with template parameters that set up the grid.

added 1 commit

• 6d2e122e - allow running of propagation test with interpolated

Compare with previous version

I updated the branch with changes that allow the propagation test with an interpolated bfield example. The CI job fails because it does not have the ATLAS field input file. This seems to be working fine, I had to tune the tolerance for the isApprox calls a bit. I also had to manually create the field cache in Atlas and Eigen steppers, since the any field cell type can be implicitly initialized, but the concrete field cell cannot.

The performance improvement seems to be less pronounces here, I'm only seeing about 2-3%:

Results:
exe                                                                                                                         average    stdev      min  rel
------------------------------------------------------------------------------------------------------------------------  ---------  -------  -------  -------
build_int_fc_any/IntegrationTests/PropagationTests --run_test="constant_bfieldorward_propagation_" > /dev/null 2>&1         85.2387  4.92415  80.346   102.84%
build_int_fc_concrete/IntegrationTests/PropagationTests --run_test="constant_bfieldorward_propagation_" > /dev/null 2>&1    82.8848  5.63553  79.1462  100.00%

Do we abandon this for now? Especially in the "real-world" example, this does not seem like a problematic performance issue.

@asalzbur

closed