Comment 9 for bug 959052

On 03/22/2012 08:41 AM, Anders Logg wrote:
> On Thu, Mar 22, 2012 at 07:24:42AM -0000, Johan Hake wrote:
>> Thanks Martin!
>>
>> The memory now peaks at 1.2GB (from 4.8GB) and code for the jacobian
>> form is now generated within 4 min, as opposed to some 8 min using SFC.
>> FFC can still not generate optimized code, the memory peaks at 7GB and I
>> interrupted it after 10 min. When optimization is turned off the code is
>> generated but everything is flattened into a single line which does not
>> compile (gcc).
>
> Why is the code flattened? I assume the quadrature representation is
> used which shouldn't flatten loops.

When optimized is set to true in the ffc_options it is not flattened,
but that process is the one that fails to complete.

Johan

> --
> Anders
>
>
>> Some further optimization would be nice as 1.2GB is still quite large
>> but doable on most laptops these days.
>>
>> Johan
>>
>> On 03/21/2012 05:37 PM, Martin Sandve Alnæs wrote:
>>> Status now is that I found some more optimizations today, giving
>>> significant memory savings for the Jacobi representation after
>>> expand_indices.
>>>
>>> I accidentally pushed to trunk instead of my buildbot, so I hope the
>>> dolfin tests pass :)
>>>
>>> It would be nice if someone with applications with complex forms can
>>> check the performance of the latest ufl. I don't think there are any
>>> assembly time changes, just preprocess/compile time.
>>>
>>> In the long run, the most scalable solution would be to avoid using
>>> expand_indices, which will require some more index handling logic in the
>>> form compilers. I'm not going down that road at the moment, so for now
>>> lets hope at least these improvements open up some more doors.
>>>
>>
>