deadcanard

6 ms·

1.
How HRT patched a binary-only library under time pressure(hudsonrivertrading.com)
2 points by deadcanard 3y ago|0 comments
2.
by deadcanard 3y ago
Take this with a hefty grain of salt. This a one-author paper from a MD that got their license suspended by MA's medical board. The author also pushes some anti vax rhetoric on their website. That does not mean the claims in the paper
3.
by deadcanard 4y ago
2) Agreed about the solvability and difficulty of avoiding cache collisions. DDIO must write its data somewhere in the L3 cache. It ends up in the shareable slice. So either you're okay with sharing your cache or cannot use these slice
4.
by deadcanard 4y ago
Have you tried one the link of the article: https://docs.kernel.org/admin-guide/kernel-per-CPU-kthreads.... ? Also try running "perf stat -d" on your run and see anything pops out
5.
by deadcanard 4y ago
Again, I am biased. But the article explains mem translation in fairly simple terms, hammers the main advantages of HPs (better use of the TLB, simpler and smaller PT). Explains clearly what how much mem the TLB can cover, what a page walk
6.
by deadcanard 4y ago
IMO the easiest way (but certainly not the only way) is to allocate a new stack and switch to it with makecontext(). The manpage has a full code example. You just need to change the stack alloc. This approach has a few drawbacks but is hard
7.
by deadcanard 4y ago
I'd argue that understanding what happens on every single memory access qualifies as fundamental.
8.
by deadcanard 4y ago
I am biased but I don't think it's fair to say that your article covers as much. There is more content in the article written in a way that's trying to be approachable. I certainly will agree it's wordy but it's har
9.
by deadcanard 4y ago
Wrt code, look at the bench in the article. Even with sequential access, you can get a decent speedup using huge pages. But unless you have a good profile and using PGO, it'll likely not be that sequential for code. Like everything els
10.
by deadcanard 4y ago
URL for your article?
11.
by deadcanard 4y ago
CAT is indeed a good thing to look at. But there are some important caveats 1) unless you have a very small number of cores, it's not possible to reserve a cache slice for all programs running (some slices are shared for things like DD
12.
by deadcanard 4y ago
Then, instantiate the smart pointer with a custom no-op deleter and if you use the nt typedef I mentioned above, you'll get a similar compiler output to Rust's. e.g nt_shared_ptr<Data> x(&d, [](Data*) -> void{}); htt
13.
by deadcanard 4y ago
It's because shared_ptr uses an atomic count to synchronise between threads while the Rust version is assuming only one thread. There is no equivalent in the standard C++ lib. Though it's very easy to write one. If you use gcc&#x2