Foo_ (foo.delete@this.nomail.com) on January 6, 2020 10:06 am wrote:
> Chester (lamchester.delete@this.gmail.com) on January 6, 2020 9:19 am wrote:
> >
> > So I'm wondering why spinlocks were used in the first place (not necessarily by the author - tons
> > of games use it apparently). My thought is frequency scaling.
>
> My guess is micro-optimization obsession. Having worked previously with video games developers
> (admiteddly long ago), my experience is that some of them think they are smarter than experts
> - smarter than compiler authors, smarter than standard libary developers, etc. They will insist
> to express possible micro-optimizations explicitly, and their C++ looks like assembler code.
> Often those people were (former or current) demomakers. So I'm not surprised that some video
> game developers would sprinkle their code with hand-written spinlock implementations.
>
> /rant end :-)
>

No on both counts. Frequency scaling is a side effect, and it's not a micro-optimization obsession. It's to remove bubbles from task scheduling pipelines. If you know a resource is going to become available soon, but not just yet, then waiting on its lock is a very expensive operation. If you know that the resource is locked by an operation occurring on a different CPU core, you can instead spin on the lock with much less wasted time (tens of cycles, instead of hundreds or thousands - or worse if another thread gets scheduled in its place and then runs for a full quantum).

This only applies is you know the system you're running on, and can hard-affinitize work to specific cores.

And your assumption about gamedevs is a little eyebrow raising. They typically have different use cases, goals, and priorities than standard library authors, compiler authors, OS implementors et al. For example, std::chrono and std::mutex in their first couple of rounds of implementations had much worse performance than existing OS primitives. Games try not to allocate memory from the system while running in order to avoid indeterminism caused by the call... and so on. Because they're developing code to run in soft-realtime (or in some cases hard-realtime) environments, they have very different needs.