Zannick
commented
1 year ago I'm going to merge this and mark it as complete. There was an issue with the history table in Cuckoo format either losing data or using a bloom filter that returned a false negative for an element previously added to the table (by the same thread, so clearly not a read-write race), and I'm going to need to double-check that this is not happening with the state table. With the PlainTable format (using default parameters), no errors occurred.
The new record of runtime is 886M (+256M extra) rounds before filling up the disk (the culprit is likely the history again, hence #76): 898M states left, 2.45B states added to the state table, 8.09B history entries, and tons of states skipped or deleted by the background thread. The time period being focused on was still in the 700000-715000ms range, which will be the topic for another issue.
Since we don't need history quite as much as the Context states themselves, we could save a decent amount of memory by having the history elements be recorded in a Cuckoo table much like the minimum times are.
We could store the history separately, as a map
unique id -> (history step, previous id). Unwinding is then several random-access point lookups.We could store the history together with the minimum time, as
Context -> (min elapsed, history id).[^1] If we did that, we no longer need to store ContextWrapper in the queue (and potentially we wouldn't need ContextWrapper at all!).[^1]: This is a better alternative to
Context -> (min elapsed, last history step, prev Context).