[Users] compiler warning for McLachlan

[Erik Schnetter]

I created the VECTORISE entries in the Simfactory MDB files so that
the generated code would be most efficient. There is in particular a
difference between Intel and AMD systems, having to do with the size
of the instruction cache.

Yes, we can change the default, but please keep the behaviour of the
current machines the same unless there is a problem when compiling.
Just switching off inlining everywhere would undo my work, even in
cases where this is not necessary. In other words, when changing the
default, I ask you do add VECTORISE_INLINE = yes to all MDB entries
that don't set anything at the moment.

-erik

On Tue, Sep 27, 2011 at 12:07 PM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>
> On 27 Sep 2011, at 18:00, Erik Schnetter wrote:
>
>> On Tue, Sep 27, 2011 at 11:50 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:
>>> If they have VECTORISE = yes (the proposed default for the new release of the ET) and VECTORISE_INLINE = yes (the current default, which I propose should be changed to "no"), and they try to compile McLachlan, the behaviour will be as Frank saw, which is that you get a warning and the compiler runs out of memory.  If the Ranger head node is configured such that a user can bring down the system by running a program which takes up a lot of memory, then the head node will go down.  This is common for default linux installs (I don' t 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.
>>
>> This depends very much on the compiler, the compiler version, and the
>> options chosen. A good compiler won't use too much memory when
>> optimizing; this is really a compiler bug (that we should report).
>>
>> I regularly encounter cases where a compiler takes a long time, runs
>> out of memory, or outputs an error message that it stopped optimizing.
>> Or the compiler crashes, sometimes in debug mode and without
>> optimizing. What I usually do is either modify the source or the
>> Simfactory options. We simply need to do the same here. (There's no
>> need to be afraid that Ranger will explode, it didn't explode in the
>> past either.)
>>
>> Frank, which machine was this? Which compiler version? What options
>> did you use? Could you open a trac issue about this?
>
> This was numrel07, he was using numrel.cfg from simfactory.  I reproduced his problem in Datura by setting VECTORISE_INLINE = yes.  I think we should just change the default in Vectors to VECTORISE_INLINE = no.  Do you think this is a bad idea?  If so, why?
>
> --
> Ian Hinder
> ian.hinder at aei.mpg.de
>
>



-- 
Erik Schnetter <schnetter at cct.lsu.edu>   http://www.cct.lsu.edu/~eschnett/