MattKC has some interesting content from time to time, like this project he worked on. But I find a decent number of his videos to be weirdly click-bait hell, like the video about installing Windows 98 on a modernish ThinkPad (using CSM - which isn't all that interesting or exotic and seemed to exist to game the Youtube algorithm for clicks) or about a video he put out a few years ago about Super Mario 64 not being optimized, with the implication that Nintendo willfully neglected to disable debug symbols in the final build of the game.
However, the reality is far more nuanced than he was letting on. The likes of Kaze Emanuar set the record straight, and actually did a proper deep dive into optimization for the game (and not just by passing a -O2 compiler flag I might add). I'd say take MattKC's channel and content with a grain of salt.
If you found the video on Super Mario 64 being published with debug symbols interesting, check this out: After finding out about the debug symbols, a developer took a deeper dive through the codebase and optimized the ever living hell out of to get 60fps+.
FIXING the ENTIRE SM64 Source Code (INSANE N64 performance)
I think you're being uncharitable. What Kaze does is very different type of optimization and I don't see how it negates (or even relates to) MattKC's analysis of the -O situation? Nintendo did indeed deliberately NOT pass the higher -O flag, MattKC was right. Kaze himself did analysis and came to the conclusion that it was likely because Nintendo wasn't confident it wouldn't introduce bugs, and the game ran fast enough as is. Of course with the power of 30 years better hindsight and tooling, we now know that compiling with the highest -O flag would have been fine.
I think to me it was the premise of MattKC's video that made me question whether or not this was some massive smoking gun. Like you said, the game ran fast enough, and Nintendo wouldn't willfully ship crap out, especially considering this was a flagship title. I still maintain that the compiler flag thing felt more like a MacGuffin for the sake of getting another clickbait video out. Even Nintendo themselves did end up using the compiler flag on the PAL region variant of SM64, which did help performance a bit, but wasn't some major gamechanger (no pun intended) in the end.
I even say this as someone who generally isn't a fan of Nintendo from the perspective of their corporate policies. I don't think Nintendo did anything wrong here, especially given how new this system and the brave new world that was 3D gaming in the home was at the time for them.
Watched this a couple of days ago and was just telling someone about it earlier today...
The technical content is really engaging (the "joy"/"frustration" of digging in some ancient technology for no easily justifiable reason--though in this case...) and there's been a heap of work put into merging the technical deep dive with a cinematic narrative that helps communicate some of the experience of what it feels like when you're three days in trying to find a piece of a puzzle someone probably hasn't cared about in 20+ years. :)
InterlockedCompareExchange is supposed to be an atomic compare-and-swap API. "Compare-and-swap" means the swap only occurs if the comparison succeeded, ie if the previous value of `*dest` was `compare`, then `xchg` is written to `*dest`. "Atomic" means that another thread cannot make changes between the two steps; if another thread did come in and modified the value between the comparison and the swap, the swap would not occur.
A proper implementation would use some kind of locking in the worst case, but usually would rely on hardware features to provide this atomicity. For example, on x86 this is done by the CMPXCHG family of instructions.
The mock implementation is not atomic. Another thread can change the value between the comparison and swap and the swap will still happen. As for the fix, there might be an intrinsic for it in the W95 SDK, or worst case an inline assembly implementation using CMPXCHG would do the job.
Wouldn't it've been easier to compile mono for Windows 95 instead of spending countless hours debugging an ancient release of .net without any sort of debug symbols?
However, the reality is far more nuanced than he was letting on. The likes of Kaze Emanuar set the record straight, and actually did a proper deep dive into optimization for the game (and not just by passing a -O2 compiler flag I might add). I'd say take MattKC's channel and content with a grain of salt.