Re: [Mesa-dev] [PATCH 1/2] glsl: Don't rehash the values when copying to new table

2017-01-02 Thread Thomas Helland
That is a very nice suggestion! I'll have a look at that, and see if I can hack a quick implementation. It would probably be much better than my multi-map approach. It felt like sort of a hack-fix on the current algorithm. Doing all replacements in one run would also be really nice, as my

Re: [Mesa-dev] [PATCH 1/2] glsl: Don't rehash the values when copying to new table

2016-12-30 Thread Connor Abbott
On Fri, Dec 30, 2016 at 10:04 AM, Vladislav Egorov wrote: > Oh, thanks! A very nice torture case. However, it seems to be related to > another problem. The test case has no IF or LOOP blocks, so it can't be > possibly improved with speeding up the cloning of the table (the

Re: [Mesa-dev] [PATCH 1/2] glsl: Don't rehash the values when copying to new table

2016-12-30 Thread Vladislav Egorov
Oh, thanks! A very nice torture case. However, it seems to be related to another problem. The test case has no IF or LOOP blocks, so it can't be possibly improved with speeding up the cloning of the table (the torture case can be modified with a few ifs and fors on top though...). Anyway, on

Re: [Mesa-dev] [PATCH 1/2] glsl: Don't rehash the values when copying to new table

2016-12-29 Thread Tapani Pälli
On 12/30/2016 05:53 AM, Vladislav Egorov wrote: I've looked into it recently (I'm working on series of many various trivial optimizations) and it's faster to just memcpy() it. Just throwing out superfluous hashing still keeps slow hash-table insertion around -- with resizing, rehashing,

Re: [Mesa-dev] [PATCH 1/2] glsl: Don't rehash the values when copying to new table

2016-12-29 Thread Vladislav Egorov
I've looked into it recently (I'm working on series of many various trivial optimizations) and it's faster to just memcpy() it. Just throwing out superfluous hashing still keeps slow hash-table insertion around -- with resizing, rehashing, memory allocation/deallocation, internal