4 ms·
It's almost always better to start with a compiler-generated critical section and see if there are possible hand optimizations. Yeap. But once you do, it's alm
by ktRolster 9y ago
It's almost always better to start with a compiler-generated critical section and see if there are possible hand optimizations.
Yeap. But once you do, it's almost always easy to get some efficiency gains, because you understand what the code intends, and the compiler does not.
Surprisingly it doesn't take much experience to do this: just a profiler, and a willingness to try different things until you find something that works.
- bachmeier 9y ago> you understand what the code intends, and the compiler does not It seems to me that the best approach to this would be to feed more information to the compiler rather than writing assembly yourself. Otherwise you give up portability.
- mikeash 9y agoThat's generally better when it's possible, but it's not always possible. If you do start writing assembly, you usually want to have it exist next to a higher-level version of the code that you can toggle on and off. This lets you maintain portability (just compile the higher-level version on platforms where you don't yet have assembly) and makes it easy to try out new optimizations that wouldn't require assembly.
- carussell 9y agoSee http://cr.yp.to/qhasm/literature.html http://cr.yp.to/qhasm/literature.html
- ktRolster 9y agoYou are right. A lot of times you can rearrange the code in various ways, and the compiler will happily generate more efficient code. When that's not possible, the way to keep it portable is by writing a generic C function, then writing an optimized version of the same function that will be compiled when that architecture is available. At work it's rare to need to compile the same code for various architectures, but sometimes it happens.