Wow this is a really excellent and comprehensive overview.
Just to calibrate my own intuition, would anyone who was mostly unfamiliar with these concepts be able to weigh in on how much of this post they grokked?
On the earliest web archive snapshot I can find [0], I do not see any mention of the safeguard/sabotage under discussion [1].
And to be clear, this isn't the safeguard where the model is explicitly downgraded to Opus, but rather where the Fable/Mythos model's "effectiveness" is transparently "limited" via "prompt modification, steering vectors, or parameter-efficient fine-tuning (PEFT)".
to preempt a discussion emerging based on the title alone, here’s their summary:
> While nuclear fusion power is often hailed as a future source of abundant, clean energy, current dominant fusion designs, magnetic and laser inertial, are unlikely to become competitive due to their expected low experience rates. Accordingly, policymakers should not rely on, or fund, fusion power as a core pillar of future clean energy systems unless designs with different characteristics are developed.
1. tcmalloc is actually the only allocator I tested which was not using thread local caches. even glibc malloc has tcache.
2. async executors typically shouldn’t have tasks jumping willy nilly between threads. i see the issue u describe more often with the use of thread pools (like rayon or tokio’s spawn_blocking). i’d argue that the use of thread pools isn’t necessarily an inherent feature of async executors. certainly tokio relies on its threadpool for fs operations, but io-uring (for example) makes that mostly unnecessary.
on the OS scheduler side, i'd imagine there's some stickiness that keeps tasks from jumping wildly between cores. like i'd expect migration to be modelled as a non zero cost. complete speculation though.
tokio scheduler side, the executor is thread per core and work stealing of in progress tasks shouldn't be happening too much.
for all thread pool threads or threads unaffiliated with the executor, see earlier speculation on OS scheduler behavior.
modern tcmalloc uses per CPU caches via rseq [0]. We use async rust with multithreaded tokio executors (sometimes multiple in the same application). so relatively high thread counts.
Just to calibrate my own intuition, would anyone who was mostly unfamiliar with these concepts be able to weigh in on how much of this post they grokked?