I like the miner for its simplicity (and is also a bit faster than standard bitcoin program).
While using this miner in the pooled mining I came across a few problems and I'd like to offer suggestions.
First one is in the code that reads the work
val = json_rpc_call(rpc_url, userpass, rpc_req);
if (!val) {
fprintf(stderr, "json_rpc_call failed\n");
return NULL;
}
If there is a network or server problem, the client will fail and it happens quite frequently with pooled mining. I changed
return NULL; to some sleep and
put it in a loop to wait until the network is up again. After such modification (and similar in
submit_work) the client survived several server restarts.
Another suggestion is in the 4way code. The code will not compile with Intel Compiler due to non-standard use of bit operations. If you change the lines that define macros to:
static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {
return _mm_xor_si128(_mm_and_si128(b,c),_mm_andnot_si128(b,d));
}
static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {
return _mm_xor_si128(_mm_xor_si128(_mm_and_si128(b,c),_mm_and_si128(b,d)),_mm_and_si128(c,d));
}
static inline __m128i ROTR(__m128i x, const int n) {
return _mm_or_si128(_mm_srli_epi32(x, n),_mm_slli_epi32(x, 32 - n));
}
static inline __m128i SHR(__m128i x, const int n) {
return _mm_srli_epi32(x, n);
}
/* SHA256 Functions */
#define BIGSIGMA0_256(x) (_mm_xor_si128(_mm_xor_si128(ROTR((x), 2),ROTR((x), 13)),ROTR((x), 22)))
#define BIGSIGMA1_256(x) (_mm_xor_si128(_mm_xor_si128(ROTR((x), 6),ROTR((x), 11)),ROTR((x), 25)))
#define SIGMA0_256(x) (_mm_xor_si128(_mm_xor_si128(ROTR((x), 7),ROTR((x), 18)), SHR((x), 3 )))
#define SIGMA1_256(x) (_mm_xor_si128(_mm_xor_si128(ROTR((x),17),ROTR((x), 19)), SHR((x), 10)))
it will compile with both gcc and icc. I hoped for a significant speed-up but for me Intel compiler is only about 10% faster on only one of my machines (Core i5) and slower on Core 2 and Opteron. Nevertheless, the code is more universal. Isn't a similar code used also in the main bitcoin cruncher?
Last issue is very mysterious and I may have come across a strange race-condition bug in GLIBC (or something else) on my Cent OS. The program randomly segfaulted in multithreaded mode while working fine in single-threaded one and working OK on my another Ubuntu machine. Long story short, it seems it was related in name resolving and I (hopefully) solved the problem by compiling libcurl with --enable-ares, which uses an asynchronous name resolution.
