This is what I came here to say. With comments in the article such as:

"CPU designers see vastly more benefit to spending area on, e.g.,vectorized floating-point multipliers."

followed by "Intel is doubling the vector size in its newest CPUs---again!---this time from 256 bits to 512 bits."

Seems like they are being optimized to be better at vector math, and games just happen to highly use these pieces of HW.

> Seems like they are being optimized to be better at vector math, and games just happen to highly use these pieces of HW

More likely the other way around ...

Given that games tend to be deployed on a wide range of computers, it's hard for them to use newer x86 extensions (e.g. AVX), while most scientific computing applications tend to be compiled for a specific machine. To get to see the larger improvements, you must use the newer instructions and registers, like you can see in BLAS benchmarks[1].

[1]: https://www.bountysource.com/teams/openblas/fundraiser

Yep, at my old job we still had to support Windows XP 32 bit for the game client (internal tools were Windows 7 64 bit) as so many people were still playing on systems. I don't remember if we could use SSE2 or what the minimum was in that regard.

Some compilers support multiple codepaths depending on the supported instruction set. Intel's C++ compiler makes this easy, for instance.

> Seems like they are being optimized to be better at vector math, and games just happen to highly use these pieces of HW.

It may in fact be that desktop/mobile CPUs are being optimized for their contemporary benchmark suites, thus targeting the ensuing benefits in marketing. The benchmarks themselves were, for a fair amount of their existence, focused on games-related performance, at least from what I recall.

I don't mind the downvotes, but more interested to know why if anyone cares to comment? I should have specified that by desktop/mobile, I do mean desktop/laptop essentially (and, not smartphone CPUs). And, I am talking about Intel/AMD largely, and how I perceive their evolution over the past two and half decades.

In short, I think "optimizing for games" means nothing to a CPU designer at say Intel, and anyways qualitative differences (expanding the ISA, or integrating new features on the IC) are more expensive to develop and sometimes tricky to market. Instead, marketing quantitative differences is much easier (hence optimize for benchmarks) - though arguably no easier to develop. Witness Intel's first rocky attempt at targeting the benchmarks in the early 2000s: Netburst [0]. Of course, in the past 5 years, things have changed (the rise of smartphones, meteoric rise in GPU performance with expanding markets & new software, CPU "per core" performance stagnation), so Intel is in the process of re-positioning itself.

[0] https://en.wikipedia.org/wiki/NetBurst_(microarchitecture)

My experience is that double precision is very common on demanding game areas, notably physics. I recall older versions of the ODE physics engine recommending and defaulting to double precision and lots of newbies on the forums being surprised there wasn't much performance difference. That was all some time ago.

My experience is that it's extremely uncommon, including on physics systems. While I no longer work in games, I did for several years, I probably can count the times that I used double precision on one hand (if you exclude the JavaScript work that plagued the end of my game development career).

The reason for this is simple -- it's twice as slow. The vector width is half the size, and so you can do half as many operations at a time.

My experience is just as an amateur, so it's only worth so much. I'm pretty sure though that the difference was much less than a factor of two.

Probably because double precision floats are just as fast as single precisions if you don't vectorise. I bet you didn't.

This would also explain for instance why many programming languages drop single precision floats altogether: they don't plan to vectorize in the first place.

Yeah, it looks like ODE doesn't use SIMD or anything, and hence performs poorly compared to more modern engines: http://blog.wolfire.com/2010/03/Comparing-ODE-and-Bullet

A pretty solid rule of thumb is that 32 bits has enough precision for rendering, physics needs doubles if it's going to use a lot of iterations. Simplified models like Super Mario jumps or the tractor beam in "Thrust" (single rigid joint) can get away with 16-bit fixed point precision.

OTOH rendering of geometry only needs about as much precision as the display offers, which often means 8 bits on older hardware.

So then you better optimize your algorithms and apps for a world where CPUs are good at single-precision BLAS stuff.

Which is funny, because games would have benefited more from half (16 bit floats) HW support. There is almost no support on CPUs (X360's CPU had conversion to and from half, IIRC, and ARM in handhelds supposedly supports full half arithmetics), even less on x86/x64 CPUs specifically.

The comedy here is that AMD and NVIDIA are adding it to CPU and GPU designs for the benefit of DNN training workloads; something that took off because of hardware designed for video games ;)