Hello,
I've committed some fixed recently that enable one to experiment with nontrivial Type implementations. I'm not proposing or suggesting any changes in this email, but I do have a few questions at the end.
As a starter experiment that was easy (and non-serious), I shrank sizeof(Type) to 32 bits to see if the memory savings yielded any quick performance gains when building Swift.swiftmodule. I did not change the alignment of TypeBase from 8 to 4 bytes due to some PointerIntPair code that uses all 3 bits, but this would have yielded some additional memory savings due to padding minimization.
Somewhat surprisingly, the performance didn't improve. I suspect that without careful data structure layout, accidental padding is too easy to trip over under in LP64 environments.
To repeat myself, this experiment was done because it was easy, not because it was serious. (Well, that and I remember how much @Chris_Lattner3 is annoyed by the "wasted" bits in pointers. Hi Chris!)
I do have a few questions though for the experienced developers on the list:
- To what extent to people think that nontrivial pointer type walls are worth pursuing?
- Do people expect that storing the AST node kind in a given type wall to be worth it? Doing so would help us avoid memory loads when using
isaordyn_cast; and extracting the pointer from the type wall would simply require either a logical-and or logical-shift-right instruction. - Similarly, do people expect that storing critical
RecursiveTypePropertiesin theTypetype wall would be advantageous? - What is the reasonable upper limit for amount of memory used by the AST? I ask because on 64-bit platforms, having a contiguous AST can save additional memory, make the allocators faster, and as a bonus make more pointer bits predictable so that type walls can use them if they desire.
Dave Z.
memory efficiency!