On 27 Sep 2011, at 18:00, Erik Schnetter wrote:
On Tue, Sep 27, 2011 at 11:50 AM, Ian Hinder ian.hinder@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?