After calling `grow()`, the new head would jump to `old_capacity` rather
than staying to the same offset.
In practice this only loses a few bytes at most.
This is the first step towards enabling multithreading on AtomTable.
For now RawBlock will default to using Cell, which yields a byte-
equivalent compiled output.
Also adds an `atomic` feature, which, when enabled, will make RawBlock
use an AtomicPtr instead, ensuring that it implements `Sync`.
the old logic would be incorrect if the payload has higher alignment than the ArenaHeader i.e. when there is padding between the ArenaHeader and the Payload
rather than passing an address as usize pass the ArenaHeader pointer
similarly don't return a u8 ptr but use a ArenaHeader pointer instead
Don't convert the pointer to a ConsPtr by going through native endian
bytes in between.
We are exploiting the fact that the 3 least significant bytes are zero
for pointer to types of alignment 8 and we expect these to line up with
the f, m, and tag field at the end of the ConsPtr struct, but using
native endiannes for this would only work on big endian systems.
by wrapping BranchNumber in an Arc.
PermVarAllocation::Done had size 208 and is now down to 32.
A Box rather than an Arc would be smaller, but it looks like BranchNumber/BranchDesignator are clones a bunch so I expect it to be beneficial to reduce allocations both of the Box itself as well as its content.
we expect p to be in bound
if we are suffiently certain that p can never be oob
unsafe get_unchecked could be used to
eliminate bounds checking all together
which should improve performance further.
we used to spend ~5.8% of the time on getting the next value of the 0..INSTRUCTIONS_PER_INTERRUPT_POLL iterator
increment on Wrapping<u8> now only takes ~0.58 of the time
- u128 is only 16 bytes instead of 24
- incrementing u128 does not involve heap allocations
- u128 should be sufficent
it would take more than 2 sextilion years to overflow if we would be incrementing it every tick at 5GHz
i.e. 2^128-1 / 5 GHz / 60 / 60 / 24 / 356 > 2 sextilion
before this ~3.2% of the execution time of the program in https://github.com/mthom/scryer-prolog/issues/3265#issuecomment-4103176469 was spend in the increment_call_count function, after this change it's down to 0.3%
