On 12 September 2011 23:24, Marie E. Rognes <m...@simula.no> wrote: > On 09/12/11 21:56, Kristian Ølgaard wrote: >> >> On 12 September 2011 21:36, Marie E. Rognes<m...@simula.no> wrote: >>> >>> On 09/12/11 20:00, Marie E. Rognes wrote: >>>> >>>> On 09/12/11 19:54, Garth N. Wells wrote: >>>>> >>>>> On 12 September 2011 18:49, Marie E. Rognes<m...@simula.no> wrote: >>>>>> >>>>>> On 09/12/11 19:40, Garth N. Wells wrote: >>>>>>> >>>>>>> Which compiler options did you use when evaluating the speed up? >>>>>>> >>>>>> Tested Extrapolation.h with vanilla dolfin (which is dominated by >>>>>> evaluate_basis calls). No additional compiler options set. >>>>>> >>>>>> What are the default compiler options? >>>>>> >>>>> '-g' for plain JIT, which is dead slow. You should test with at least: >>>>> >>>>> parameters["form_compiler"]["cpp_optimize"] = True >>>>> >>>>> in the Python code. This will use '-O2'. >> >> Isn't this limited in a way? Would it be a problem to let users do: >> >> parameters["form_compiler"]["cpp_optimize"] = '-O2 -funroll-loops' >> parameters["form_compiler"]["cpp_optimize"] = '-O3' >> >> and then perhaps let >> >> parameters["form_compiler"]["cpp_optimize"] = True >> >> default to '-O2' as we do now? >> Just a thought. >> >>>> Ok, thanks -- I'll take a closer look. >>>> >>> Take a look at the attached results in old_evaluate_basis.txt (results >>> with >>> "old" FFC), >>> and new_evaluate_basis.txt (results with "new" FFC) from running the >>> attached >>> test_evaluate_basis.py. >>> >>> Acceptable? >> >> Looks good, and the generated code is much nicer now. :) >> It could have been fun to see the impact of the '-O2 -funroll-loops' >> option on the old code, but then you'll have to switch to C++. Anyway, >> I'm quite sure that the old code will never perform as well as the new >> code even with this option. >> >> As you have probably found out, the generated code was simply a mirror >> of what is going on in FIAT (translated to C++). > > Yep. > >> Perhaps there are more places where we can simplify the generated code? >> > > Probably, did you have anything particular in mind?
Not really, just wondered if you found something while poking around. > One thing we could do to reduce code size > would be to move the evaluation of the modal(?) basis functions > outside of the switch and just do the vector-vector product inside. Yes, I thought about reusing code which is identical for dofs, but as I don't really know how those values are being generated I can't tell which parts of the code are guaranteed to be identical _always_. So, I would have to implement some ad hoc look up/mapping of values unless you can explain what is going on :) And of course we still need to consider mixed elements etc. > Also, I think it would significantly speed up evaluate_basis_all, > if we just did the evaluation of the modal basis functions once, > and then the vector-vector product 'local_dimension'-times. > Actually, I plan on doing that unless anyone protests vehemently. > The reduction in generated code from the one should more or less > counteract the increase in generated code from the other. The code for the evaluate_*_all functions was just a simple way of getting something working fast, I don't use it (others might), so feel free to improve the code. Kristian >> Another thing in relation to improving the evaluate_basis* functions >> that I have thought about is if it's really necessary to support >> derivatives of arbitrary order. If we only generate code for the first >> derivative by default (and support arbitrary derivatives by a command >> line argument) the code will be a lot simpler (easier on C++ compiler) >> and much faster irrespective of which gcc optimisation is being used. >> > > Sound neat to me. > > -- > Marie > >> Kristian >> >>> -- >>> Marie >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~ffc >>> Post to : ffc@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~ffc >>> More help : https://help.launchpad.net/ListHelp >>> >>> > > _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
