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@jedbrown.org
<mailto:jed@jedbrown.org>> wrote:

   Kenneth Raffenetti <raffenet@mcs.anl.gov
   <mailto:raffenet@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@mpich.org <mailto:discuss@mpich.org>
   To manage subscription options or unsubscribe:
   https://lists.mpich.org/mailman/listinfo/discuss




_______________________________________________
discuss mailing list     discuss@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@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss