Boost logo

Boost Testing :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-20 21:24:01


"Victor A. Wagner Jr." <vawjr_at_[hidden]> writes:

> At 07:00 2005-06-17, David Abrahams wrote:
>>"Victor A. Wagner Jr." <vawjr_at_[hidden]> writes:
>>
>> > At 04:08 2005-06-17, you wrote:
>> >>"Victor A. Wagner Jr." <vawjr_at_[hidden]> writes:
>> >>
>> >> >>Was it only that one test that was failing? We could easily add an
>> >> >><asynch-exceptions> feature and set it to "on" in that test's
>> >> >>requirements.
>> >> >
>> >> > there was (at the time) only one failure showing non-green in the vc-8_0
>> >> > (maybe it was before the date-time problem was marked expected failure)
>> >> > results.
>> >> > I don't know how easy it would be to add it to a specific instance since
>> >> > (from my brief reading of the /EH options page in MSDN) it appears that
>> >> the
>> >> > order in which the options appear affects what's used and /EHs and /EHa
>> >> > would need some close looking at, since the testing framework needs at
>> >> > least on of them.
>> >>
>> >>I already analyzed the issues and did it for BBv2. See
>> >>tools/build/v2/tools/msvc.jam
>> >
>> > good, then as soon as we've finished this release there won't be any issue
>> > right?
>> > We're going to be dropping BBv1 and switching to v2?
>>
>>Yes. That said, I realize we need to make the fix. Why? Because
>>even people that don't use bjam for their own projects will be
>>building their Boost release-mode libraries for distribution with
>>bjam, and we can't impose the cost of /EHa on every user. Some of
>>these people surely need high performance.
>
> I don't have time for this. But don't you think profiling before
> complaining about performance should be in order?

Not when this particular change is well known to commonly have a
performance impact.

> IF the performance goes to hell in a handbasket, perhaps we should be
> filing bug reports with MicroSoft

Do you think that will help our users whose applications suddenly slow
down when they upgrade?

> instead of just saying "we'll bow the the whims of the performance
> weenies".

I don't know who "the performance weenies" are supposed to be. I am
working on high-performance numerical codes right now so maybe you can
count me among them. Why do you think "we" would bow to the idea of
making a quick-and-easy change to the build system to suppress a
single error and be unsympathetic to those who care about performance?

> from my point of view, what happens AFTER an error has been detected can
> hardly have a significant affect on performance.

Then you don't know much about the MS implementation of exception
handling.

> The state of affairs as you wish to have them will abort the program
> which drops the speed of the program to 0.

Not if the program never segfaults in the first place, which is the
case for most good programs.

> perhaps you're worried about the extra memory it will take to take this
> already detected error and turn it into an exception?

No, I'm worried about the speed overhead incurred by the MS exception
mechanism to deal with the possible eventuality of an exception, even
when none is thrown.

>> > in about 24 hours, I'm going to be gone for 3 weeks
>> > the system will be left running mostly unattended
>> > is this something that really needs to be addressed before the release
>> > (i.e. before I leave?)
>>
>>I'm afraid so.
>
> I took the change out
> I also deleted from my results directory all .output, .xml, and .obj files
> before this next run (scheduled in 10 minutes).
> I'll be back in town late on Friday 2005 July 8.
> I hope the release has happened by then.

Me too. Have a nice trip.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost-testing list run by mbergal at meta-comm.com