perf: Relax atomic allocated ops in Table and shrink page size

[Veykril]

These are already paired with a lock-access on write. We also never store more than 10 bits of entries per page, so we can swap the usize with a u16 to shrink the page overhead.

[Veykril]

@davidbarsky here is your reminder for this for your loom work

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	f6cdb3d
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/684bb464675aa80008829a60

[codspeed-hq]

CodSpeed Performance Report

Merging #766 will not alter performance

_{Comparing Veykril:veykril/push-qryuyllyzoll (f6cdb3d) with master (6ced42b)}

Summary

✅ 12 untouched benchmarks

[ibraheemdev]

just shuttle passes

I don't think shuttle actually models weak atomics. We could run Miri with --many-seeds to get more coverage of this.

[Veykril]

Ah I see, a bummer. According to miri docs the default is already at a high, slow 64. Unsure if increasing it is worth it? Is my reasoning for relaxing the loads here correct either way? I think it is but I'd rather get a second opinion of course.

[ibraheemdev]

Ah I see, a bummer. According to miri docs the default is already at a high, slow 64

I think that's the default if you pass the flag without a value. A plan cargo miri run will only use one seed.

[ibraheemdev]

I'm not sure this is correct if something like slots_of is used concurrently? I know that's only exposed under salsa_unstable, but the code is currently written such that slots can be accessed across threads (the functions return a slice, not just the specific ID). If we wanted to relax the loads I think we should be clearer about only supporting point-access for previously synchronized slots.

[Veykril]

Hmm, is that a problem? The allocated count only ever increments and we never reallocate the data. allocated here is more of a misnomer I think, what it actually means is slots initialized, so a slice here will never point to uninitialized elements.

You mean the slots_of function here I believe is that right?

[ibraheemdev]

allocated is the flag for a slot being initialized and establishes happens-before, e.g. if i < allocated.load(Acquire) { *slot.get(i) }. This matters if you are reading a slot that was initialized by a different thread, which I believe can only happen with the slots_of function. Otherwise, most slots are tied to a specific ingredient Id which must be allocated by the current-thread. However, even apart from slots_of, this invariant is not clear in the code so I would be wary of relaxing the load.

[Veykril]

fair enough