choudanu4
Joined 11 years ago
Joined 11 years ago
https://doc.rust-lang.org/nomicon/phantom-data.html
https://doc.rust-lang.org/std/marker/struct.PhantomData.html
So
struct Sender<S> {
/// Actual implementation of network I/O.
inner: SenderImpl;
/// 0-sized field, doesn't exist at runtime.
state: S;
}
I believe could become struct Sender<S> {
/// Actual implementation of network I/O.
inner: SenderImpl;
/// 0-sized field, doesn't exist at runtime.
_marker: PhantomData<S>;
}
I've never used this PhantomData personally, so this might be wrong. Cheers!I found this paragraph confusing, is it talking about data prefetchers (Which would make sense b/c of the mention of short prefetches) or branch predictors? (Which would make sense b/c of the mention of TAGE and Perceptron)
I'm not as clear on the history, but was Linux ever pitched as capable of being real-time OS? I don't think so. The hard requirements for real-time generally lead to very different systems than general-purpose operating systems.
[1] https://en.wikipedia.org/wiki/Real-time_operating_system
Don't despair, I think we do care. :)
- Branch Predictor
- Cache Replacement Policy
- Memory Prefetcher
- Schedulers
So for whatever cores are enabled on each die, you get the L1/L2 caches for each core as per the Ryzen launch. Additionally, you get all of the shared L3 cache, irrespective of the number of cores disabled per core complex. This pattern follows across all four dies in each socket.
LLCs often are exposed to access streams where the temporal locality (which is the assumption that makes LRU good) has been filtered out by earlier caches.
For that reason, newer cache replacement policies such as RRIP, SHiP, and Hawkeye have significant headroom to improve upon LRU (and PseudoLRU).
I was thinking this would be pretty cool to use for debugging device drivers on embedded devices especially w.r.t latency.