@pervognsen.mastodon.social.ap.brid.gy
I like programming and understanding how stuff works. My background is in systems programming and game development.
🌉 bridged from ⁂ https://mastodon.social/@pervognsen, follow @ap.brid.gy to interact
@pervognsen.mastodon.social.ap.brid.gyJust finished mission 10 (out of 30) and still loving it but taking it slowly. On that note, one thing I don't love is having 10 click-through splash screens every time I launch the game.
@pervognsen.mastodon.social.ap.brid.gy@dpiponi (And if you take the coward's way out by doing quotient estimation with binary search, you might as well do binary division.)
@pervognsen.mastodon.social.ap.brid.gy@dpiponi As an aside, the first time I had to implement non-binary division in a computer, I realized that the long division "algorithm" we were all taught is missing an algorithmic component for what Knuth calls quotient estimation to turn it into an actual algorithm; it just so happens that […]
@pervognsen.mastodon.social.ap.brid.gyIf you updated Firefox and wondered what the hell happened to the UI like I did, open about:config and set browser.nova.enabled = false.
@pervognsen.mastodon.social.ap.brid.gy@kha I'm partial to the next level of pastel de nata where you add a cream cheese crust, so it's basically a miniature cheesecake egg custard tart.
@pervognsen.mastodon.social.ap.brid.gy@rudi "Paying it forward" could mean something like publishing the now-uncapped-refcount copy with an atomic pointer CAS to replace the capped-refcount original, so future readers don't have to make their own copy. That would turn an overflowing reader into a writer of a new version that happens […]
@pervognsen.mastodon.social.ap.brid.gy@rudi There's a flaw with the analysis in the concurrent case, similar to the naive version of this kind of thing that Okasaki covers in his book on functional data structures, which is that multiple readers can trigger the same worst-case cascade off of a shared refcount-capped copy and so one […]
@pervognsen.mastodon.social.ap.brid.gy@rudi You can prove that an overflow-triggered copy of a bounded-refcount node takes amortized O(1) time and space, assuming nodes of size O(1). In the case of a 1-bit refcount on a linear chain of nodes, it behaves exactly like incrementing a binary counter; the amortized time/space cost is […]
@pervognsen.mastodon.social.ap.brid.gy@dpiponi Joining the illustrious company of North Korea and Saudi Arabia as one of the few places in the world to still have public executions by the state.
@pervognsen.mastodon.social.ap.brid.gyHere's a programming trick that can come in handy. For reference-counted copy-on-write nodes, you can get away with an unusually small number of refcount bits. When the refcount for a particular node is capped, you just make a copy instead of incrementing the refcount. Even the 1-bit refcount […]
@pervognsen.mastodon.social.ap.brid.gyWe are so back.
@pervognsen.mastodon.social.ap.brid.gyI'm already pipelining to fill the fan-in/fan-out utilization hole across frame boundaries, but that's just for the per-rasterization work, and the main thread is currently responsible for the present() and therefore waits for the last raster task to finish. So that kind of pipelining doesn't […]
@pervognsen.mastodon.social.ap.brid.gyI guess another option in this particular case is a variant of triple buffering where you let straggler threads finish their tasks targeting the old frame's buffer while the rest of the threads move on to the next frame's buffer. The last straggler thread to leave a frame would have to do the […]
@pervognsen.mastodon.social.ap.brid.gyThis is with a thread pool of size n-2 so I'm leaving an entire core to the desktop compositor and any other background system tasks. Interference effects are way more frequent and severe with n-1 or n. But at some point adding more slack to accommodate the rest of the system is only going to […]
@pervognsen.mastodon.social.ap.brid.gyAny time I see this kind of thing, it makes me want to do a wait-free helping scheme. In this case it happened far enough from the end of the frame that it didn't lead to tail latency but sometimes it does. With tile-based rendering it should be pretty easy […]
@pervognsen.mastodon.social.ap.brid.gy@wingo Do you feel that way about planned obsolescence in general? There is definitely a strong incentive to demonstrate a step-change to existing users when a new model launches, and humans suffer from recency bias. E.g. maybe continuous training "degrades" the model over time vs the offline […]
@pervognsen.mastodon.social.ap.brid.gyPer-core power usage is 0.3 W for MWAITX (the C0 vs C1 variant is only +/- 0.02 W) vs 1.8 W for PAUSE, so it's a pretty big difference if you care about such things. It's still going to count as busy to the kernel, hence why you always want to use MWAITX (the version with a timeout) so you can […]
@pervognsen.mastodon.social.ap.brid.gyI went back and checked "just as good on latency" because while it's true that on the real workload it was "just as good" I hadn't actually done an isolated head to head measurement. So here are some measurements: PAUSE spinning with a load is 40 ns wake-up latency, MWAITX wake-up latency is 140 […]
@pervognsen.mastodon.social.ap.brid.gyI wouldn't say I've root-caused it to my satisfaction but I've known from the beginning that the slower binaries are more front-end limited and op cache misses and iTLB misses are higher, but I suspect the iTLB misses are a downstream effect of the op cache misses. I guess the op cache must be […]
@pervognsen.mastodon.social.ap.brid.gyI know with near certainty it's the physical placement at fault because, aside from byte-exact copying, POSIX_FADV_DONTNEED on a file will reshuffle the physical placement relative to the original placement when you next run it, and you immediately see the performance effects. Anyway, no-one […]