Setting this unconditionally doesn't make sense; there may be another compiler, or another version, or a different set of compiler options which doesn't have such a dramatic slowdown, and which produces much slower code in this case. Things need to remain configurable.
Let's fix this particular problem first, and then look for a general solution once we know the behaviour on all the other machines.
-erik
On Tue, Sep 27, 2011 at 10:56 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
On Tue, Sep 27, 2011 at 03:02:42PM +0200, Ian Hinder wrote:
I just checked, and even before combining all the FD orders into one thorn, the compilation with VECTORISE_INLINE = "yes" was slow and used a lot of memory (> 8 GB) for 8th order and multipatch with vectorisation. The compiler memory usage does seem to have increased by combining the FD orders however. Given that production binary black hole simulations typically use 8th order these days, I think we should just use functions for the difference operators by setting VECTORISE_INLINE = no.
Can we set this unconditionally for McLachlan only? Otherwise people are bound to stumble over this when they try the released version.
Frank
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users