drt: Contiguous GC data

[kbieganski]

Store some of the GC data in contiguous arrays. The last commit is to ensure no one pushes to these vectors, as other code references this data via pointers, so we cannot invalidate them.

asap7/aes

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
baseline	400.30	401.20	400.77 ± 0.27	1.03	400.83	1.03
drt-contiguous-gc	390.57	390.82	390.66 ± 0.08	1.00	390.63	1.00

asap7/ibex

Branch	Min [s]	Max [s]	Mean [s]	Relative mean	Median [s]	Relative median
baseline	570.74	571.73	571.13 ± 0.31	1.03	571.08	1.03
drt-contiguous-gc	555.77	557.53	556.71 ± 0.50	1.00	556.69	1.00

[github-actions]

clang-tidy made some suggestions

[kbieganski]

@osamahammad21 Have you had a chance to look at this?

[maliberty]

Please cleanup the clang-tidy warnings

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[osamahammad21]

I am still looking into the PR but I don't understand the need for the dynarray class. Is it just a container for the std::vector? Why is it better than just using std::vector directly?

[osamahammad21]

I have concerns about the dynarray class. It doesn’t feel dynamic, as it prevents adding objects to the vector without invalidating pointers both in the objects themselves and the region query. While we don’t currently add objects this way, it’s something we might need in the future. Using unique_ptrs was more intuitive and developer-friendly, and the gain here is modest at just 2.5%. Since we rely heavily on polymorphism, this approach likely won’t be generalized in DRT, making the trade-off less compelling. Is there a stronger or longer-term motive for merging this PR that we might be overlooking?

[kbieganski]

I should've outline some of this in the description, apologies.

The whole point of dynarray is to prevent adding objects to the vector. This is to prevent invalidating pointers to its contents. I'd rather those be indices, but that would be too big of a change for one PR. I'd also prefer to just have an array instead of a vector there, but again, some places required too many changes for a single PR.

As for a longer term motive, this is a change to the structure of a small subset of the data that DRT operates on. One could apply similar changes to the rest of the data, and stack these speedups.

I get that you use polymorphism and you like it, but I encourage you to reconsider using it everywhere. It's dynamic in some ways, but static and constraining in others. Not to mention it requires pointer chasing and fragmented memory access. Can you point out what problems it solves for you? I also fail to see how arrays of pointers are more intuitive than just arrays.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"