[postgis-devel] Caching Double-based Boxes

[Paul Ramsey]

Well, two things (and notice to reader, we're discussing the doublebox
spike here):
- on the side of expected slowdown (systematic problem), we're pushing
twice as much data through the pipes (reading cached double instead of
cached float) to get the answer we want
- on the side of the unexpected slowdown (operator problem (Paul
error)), in order to do the comparisons between the cache keys
(doubles) and the index keys (floats) the cache keys now all have to
be converted to floats before the comparison so there's an extra step
in there that doesn't exist in the pure-float (cached float and float
indexes) implementation
P.

On Tue, Nov 29, 2011 at 6:03 AM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> On 26/11/11 20:44, maplabs at light42.com wrote:
>
>> Hi All-
>>
>>   I have devised a second set of tests, based on the first run and some
>> suggestions. There are three sets of results for each of the source
>> builds, float bbox and double bbox. The condensed records are here:
>>
>>     http://download.osgeo.org/postgis/postgis_dbl_boxes_test_results22.csv
>>
>> Notes:
>>
>> * there is one test result in one run that was lost..
>> * I have not analyzed these numbers.. I expect people will want to do
>> that for themselves. Barring an undiscovered problem in the setup, there
>> are very large differences in run times
>> for the double-boxes branch, but almost entirely consistant run times
>> for the float-trunk
>> branch.
>>
>> * The third run in each case was after a database restart, in order,
>> from top to bottom. The isolated numbers in the columns are 'cold' bbox
>> hits.. much much larger than
>> running them a second time, so I noted them as an aside
>
>
> Hi Brian,
>
> Thanks for spending time on devising and running the tests. I must admit I
> am surprised by the amount of slowdown that you experienced during your test
> run as there are a couple of reasons why things should, in theory, be the
> same or faster:
>
> 1) Doubles will give 8 byte alignments on 64-bit architectures (so that
> should align these values automatically within the structs which as we know
> gives us a good speed increase)
>
> 2) If we're using doubles, then this should be the most optimal path for
> hardware assisted IEEE calculations (or at least, it should equivalent and
> not slower)
>
> I'm wondering if perhaps something else is going on here, such as we're now
> doing extra internal copying or similar? Is there any chance of generating a
> gcc profile from both tests so we can find out exactly where the time is
> going?
>
> I'm not sure why but something about this intuitively feels wrong in terms
> of the amount of slowdown related to the change in work done here...
>
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland - Senior Technical Architect
> PostgreSQL - PostGIS
> Sirius Corporation plc - control through freedom
> http://www.siriusit.co.uk
> t: +44 870 608 0063
>
> Sirius Labs: http://www.siriusit.co.uk/labs
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel