[Mesa-dev] [PATCH 0/3] Hash-table and hash-set, V4

Eric Anholt eric at anholt.net
Thu Apr 16 12:16:34 PDT 2015


Eric Anholt <eric at anholt.net> writes:

> Jason Ekstrand <jason at jlekstrand.net> writes:
>
>> On Sat, Apr 11, 2015 at 4:25 PM, Thomas Helland
>> <thomashelland90 at gmail.com> wrote:
>>> The performance numbers (shader-db runtime) are:
>>>
>>> Difference at 95.0% confidence
>>>       -14.7608 +/- 3.36786
>>>      -9.05064% +/- 2.06501%
>>> (Original runtime was 160 seconds)
>>
>> Good Work!
>>
>> I had one comment on the hash set patch.  With that fixed, the series is
>>
>> Reviewed-by: Jason Ekstrand <jason.ekstrand at intel.com>
>>
>> Probably want to give Eric a a couple of days to look at it too.
>
> Yeah, I'm splitting the series up into each individual change (resizing
> cutoff, linear probing, power-of-two, then quadratic probing) so that we
> can make sure that they're all good for both the compiler and GL object
> lookup.

OK, I've got a split out series on hash-quadratic of my tree.  Here's be
bad news from the last commit:

    However, over the course of this series, INTEL_NO_HW=1 minecraft is still
    down by -0.615582% +/- 0.514508% (n=55).  If we drop 2 low outliers each
    from before/after of that dataset, the image is more clear: -0.538901% +/-
    0.381768% (n=53).

It looks like the collision reprobe changes are hurting too much.  The
fact that collision is that big of a deal is bad -- I thought we should
be having basically no collision in Mesa's GL hash tables, but I guess a
lot of objects have been deleted before new ones are genned (and this
probably also means that our benchmarking, which tends to execute a
timedemo once instead of doing level loads multiple times, is
underestimating the problems we have in our GL name hash tables).  This
probably means we should be looking into making GL gen its handles from
the lowest unused number when possible, and using an array for most of
the hash table.  Until we do, I don't think we want to change our hash
table to improve compiler performance at the expense of runtime
performance.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150416/79aed8b4/attachment.sig>


More information about the mesa-dev mailing list