Message5867

Author malte
Recipients andrew.coles, erez, florian, jendrik, malte, silvia
Date 2016-12-12.23:27:37
Content
Taking the wider view: I am somewhat reluctant to rush merging the new hash
implementation because of its time overhead. But I don't think this should keep
us from merging other, less critical aspects of this that affect other parts of
the code.

Suggestion: we split off the different code changes (e.g. replacing generating
operator pointers by operator IDs, new hash function, new hash table
implementation, space improvement for lmcount heuristic) into their own issues,
and we use this issue for keeping track of the relative performance of m32 vs.
m64 and the eventual switch (hopefully) to m64 in the build configs etc.

I see the following largely independent changes:

A) operator IDs instead of generating operator pointers
B) new hash function
C) new hash table implementation
D) space improvement for LM-Count

If we split these off, hopefully we can at least merge A, B and D soon.
(Of course, D still needs to be done.)

What do you think?
History
Date User Action Args
2016-12-12 23:27:37maltesetmessageid: <1481581657.93.0.43751197846.issue213@unibas.ch>
2016-12-12 23:27:37maltesetrecipients: + malte, erez, andrew.coles, silvia, jendrik, florian
2016-12-12 23:27:37maltelinkissue213 messages
2016-12-12 23:27:37maltecreate