[Users] compiler warning for McLachlan

[Roland Haas]

Hello Ian, all,

> If we change the default, then the default will be VECTORISE_INLINE =
> no.  We have to have a default, and it's not clear which is better.
> Vectorisation is new in this release of the ET, so no one using a
> previous release should be affected.  We know that McLachlan prefers
> VECTORISE_INLINE = no for high order differencing, otherwise the
> compiler takes too much memory.  So I say we should set the default
> to the only thing we know is a definite improvement for the thorns in
> the ET.
Sounds reasonable. A comment why we make this choice in the option lists 
might be helpful though to avoid users blindly turning it on again since 
"inlining is always better" [see 
http://www.mjmwired.net/kernel/Documentation/CodingStyle#692 :-)].

> ?  The addition of this feature of Kranc was intended to avoid this
> proliferation of parameterised calculations.  I'm not sure what you
> are trying to say...
Ok, this is more or less what I suspected. My point would have been that 
the (smaller) parameterized calculations might have avoided the 
out-of-memory problems (though Erik says that 8th order always used lots 
of memory). Not having the number of routines explode is certainly a 
nice thing.

> know why), but Ranger has a ulimit setting of 8 GB for virtual
> memory, so I think the process will be terminated when it uses more
> than 8 GB, which is a sensible precaution for a production system.
ok. Then we will not get lots of angry emails from Ranger users that 
brought down the head node. Thanks.

Yours,
Roland

-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://keys.gnupg.net.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20110927/dba5caec/attachment.bin