It depends on how many speed-critical parts a program has. If you have 15 hashes, of which you can change 10 without the program hitting compilation problems, and you are experimenting with 4 compilers, it may go up to 60 times or even 200+ times once you start tuning cflags for each.

If you focus on tuning 2-3 pieces of code (files), it's way faster. At most 12 compilations. But then you are tempted to start playing around with different sets of CFLAGS for each, and you end up spending your time anyway


Trial and error at the file level switching compilers (and flags), per file.


Both intrinsics and asm implementation tend to exceed plain .c by quite a margin. The compiler can only make a difference in less optimized pieces of code...


Indeed.


Yeah I'm similar in that regard, although with a shorter-time gap (last time I was doing it seriously it was on 16bits). In general, all algos have multiple implementations for multiple instruction sets, with c, intrinsics, asm, etc. So I wouldn't try to reinvent the wheel in this regard - as there are extremely competent people actively optimizing these hashes and providing multiple implementations for multiple instruction sets.

I anticipate that the big gains (for cpu mining) will be when hashing starts going in batches of 2 or 4 at the same time, instead of 1 per thread. Trying 2 or 4 candidates each round will allow proper vectorization, by packing the data from each step of the process in wide registers, and then processing them with packed simd instructions (instead of scalar, as it is done most of the time right now).

Intel did a sha256 in that way, by loading multiple hashes together on the AVX registers so that all the steps can be executed with less commands: https://lwn.net/Articles/692605/

"On multi-buffer SHA256 computation with AVX2, we see throughput increase up to 2.2x over the existing x86_64 single buffer AVX2 algorithm."

...if we were to ever implement something like that, it would be quite a change because most, if not, implementations are for single-data rounds and the software itself is based on a logic of processing 1 hash every time. As Xeons with AVX512 start coming online, these will need it even more - because those would be able to load twice the data on their registers and process them with just one command. This is a job that would probably pay very good money if one was to make such a miner - because it would take the throughput 2x+ upwards. I guess for many it would be just easier to port the code to opencl and create GPU miners instead. And now thinking about this, it may even be possible to use multiple-buffer implementation on each thread of the GPU to increase the throughput there also, provided the SIMD registers are wide enough to take multiple data (I guess it will depend on the gpu architecture).

hi,

tried to compile it and it fails, does onyone know what the Problem is?

In file included from algo/echo/aes_ni/vperm.h:20:0,
                 from algo/echo/aes_ni/hash.c:21:
/usr/lib/gcc/x86_64-linux-gnu/5/include/tmmintrin.h:136:1: error: inlining failed in call to always_inline ‘_mm_shuffle_epi8’: target specific option mismatch
 _mm_shuffle_epi8 (__m128i __X, __m128i __Y)
 ^
In file included from algo/echo/aes_ni/hash.c:21:0:
algo/echo/aes_ni/vperm.h:52:5: error: called from here
  t1 = _mm_shuffle_epi8(*((__m128i*)table + 1), t1);\
     ^
algo/echo/aes_ni/hash.c:385:4: note: in expansion of macro ‘TRANSFORM’
    TRANSFORM(_state[j], _k_opt, t1, t2);
    ^
Makefile:2445: recipe for target 'algo/echo/aes_ni/cpuminer-hash.o' failed
make[2]: *** [algo/echo/aes_ni/cpuminer-hash.o] Error 1
make[2]: Leaving directory '/home/customer/cpuminer-opt-3.4.6'
Makefile:3462: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/customer/cpuminer-opt-3.4.6'
Makefile:661: recipe for target 'all' failed
make: *** [all] Error 2

The moves are usually relatively inexpensive in terms of time compared to the processing part, so I wouldn't worry that much. I was doing some googling to check sha256 and 512 for avx512, and I found this in the openssl site: https://rt.openssl.org/Ticket/Display.html?id=4307

...where an intel software engineer is submitting optimized algorithms... he says over 2x for avx512.

The benchmarks are also quite interesting (the numbers should be up to avx2*)

Architecture: SHA256 Serial | SHA256 MultiBlock
HSW: 7.82 cycles/round | 2.99 cycles/round
BDW: 7.82 cycles/round | 2.85 cycles/round
SKL: 7.73 cycles/round | 2.59 cycles/round

Architecture SHA512 Serial | SHA512 MultiBlock
HSW: 5.43 | 3.79
BDW: 5.35 | 3.64
SKL:  5.23 | 3.42


* I had seen a pdf or powerpoint, I can't find it right now, but it should be from the same Intel guy, where with avx512 it went down to ~1.something cycle/round for multiblock sha256. I think it was a projection/simulation run due to lack of chips.

Hi,

i just didautogen.shconfigure and then make

CPU is this:

bugs      :
bogomips   : 5201.40
clflush size   : 64
cache_alignment   : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor   : 31
vendor_id   : GenuineIntel
cpu family   : 6
model      : 45
model name   : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
stepping   : 6
microcode   : 0x615
cpu MHz      : 1199.960
cache size   : 20480 KB
physical id   : 1
siblings   : 16
core id      : 7
cpu cores   : 8
apicid      : 47
initial apicid   : 47
fpu      : yes
fpu_exception   : yes
cpuid level   : 13
wp      : yes
flags      : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid xsaveopt
bugs      :
bogomips   : 5201.40
clflush size   : 64
cache_alignment   : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

how can I mine on my core i5-2520M ?
It hangs after Windows 7

cpuminer-opt v3.4.7 released

Source code: https://drive.google.com/file/d/0B0lVSGQYLJIZano2UmdqN2tfWXM/view?usp=sharing

Windows binaries: https://drive.google.com/file/d/0B0lVSGQYLJIZRGVIMkpZdjdWRm8/view?usp=sharing

Fixed benchmark except x11evo.

Added CPU temperature to share submission report on Linux.

Edit Now of git: https://github.com/JayDDee/cpuminer-opt

Do you see this?
[2016-09-22 11:10:26] Accepted 7/7 (100%), 4824 H, 77.64 H/s

You're mining at 4824 H/m.
Wallet showing H/m, cpuminer H/s.
80H/s*60s=4800H/m

I've just uploaded cpuminer-opt 3.4.7 to git

https://github.com/JayDDee/cpuminer-opt

Yay!   
Now all my Linux miners will get faster updates!

Thanks joblo