That's interesting. Seems like it was more about inlining than branch prediction. Surprising how much difference it made.
On Tuesday, January 5, 2021 at 6:18:38 PM UTC-5 Timo Heister wrote: > What I forgot to say: > We used to have something like > > if (use_anisotropic_viscosity==true) > cell(i,j) += viscosity_tensor * .... > else > cell(i,j) += viscosity_constant * .... > > and improved the performance by making two separate assemblers (note > that there is no function call/vtable lookup here, just an "if"). I > don't remember how big the difference was, so I went back and found > the PR: > https://github.com/geodynamics/aspect/pull/2139 > Rene claims 25% fewer instructions. > > > > On Tue, Jan 5, 2021 at 4:48 PM blais...@gmail.com <blais...@gmail.com> > wrote: > > > > Hi Timo, > > > > I understand. It makes a lot of sense. > > Thanks! > > Bruno > > > > On Tuesday, January 5, 2021 at 4:34:19 p.m. UTC-5 Timo Heister wrote: > >> > >> Hi Bruno, > >> > >> We mitigate the performance problem by making the decision per cell in > ASPECT: > >> We have a set of "assemblers" that are executed one after each other > >> per cell. This means the vtable access cost is small compared to the > >> actual work. > >> See > >> > https://github.com/geodynamics/aspect/blob/b9add5f53172aac18bdbb19d14ca266e88c491dd/include/aspect/simulator/assemblers/interface.h#L493-L515 > >> > >> On Tue, Jan 5, 2021 at 4:28 PM blais...@gmail.com <blais...@gmail.com> > wrote: > >> > > >> > Bruno, > >> > > >> > Thanks, you are right. As always, measure first and then optimize > after. No point in optimising stuff that costs nothing... > >> > > >> > > >> > On Tuesday, January 5, 2021 at 3:15:06 p.m. UTC-5 > bruno.t...@gmail.com wrote: > >> >> > >> >> Bruno, > >> >> > >> >> If you are worry about the cost of looking up though the vtable, I > think that you are stuck using template. So either use 2 or 3 and CRTP. But > first of all, I think that you should profile your code and verify that > this is a problem. There is no point in spending time refactoring your > code, if your are going to gain less than 1%... > >> >> > >> >> Best, > >> >> > >> >> Bruno > >> >> > >> >> On Monday, January 4, 2021 at 3:31:45 PM UTC-5 blais...@gmail.com > wrote: > >> >>> > >> >>> Dear all, > >> >>> I wish you all an happy new year! > >> >>> > >> >>> One problem we always end up facing with FEM problems is that, as > program grow, more and more features are added to the equations. This leads > to multiple variation of the same equations (for example, Navier-Stokes > with Newtonian and non-Newtonian viscosity, etc.). In turn, this leads to > assembly functions for the non-linear systems of equations which branch out > to multiple possibilities. > >> >>> > >> >>> I was wondering what is the best approach to deal with multiple > "switches" in an assembly function. The naïve approach would be to use if > conditions, but I have a feeling that if they appear down in the assembly > (for example the loop on dofs), this would lead to significantly higher > assembly cost because the loops would spend time just checking if. > >> >>> > >> >>> From experience, I have seen the following approaches: > >> >>> 1- If or switches in the assembly routine. Simplest/most versatile > way, but adds significant overhead > >> >>> 2- Template the assembly function with the parameters. I think this > would lead to zero additional cost, but as the number of parameters grows, > this can become more and more complex since the various possibilities have > to be known at compile time. > >> >>> 3- Use generic interface objects for common elements (for example a > viscosity class to calculate viscosity, etc.) and use inheritance to > specialise the model. I think this could be inefficient because of the need > to extensively look up through the vtable. > >> >>> > >> >>> What is the general consensus in the deal.II community on this > problem? What's the best way to deal with multiple possibilities in the > same assembly function? I would be very interested in hearing the > perspective of the ASPECT author since it has such a large range of sub > models. > >> >>> > >> >>> > >> > -- > >> > The deal.II project is located at http://www.dealii.org/ > >> > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > >> > --- > >> > You received this message because you are subscribed to the Google > Groups "deal.II User Group" group. > >> > To unsubscribe from this group and stop receiving emails from it, > send an email to dealii+un...@googlegroups.com. > >> > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/a501667f-4cb7-4894-9364-fb2eaa47c0ecn%40googlegroups.com > . > >> > >> > >> > >> -- > >> Timo Heister > >> http://www.math.clemson.edu/~heister/ > > > > -- > > The deal.II project is located at http://www.dealii.org/ > > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups "deal.II User Group" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to dealii+un...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/8748edb0-c096-4830-92e3-4a50baae00e9n%40googlegroups.com > . > > > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/7c241e92-803a-4cc1-84fb-0496506d94dan%40googlegroups.com.
