5 ms·
Doing most of your changes made essentially no difference X) I suspect the assembly generated by the compiler is pretty fancy. Edit: Just briefly looking at t
by fallat 6y ago
Doing most of your changes made essentially no difference X)
I suspect the assembly generated by the compiler is pretty fancy.
Edit: Just briefly looking at the objdump again, gcc is using a lot of scalar variants of instructions, instead of vector. Maybe this is giving the CPU better hints?
Maybe my code would run better on a more modern CPU (while still constraining the original C program to SSE3 only) ?
- jdsully 6y agoStrength reduction and algorithmic changes will make the most difference, but that requires a much deeper look at the code. I wouldn’t be surprised if the compiler found a way to reduce the number of divisions. If you have a lot of practice the compiler is not difficult to beat. But it definitely takes some effort and study of the optimization manuals.
- alecco 6y agoHand written 294 lines vs. gcc -O3 526 lines. https://godbolt.org/z/yEcMKf https://godbolt.org/z/yEcMKf At a first glance, it seems the compiler version is better at hiding the latency of some of the div instructions. It might be hiding memory access latency, too. But that's more involved analysis.
- msla 6y agoI don't know why you're using objdump instead of -S to have gcc generate assembly directly. You get named constants and named labels that way, and you can even choose the sane Intel syntax with -masm=intel which you can also do with objdump.
- kragen 6y agoI like -Wa,-adhlns=foo.lst -g to see the C, asm, and machine code all together.
- Phylter 6y agoFor x86-64 compilers will use intrinsic instructions which will automatically optimize for that processor. Unless you're really good at knowing the processor you're almost always better off doing it like this. It's almost no benefit writing assembly because of these optimizations these days.