[mpich-discuss] Very long configuration time

[William Gropp]

We should look at this again.  Many years ago, autoconf supported a local cache, but it didn't do it correctly - it would use the cache even when the cache values did not correspond to the environment.  A common error was to use the cache even when configuring with a different compiler or compiler flags, thus picking up incorrect results.  After several wasted days tracking down problems that were due to autoconf's broken cache system, we (that means I) added aclocal_cache.m4 to our local autoconf macros; this redefines AC_CACHE_LOAD.  There are also routines to save and load the cache for subsidiary configure invocations.

But that was a long, long time ago.  Today's autoconf is vastly different and may be more robust in how it handles caching.

Bill

William Gropp
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
University of Illinois Urbana-Champaign





On May 21, 2014, at 8:26 PM, Rob Latham wrote:

> 
> 
> On 05/21/2014 03:35 PM, Yida Wang wrote:
>> I have to use icc since I want to run code on Intel Xeon Phi. Also, I
>> tried to install MPICH2 since it claims to support Intel-MIC
>> architecture and is open source.
> 
> long ago, autoconf used to support a local cache.  sadly, that appears not to work, despite the continued presence of a --cache-file command line parameter.  It was perfect for just these kinds of situations: for but one example, mpich looks for stdint.h twice.
> 
> ==rob
> 
>> 
>> BTW, still configuring. It's faster to do it locally (both the source
>> code and the Intel compiler), but encountered a Fortran type length
>> detection error (don't remember the exact error information now, it
>> recommended me to "Consider setting CROSS_F77_SIZEOF_INTEGER to the
>> length in bytes of a Fortran INTEGER") last run.
> 
> 
>> 
>> Thanks,
>> YW
>> 
>> 
>> On Wed, May 21, 2014 at 4:28 PM, Jed Brown <jed at jedbrown.org
>> <mailto:jed at jedbrown.org>> wrote:
>> 
>>    Kenneth Raffenetti <raffenet at mcs.anl.gov
>>    <mailto:raffenet at mcs.anl.gov>> writes:
>> 
>>     > The Intel compilers could also be a source of slowdown. Are they
>>     > installed on a network filesystem? They may also call out to a
>>    network
>>     > license server each time they are invoked for a compile test.
>>    Does just
>>     > compiling a small program take a long time with icc, ifort, etc.?
>> 
>>    The system headers and libraries are also often on a network file
>>    system.  Although moving the source tree to a local disk usually
>>    provides some improvement, I rarely find it getting anywhere close to
>>    the performance of a cheap laptop because most of the file accesses
>>    performed by the compiler are hitting the network anyway.  This is the
>>    price we all pay for legacy file system semantics and dumb compiler
>>    architecture.  I think most companies in a place to change these things
>>    do full local installs on their development boxes so that compilation is
>>    fast.  And the HPC vendors wear blindfolds and put their heads in the
>>    sand.
>> 
>>    As for Intel license servers, this is the price you pay for anti-piracy
>>    measures.  People that are really ticked off by this crack their
>>    compilers---the pirates enjoy a better user experience.  Is it ethical
>>    to use a cracked version if you've already paid for the licensed
>>    version?
>> 
>>    Besides those issues, the Intel compiler usually takes a lot longer to
>>    compile.  It's worth building with gcc and clang to compare.  You might
>>    be pleasantly surprised to find that in addition to compiling faster,
>>    your code also runs faster (this is the case for several applications I
>>    work with).
>> 
>>    _______________________________________________
>>    discuss mailing list discuss at mpich.org <mailto:discuss at mpich.org>
>>    To manage subscription options or unsubscribe:
>>    https://lists.mpich.org/mailman/listinfo/discuss
>> 
>> 
>> 
>> 
>> _______________________________________________
>> discuss mailing list     discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>> 
> 
> -- 
> Rob Latham
> Mathematics and Computer Science Division
> Argonne National Lab, IL USA
> _______________________________________________
> discuss mailing list     discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20140522/52ecdb9e/attachment.html>