4 ms·
I might suggest thinking along the lines that hardware engineers reject many features because of other constraints that impact the processor. The failure of th
by barkingcat 6y ago
I might suggest thinking along the lines that hardware engineers reject many features because of other constraints that impact the processor.
The failure of the larrabee team to bring something competitive to the market a decade ago doesn't necessarily imply it will become competitive just because it was brought "on-chip" instead of as an additional card or a co-processor.
If it worked all that well, it would be a product of its own, able to compete against Nvidia in GPU and GPGPU tasks.
- corysama 6y agoAn example of what we are talking about is _mm_dp_ps (4-component dot product). It was heavily requested by game devs for SSE2 but didn't show up until 4.1. And, even then it wasn't much better than hand-rolling it with old instructions. The hardware engineers were "correct". It's a difficult instruction to make fast compared to completely independent mul-adds. Game devs "should just" re-architect their code to not deal with small situations individually and instead be more bulk-data-processing like SPECfp because that's what's friendly to the hardware. But, that's dismissing how the software actually worked --especially back then. 16 years later, many, but far from all of AAA game engines more closely resemble SPECfp. But, all along the way, and in tons of 3D graphics and gameplay code still today, it would have been nice to reliably have one of the most common and fundamental operations in games well-baked into the chips.