Subject: Re: [boost] Issues with intel's compiler and newer builds of GCC
From: Belcourt, K. Noel (kbelco_at_[hidden])
Date: 2010-10-20 17:53:07
On Oct 20, 2010, at 10:41 AM, Hartmut Kaiser wrote:
>>> This is now a problem for the MSVC-7.1 test, too. It, too, times
>>> The logs from the build machine have warnings. These warnings are
>>> identical to ones that I get with MSVC-7.1 when building
>>> (rather, the warnings shown on the build logs are a subset of the
>>> warnings I get, the logs seem to cut off after a certain amount of
>>> warnings, e.g. 65k). Building Serialization with MSVC-7.1 passes all
>>> tests on my machine and builds all examples, without any trouble.
>>> I'm sure the argument could be made that five minutes (300
>>> seconds) is
>>> more than reasonable, and the XML grammar for Serialization could
>>> definately be refactored (it's structure is nearly identical to the
>>> old Spirit.Classic grammar; I didn't want to get fancy). However,
>>> grammar works, and I'd really like to not have false negatives from
>>> the build machines. This is, to my knowledge, the first component of
>>> Boost that uses Spirit 2.x (Hartmut/Joel please correct me if I am
>>> wrong. Wave uses Spirit Classic, I believe). The Spirit 2.x examples
>>> aren't compiled by the tests, so I am assuming that this is the
>>> time the build bots have compiled larger Spirit 2.x parsers.
>>> The compile times for MSVC 10, GCC and clang are all far more
>>> reasonable than Intel and MSVC 7.1 on my machines.
>> I agree that the time limit can be pretty annoying - I had to
>> refactor a
>> large number of the Boost.Math tests to avoid long run times.
>> the limit is not unreasonable either - it is important that the tests
>> cycle in a reasonable time - remember that the CPU time on the
>> build bots
>> has all been graciously donated, and isn't entirely free of cost.
>> We also
>> need to consider the impact on the end user of long compile times,
>> also on
>> the occasional "casual" tester of Boost.Serialization - the time
>> taken to
>> run all the tests is pretty long, so anything that can be done to
>> that would be a big win.
>> Would it be worth getting the spirit2 developers in on this to see if
>> there is any low-hanging fruit that can be pulled?
> Not that I know of :-(
> We're trying to bring down Spirit's compilations times, but that's a
> Couldn't we customize the max time before cutoff for compilers known
> to be
> slow (icc) only?
Well it's not just Intel. PGI is another very slow EDG based compiler.
Frankly I think five minutes is a pretty long time for a compiler to
chew on a single source file. Note that most of the Sandia hardware
these tests run on is pretty high end server stuff (e.g. 8 core Intel
5570's, 32 Gb memory and 500Gb local disks). I point this out because
most users have significantly less capable systems so they will
experience significantly longer compile times.
Off the top of my head, I don't know how to alter Boost.Build to
introduce a toolset dependent timeout though I'm sure it can be done.
I'm just not at all convinced that we should do it.