<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 8, 2017 at 3:01 PM, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think this is good stuff. I'd gladly take it just for the shader-db<br>
improvement.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Agreed.  If it really did hurt minecraft before, we should try that again just to be sure, but I like faster shader compilation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Marek<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 8, 2017 at 11:35 PM, Thomas Helland<br>
<<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>> wrote:<br>
> 2017-02-08 22:07 GMT+01:00 Thomas Helland <<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>>:<br>
>> 2017-02-08 21:35 GMT+01:00 Thomas Helland <<a href="mailto:thomashelland90@gmail.com">thomashelland90@gmail.com</a>>:<br>
>>> I was cleaning up my local git repo, and came across this series.<br>
>>> Last time it was discussed was all the way back in April 2015.<br>
>>> Things looked pretty good back then, but we where seeing a smaller<br>
>>> regression in CPU-bound scenarios as Eric found with forcing software<br>
>>> rendering while running Minecraft.<br>
>>><br>
>>> I figured I'd do a retest of the series to see how it fares today.<br>
>>> Using perf on shader-db I see:<br>
>>> hash_table_search being cut from 3.88% down to 1.83%.<br>
>>> _mesa_hash_data being cut from 1.47% down to 1.25%<br>
>>> _mesa_hash_table_rehash going from 0.23% up to 1.16%<br>
>>> hash_table_insert being cut from 2.26% down to 0.33%<br>
>>><br>
>><br>
>> This stats are wrong. I recompiled stuff, so the symbols got<br>
>> mangled in the libraries. So here is the correct data (after increasing<br>
>> the initial size of the set and hash table to 8, so not perfectly comparable):<br>
>> hash_table_search: 3.88% -> 1.84%<br>
>> hash_table_insert: 2.26% -> 1.16%<br>
>> _mesa_hash_data is unchanged (which is kinda obvious).<br>
>> set_add: 0.70% -> 0.35%<br>
>> set_search: 0.59% -> 0.27%<br>
>><br>
>>> This yields an approximate 10% reduction in shader-db runtime.<br>
>>><br>
>>> The increase in the rehash function is a bit peculiar.<br>
>>> I'll look into increasing the table one more step, as a four entry<br>
>>> hash table seems a bit on the low side. I'll also work on getting<br>
>>> some more reliable numbers from a real world application, along<br>
>>> with some more runs of shader-db to get better statistical certainty.<br>
>>> I'll pull out my i3-6100 / RX460 combo and give this a spin<br>
>>> with Borderlands 2 I think, as Marek's threaded GL work suggests<br>
>>> this is a title with heavy CPU bottlenecking.<br>
>>><br>
><br>
> Using this hardware I ran the Metro LL Redux benchmark mode<br>
> through phoronix-test-suite as a quick test. Average fps improved<br>
> from 43,97 to 45.23. So not insane, but a decent gain of 2-3%.<br>
> I'll come back with some more numbers from in-game play of<br>
> some other games in my possession. Likely CS:GO, portal,<br>
> TF2, dota2, borderlands 2, or some other games I have.<br>
><br>
>>> As a side note, Robin Hood hashing was mentioned in the thread from<br>
>>> back in April 2015. I actually have an implementation of that, but<br>
>>> I'm still working out an issue that our make-check tests doesn't<br>
>>> catch that causes corruption in the table when runing shader-db.<br>
>>> I'm not to sure about it's effect though, as it sacrifices insert<br>
>>> speed for lookup speed, but one never knows until one tests.<br>
>>><br>
>>> Let me know if this is something I should persue. If not I'll<br>
>>> mark this series as "junk" in my git repo, and get on with the cleaning.<br>
>>><br>
>>> Thomas Helland (4):<br>
>>>   util/tests: Expand collision test for hash table<br>
>>>   util: Change hash_table to use quadratic probing<br>
>>>   util: Change util/set to use quadratic probing<br>
>>>   util: Use set_foreach instead of rolling our own<br>
>>><br>
>>>  src/util/hash_table.c                 | 102 +++++++++--------------------<br>
>>>  src/util/hash_table.h                 |   3 +-<br>
>>>  src/util/set.c                        | 118 ++++++++++++------------------<wbr>----<br>
>>>  src/util/set.h                        |   3 +-<br>
>>>  src/util/tests/hash_table/<wbr>collision.c |  14 ++++<br>
>>>  5 files changed, 89 insertions(+), 151 deletions(-)<br>
>>><br>
>>> --<br>
>>> 2.11.1<br>
>>><br>
> ______________________________<wbr>_________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>