compiler/assembler optimizations possible?

[ixfd64]

It seems that a stable release of Prime95 26.x may become available soon. Notably, version 26.x is going to feature (among other things) optimizations for various CPU architectures.

However, some people report getting faster iteration times simply by changing the way Prime95 is compiled. See this post, for example.

Does Prime95 26.x use these optimizations? If not, then an additional 5-10% increase in performance would be quite nice!

[Prime95]

Originally Posted by ixfd64

However, some people report getting faster iteration times simply by changing the way Prime95 is compiled.

I put little stock in such reports. All the CPU intensive code is in assembly language. Recompiling C code will not affect timings.

[CRGreathouse]

Originally Posted by Prime95

I put little stock in such reports. All the CPU intensive code is in assembly language. Recompiling C code will not affect timings.

Or, more precisely: the amount of time saved by recompiling will be smaller than that spent recompiling. :)

[tichy]

Originally Posted by ixfd64

See this post, for example.

Yes, these were bogus effects. For some reason deviation if timings was more frequently on favour of recompiled binary than the official one.

However, back in december I started tackling the assembler part of mprime. When I reach something more interesting than 1-tick speedup of 32-bit =<74bit factoring code I will share it here. Right now my priority is porting as much as I can to NASM. GAS already proved a viable alternative to MASM, but the chores of adding debugging symbols (I used STABS directives) was to much troublesome.

[tichy]

Originally Posted by tichy

bogus

This is a wrong word - not being a native english speaker leads sometimes to such mistakes. I needed an adjective which means that the observed timings improvements were not intrinsicaly related to the code itself but were merely result of the environment the code was ran in.

[axn]

Originally Posted by tichy

This is a wrong word - not being a native english speaker leads sometimes to such mistakes. I needed an adjective which means that the observed timings improvements were not intrinsicaly related to the code itself but were merely result of the environment the code was ran in.

In the context that you used, it fits perfectly.

[cheesehead]

Originally Posted by tichy

This is a wrong word - not being a native english speaker leads sometimes to such mistakes. I needed an adjective which means that the observed timings improvements were not intrinsicaly related to the code itself but were merely result of the environment the code was ran in.

It wasn't deliberately bogus, which would have implied deception. It was unintentionally, accidentally (and unknowingly, at that time) bogus -- and most readers would understand that.

[henryzz]

Originally Posted by cheesehead

and most readers would understand that.

Maybe not some non-native english speakers.