4 ms·
There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your comp
by zanny 10y ago
There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions.
The same concept applies to Vulkan / DX12. The hardware manufacturers will know better than any developers about per-device shortcuts to put into their drivers, and if they do not need to maintain millions of LOCs of OpenGL state machine and validation layers they might find time to optimize the shader compiler to be in the same class of "the compiler is smarter than you" reasons not to use a hard ASM language.
In the case of consoles, all of them are using AMD based graphics, and when the next generation comes out they will all be on a similar cadence of GCN. I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM.
- shmerl 10y ago> I cannot imagine in what world an optimized AMD SPIR-V compiler that AMD already needs to write for the desktop and mobile won't beat 99% of developers on both the Sony / MS / Nintendo and 3rd party sides trying to microoptimize RadeonSI ASM. Good point. Today not to provide Vulkan on consoles is a political diversion (to make cross platform development more costly by taxing developers with doing the same thing multiple times).
- pcwalton 10y ago> There is also the fact that in modern CPU-side development you will find it almost always is a bad idea to try to drop to assembly micro-optimization. Your compiler is going to almost always do a better job optimizing the general case into an optimal set you won't be able to easily implement in raw ASM, especially when you start using vectorization instructions. I agree. In fact, the fact that it's not even a good idea in most situations to write in assembly on x86 CPUs proves the point even more. GPUs are less willing to spend die space on things like sophisticated branch prediction, complex superscalar architectures, register renaming, and so forth. This effectively means that GPUs punish naive codegen (which is the kind of codegen that humans without in-depth knowledge of the architecture tend to produce with their brains) significantly worse than x86 CPUs do. For an extreme example, look at the vector part of the low-power VideoCore IV architecture [1]: compared to a compiler, I don't trust myself for a second to program this optimally. [1]: https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV-Programmers-Manual https://github.com/hermanhermitage/videocoreiv/wiki/VideoCor...