iu-parfunc / cnf-mutable-tests Goto Github PK

However... this still does not fully solve the problem because if GHC crashes, that is not an "exception" that can be caught.

The tests that fail "hard" like that need to be split into their own executables.

After the simple unboxed-vector-in-CNF works, next step will be something that is still simple but pointer-based (though not threadsafe), for example, a linked list of Ints:

• root of the structure would be a CNFRef pointing at the first cons cell in the list (and optionally the last as well).
• each car field would be an unboxed vector of Ints. This could be a singleton vector at first.
• cdr fields would be mutable pointers to the next cons cell
• the root would also contain a pointer to a free list as well as a head of the actual list.

This should be enough to implement a traditional imperative sequence structure, with its own memory management scheme.

• Extending the list would mean mutating the last CDR pointer to point to a new cell, drawn from the freelist if possible, or added to the compact with appendCompact.
• Popping the first thing off the list would mutate the root's first pointer and extend the freelist.
  This structure only grows, never shrinks. Though there could always be a data-structure specific policy to recompact if the freelist grows bigger than the main list by some factor....

It seems like Data.CList is ready for a simple benchmark. How about a two phase benchmark:

• phase 1: run N inserts on the list
• phase 2: for K steps, drop one then insert one

This "blows up" the structure to a certain size, and then runs with it in that steady state.

Three versions to compare would be:

1. CList (Compact + FreeList)
2. NormalHaskell - Either DummyCompact NoFreeList, or just a fresh implementation.
3. Senseless: (DummyCompact+FreeList) CList with the dummy compact implementation (i.e. no CNF)
4. Leaky: (Compact+NoFreeList) A tweaked version of CList with no freelist, but with everything else as-is.

Of course the middle is senseless, but it doesn't hurt to run it. With a large N and even larger K we expect to see GC time in (3). But version (1) should be able to run in a completely GC-free state and thus total GC time should not grow with K.