Re: [boost] [xpressive] Performance Tuning?

Subject: Re: [boost] [xpressive] Performance Tuning?
From: Edward Grace (ej.grace_at_[hidden])
Date: 2009-07-21 06:17:20

>> I wait with baited breath.
>
> Two warnings, but compile is successful.
>
> 1>R:\Programming_Projects\Spirit_Price\ejg_uint_parser_timing 
> \other_includes\ejg/timer.cpp(468)
> : warning C4267: 'initializing' : conversion from 'size_t' to
> 'unsigned int', possible loss of data
> 1>

[....] etc.

> Running the file gives:
> initializing input strings...
> Calibrating overhead...<Unhandled Exception>
>
> So, debugging into it now reveals that the error happens on line 170
> in timer.cpp, this function call:
>
>       ejg::statistics::robust_linear_fit(xs.begin() ,  xs.begin() + n,
> 					 ys.begin() ,  ys.begin() + n,
> 					 tmp.begin(), tmp.begin() + n,
> 					 intercept,  slope, __);

Blast!

That's one of the goofs I spotted via MSVC.  It turns out I didn't  
pull the latest sources from CVS when building the tar file.  Sorry.

> the function you tmp.clear(), but then never touch it again, so of
> course it is going to be a size of 0, does this function really work
> in gcc, and if so how?

Yes it does work in g++, I think because it's less conforming to the  
true concept of a vector object than the MSVC compiler (there I wrote  
it).  I presume that's what all the

#if defined(BOOST_MSVC)
#pragma inline_depth(255)
#pragma inline_recursion(on)
#define _SECURE_SCL 0
#endif // defined(BOOST_MSVC)

means at the top of Joel's file - switching off the bounds  
checking.   I think the gcc implementation of the stl is unchecked by  
default. Consider the following:

#include <vector>
#include <iostream>
#include <iterator>
int main() {
   using namespace std;
   vector<double> v(10);
   cout << v.capacity() << " " << v.size() << endl;
   v.clear();
   cout << v.capacity() << " " << v.size() << endl;

   // Will the following fail? It jolly well should!
   v[5]  = 2;
   cout << v.capacity() << " " << v.size() << endl;

   // Consequently if we squirt it out using
   copy(v.begin(),v.begin()+10,ostream_iterator<double>(cout," "));

   // It *might* work as in practice it should access the same memory  
as if we
   // had not done .clear().  Strictly though it's evil!
   return 0;
}

$ ./clear_capacity
10 10
10 0
10 0
0 0 0 0 0 2 0 0 0 0

That's pure evil of course! I suppose that's a good reason for always  
using .begin() and .end() rather than .begin() + N.

I'll double and triple check everything again to confirm it works,  
then post it up again.

Sorry about this mucking around. It makes me appreciate how hard it  
is to get things not just working but 'correct' across so many  
platforms.

-ed
>

------------------------------------------------
"No more boom and bust." -- Dr. J. G. Brown, 1997