> 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...
_______________________________________________
glob2-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/glob2-devel
