Hacker News Reader

Comment by fallat | Hacker News Reader

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) ?

View on HN

Strength 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.

I 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.

I like -Wa,-adhlns=foo.lst -g to see the C, asm, and machine code all together.

Hand written 294 lines vs. gcc -O3 526 lines. 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.

For 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.

Reply on news.ycombinator.com