ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 15, 2007 at 04:07:12PM +0200, Kristian Oelgaard wrote:
> 
> 
> Currently I'm compiling simple forms like:
> 
> e_u   = FiniteElement("Lagrange", "triangle", 10)
> e_uh  = FiniteElement("Lagrange", "triangle", 5)
> u   = Function(e_u)
> uh  = Function(e_uh)
> a = (u - uh)*(u - uh)*dx
> 
> which takes roughly 2min to compile. The code generation is very fast but
> formatting the output takes forever. With quadrature the above form compiles in
> 1-2s and so does tensor representation if I do:
> 
> #ufc_code["tabulate_tensor"] = remove_unused(body)
> ufc_code["tabulate_tensor"] = body
> 
> in __generate_cell_integral() (ufcformat.py)
> 
> So avoiding the use of remove_unused(), at least when generating code for
> tabulate_tensor() would be preferable.
> 
> Currently the code generation in tensorgenerator.py is executed in the same
> order as the code appear in the resulting header file i.e.
> 
> coefficients -> geometry -> sign_code -> element_code
> 
> and then in ufcformat.py we put the jacobian in front of everything after which
> we hand over the code to remove_unused()
> 
> I suggest we instead do something like this:
> 
> # generate element code + set of used geometry terms + set of used signs
> element_code, geo_set, sign_set = __generate_element_tensor()
> 
> sign_code = __generate_signs(sign_set)
> 
> # generate geometry code + set of used coefficients + set of jacobi terms
> geo_code, coeff_set, jacobi_set = __generate_geometry_tensors(geo_set)
> 
> code = __generate_jacobian(jacobi_set)
> code += __generate_coefficients(coeff_set)
> code += geo_code + sign_code + element_code
> 
> with this approach we should be able to speed up code generation (at the expense
> of memory consumption, which will be small I think?)
> 
> or is the above not possible because of something that I missed?
> 
> Kristian

We did something like this before (keeping track of which variables
are used when we generate the code). I added the remove_unused() as a
postprocessing step for simplicity.

I have no objections to fixing this, but perhaps we can wait until
after the release? (So we don't break anything.)

Another thing to look at would be if it's possible to optimize the
remove_unused() function.

/Anders