I've made a research on the commit that the NoodleDoodle has claimed to make publicly available. And you know what, I have found something very weird.
Experiment
Core I5, Windows.
Two attempts
1) Binaries compiled from the source code that NoodleDoodle committed yesterday.
2) Pre-compiled binaries that were spread on this topic.
Results
Hashrate:
1) Compiled binaries: 8.3 - 8.9 hr/s
2) Pre-compiled binaries: 15.1 - 15.5 hr/s
Come on guys, this stinks! Aren't you lying again?
My questions:
1) How exactly can the hash rates differ by the factor of 2 if they are on the same code? (Hint: it is impossible).
2) Why do the "team" claim that they've made the source code publicly available when they actually hide the real optimization?
3) Doesn't this mean that instamine is actually going on?
4) How much more the "team's" miners are optimized?
I guess, explanation is required.
Everyone is welcome to try it out themselves.
I ran the same test on my dedicated boxes (mostly Xeon E5-2620 v2 processors) on Ubuntu 12.04. Hashrate pulled from screenlog (screen -L) and averaged after an hour of mining. Boost 1.55 is installed from source, and built with gcc 4.8. The results:
1. Original build from source: 9.8741h/s
2. Original build from source w/ march=native, -funroll-loops: 10.2491h/s
3. Pre-compiled binaries from this topic: 20.7734h/s
4. Build from updated source: 21.8741h/s (faster than pre-compiled binaries!!)
5. Build from updated source with constants instead of divs: 22.8004h/s
6. Build from updated source with constants instead of divs, w/ march=native, -funroll-loops: 23.0526h/s
Out the box the changes NoodleDoodle committed are faster than his precompiled bins. I am not building with icc at this stage, but that might give a slight improvement.