Re: [glob2-devel] gradient improvement

[Simon Schuler]

> I thought about an architecture independent way to measure the quality
> of our optimizations.  In your case we could implement a global 64-bit
> counter for the sum of all listCountWrite values in total and cerr
> that at the end of a mission (or put it in a logfile).  By comparing
> the results of the normal implementation to optimized ones (using
> "glob2 -nox" on a few maps with the different versions of glob2) we
> could get further insight into the algorithm.  Thereby we could see if
> an optimization is as good as we duduced from simple cases.  If it is
> not - then there is no need to think about cleaning up the code to
> reduce the overhead.

Hmm, yes that could give some good indications about the algorithm...

> How did you check it?  Running both gradient calculations and compare
> their result field by field?
Exactly. I did something like this:
        memcpy (testGradient, gradient, size);
        updateGlobalGradientOwn (testGradient);
        updateGlobalGradientSlow (gradient);
        assert (memcmp (testGradient, gradient, size) == 0);
> 
> I had to try something different for an idea.  But this was slow
> and used two boolean flags.  Your flags would be really nice if
> c++ would allow to define constants in binary representation.
> I would put comments like
> // 9  = 1001
> // 3  = 0011
> // 6  = 0110
> // 12 = 1100
> in the code.

Yes perhaps that would make it more readable. Constants like 0b1001
would really be nice...