Feature/ordered set #386
Merged
Feature/ordered set #386
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- this has to be benchmarked! - the mapping from old to new ids could be made more compact - This commit removes the hide function in predicate domains that removed negative literals that were never defined. "Good" incremental programs should be written in a way that such a situation cannot arrise.
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use hash table implementations from https://github.com/Tessil instead of gringo's own implementation. Currently, one can select between the sparse and hopscotch based hash table implementations. The first having a smaller memory footprint while the latter is faster (and currently the default).
The hopscotch based hash tables are slightly faster than gringo's HashSet but have a larger memory footprint. The sparse hash tables have a comparable but still slightly higher memory footprint as compared to gringo's HashSet and are slower. The memory overhead for the hopscotch based hash tables seems to be negligible. The main advantage is that the external implementation have a cleaner interface and do not require sentinel literals.
The sparse hash table implementations performs much better with a prime growth policy but then uses as much memory as the hopscotch based implementation. Maybe more tuning would be possible.