Open source optimized PTS CPU miner (BETA)

[ptsrush]

Hi dga,

ptsminer-dga-beta7-avx2-linux64-static.bin running at 530 cpm on my e3-1230 v3.

RJ is about 0.5% - 1.2%. Very nice.

Now running your miner on all my haswell machine.

In the other hand, ptsminer-dga-beta7-avxsse-linux64-static.bin has 20% RJ very
often. terrible.

minor issue:

when the ptsminer start, seems all workers are print texts at same time
 so screen a little mess. for example:

spawning 6 worker thread(s)
[WORKER[WORKER1] starting
0] starting

Fix it or not, I guess no one really care about that

then some Feature-Request:

At present, the ptsminer output 3 kind of information:
[MASTER], [WORKER] and [STATS]

as a miner, I don't care about [MASTER], [WORKER]. I just want to see [STATS].

"66101067<->34749031 #29878"

No one understand it except you developer, I guess.

I don't want to see "[MASTER] submitted share -> SHARE", since I have VL already.

"[MASTER] work received" is useful, though.

By the way, RJ is reject, ST is stale, what the "VL" is?

And the ST always 0 on my machine.

At last, maybe you should not open source your code. Now @archit start to port
your code back to linux, hell.

In China a packer rebuild your code and earn 20%.

[dclark44]

I upgraded my libraries and left off the mode from the command line and got it to work.

Thanks,
D

[noobster]

it's a centos6 box

Code: [Select]

%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

Ow.  gcc doesnt support avx2 until somewhere in the 4.7 release.  Best suggestion for now is to try the static avxsse binary - does it work for you?

Or if you're on an avx2 machine, upgrade. :-)

Next best is that it's getting higher on the TODO to make it easy to disable avx2 building.

I installed gcc4.7.2 but got the same errors,
I met exactly the same problem when compiling girino's opencl miner,
what version of gcc do you use?

try upgrading your entire system, gcc might not be enough since it uses libraries such as libstdc++ and more

[dga]

it's a centos6 box

Code: [Select]

%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

Ow.  gcc doesnt support avx2 until somewhere in the 4.7 release.  Best suggestion for now is to try the static avxsse binary - does it work for you?

Or if you're on an avx2 machine, upgrade. :-)

Next best is that it's getting higher on the TODO to make it easy to disable avx2 building.

I installed gcc4.7.2 but got the same errors,
I met exactly the same problem when compiling girino's opencl miner,
what version of gcc do you use?

Odd.  I use a more recent one:

gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

This may also be about your version of the assembler, though:

as --version
GNU assembler (GNU Binutils for Ubuntu) 2.23.52.20130913

[mmao]

it's a centos6 box

Code: [Select]

%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

Ow.  gcc doesnt support avx2 until somewhere in the 4.7 release.  Best suggestion for now is to try the static avxsse binary - does it work for you?

Or if you're on an avx2 machine, upgrade. :-)

Next best is that it's getting higher on the TODO to make it easy to disable avx2 building.

I installed gcc4.7.2 but got the same errors,
I met exactly the same problem when compiling girino's opencl miner,
what version of gcc do you use?

[dclark44]

Hi,

I was using beta7 and got the following error message

[MASTER] work received - sharetarget: 03ffffffffffffffffffffffffffffffffffffffff                                                             ffffffffffffffbeefde4d
ptsminer-dga-beta7-avxsse-linux64-static.bin: malloc.c:2369: sysmalloc: Assertio                                                             n `(old_top == (((mbinptr) (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_                                                             offsetof (struct malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old                                                             _size) >= (unsigned long)((((__builtin_offsetof (struct malloc_chunk, fd_nextsiz                                                             e))+((2 * (sizeof(size_t)) < __alignof__ (long double) ? __alignof__ (long doubl                                                             e) : 2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)) < __alignof__ (long d                                                             ouble) ? __alignof__ (long double) : 2 * (sizeof(size_t))) - 1))) && ((old_top)-                                                             >size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Thanks,
D

[dga]

is a new sse4 version going to be available?

i get

core 2 duo t8100 @ [STATS] 2014-Jan-18 21:44:54 | 60.6 c/m | 1.0 sh/m | VL: 502 (83.8%), RJ: 97 (16.2%), ST: 0 (0.0%)

core i3 380um @ [STATS] 2014-Jan-18 21:43:03 | 47.2 c/m | 0.7 sh/m | VL: 409 (85.9%), RJ: 67 (14.1%), ST: 0 (0.0%)

damn i wish I had faster cpu
thanks

Yes.  beta7 is now online for both avx2 and sse/avx. 

There aren't major changes from beta6 for avx2 users;  if you're running really happily, I wouldn't bother upgrading.  The changes are mostly internal to trying to make it easier to build, and to make available the reject-reducing improvements for SSE and AMD CPUs.  It should be even more aggressive for slower CPUs, but it's quite a bit better than it was.  Note:  You may still see a batch of rejects at the very start when the miner switches out of dev-mining mode for the first time.  Just depends on where things were when it switches.

One note:  More individually slower cores will result in a higher reject rate.  I'm seeing this, for example, if I push the hyperthreading too hard, and on AMD CPUs, which have more cores but no hyperthreading, with each core a bit slower.  Not horrible, but something you'll notice.

Updated:  I've also put the Mac build online for beta7, and tried to improve the static-ness of this one so it should be easier to run.  This also meets a second personal goal of mine:  It's now about as fast to mine with the CPU on the Macbook Pro than it is to use the GPU with cudapts.  Take that, cudapts!  It's about time to put the GPU-hardness back in Protoshares.  <grin>  (It does, however, make the fans spin more.)  I'm getting about 200 cpm using 4 threads on MBP, which is pretty close to GPU.  I don't recommend mining on a laptop, though, unless you don't like your laptop.

[noobster]

is a new sse4 version going to be available?

i get

core 2 duo t8100 @ [STATS] 2014-Jan-18 21:44:54 | 60.6 c/m | 1.0 sh/m | VL: 502 (83.8%), RJ: 97 (16.2%), ST: 0 (0.0%)

core i3 380um @ [STATS] 2014-Jan-18 21:43:03 | 47.2 c/m | 0.7 sh/m | VL: 409 (85.9%), RJ: 67 (14.1%), ST: 0 (0.0%)

damn i wish I had faster cpu
thanks

[dga]

beta6 is now available as a dynamically linked build as well.  I think the static is a better way to go in general, but I threw this one up there in case anyone wants to test it.  I've removed the dependencies upon boost_filesystem and boost_chrono (which is the first step towards getting rid of at least one of those darned makefiles, and simplifying compilation on other platforms).

Me being the high-quality software engineering house that I am, there are a few other hopefully-insignificant tweaks in the one I just put online vs the static beta6, 'cause you're just getting builds out of my dev directory as I muddle through this, but (ha ..) nothing that should cause noticeable performance difference.

Happy mining.

[dga]

I'm not native speaker, but maybe in such case guess I should say it's "damn fast"!

Anyway, once a new block start, seems all my 6 worker print "Aborting scan run because of new work."

It's is a little annoying. Could you output them only 1 time?

And sometime it says "Not inserted: <298324783427234980742398> at 7744". Is it OK?

The RJ is about 5% in China. I'm not sure is due to broken internet or something else.

Thanks for these bug reports.  I've fixed both and pushed beta6 for haswell/avx2.

My benchmark hasn't been running long enough to really stabilize, but...

Beta5:   546.7 c/m | 8.7 sh/m | VL: 3937 (97.8%), RJ: 90 (2.2%), ST: 0 (0.0%)

Beta6:   543.0 c/m | 8.7 sh/m | VL: 142 (100.0%), RJ: 0 (0.0%), ST: 0 (0.0%)

I wouldn't read too much into the c/m and sh/m differences - it hasn't been running long enough - but the reject rate is reduced substantially.  The speed should be within 10c/m plus or minus once it's been running long enough to tell.

With more data:  540.2 c/m | 7.8 sh/m | VL: 1219 (99.5%), RJ: 6 (0.5%), ST: 0 (0.0%)

Much better reject rate with beta6.
  -Dave

[dga]

it's a centos6 box

Code: [Select]

%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

Ow.  gcc doesnt support avx2 until somewhere in the 4.7 release.  Best suggestion for now is to try the static avxsse binary - does it work for you?

Or if you're on an avx2 machine, upgrade. :-)

Next best is that it's getting higher on the TODO to make it easy to disable avx2 building.

[mmao]

it's a centos6 box

Code: [Select]

%gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

[dga]

I got some error messages when I compile the source:

Code: [Select]

cc -c -O3 intel/sha512_avx2.S -o obj/sha512_avx2.o
intel/sha512_avx2.S: Assembler messages:
intel/sha512_avx2.S:606: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:607: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:608: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:609: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:618: Error: suffix or operands invalid for `vpaddq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpalignr'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpaddq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpalignr'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsrlq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsllq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpor'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsrlq'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $41,e,y0'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $18,e,y1'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $34,a,T1'why ?

What compiler?  It's possible you're using too old a version of gcc that doesn't understand the avx2 instructions.

[mmao]

I got some error messages when I compile the source:

Code: [Select]

cc -c -O3 intel/sha512_avx2.S -o obj/sha512_avx2.o
intel/sha512_avx2.S: Assembler messages:
intel/sha512_avx2.S:606: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:607: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:608: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:609: Error: suffix or operands invalid for `vpshufb'
intel/sha512_avx2.S:618: Error: suffix or operands invalid for `vpaddq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpalignr'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpaddq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpalignr'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsrlq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsllq'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpor'
intel/sha512_avx2.S:620: Error: suffix or operands invalid for `vpsrlq'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $41,e,y0'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $18,e,y1'
intel/sha512_avx2.S:620: Error: no such instruction: `rorx $34,a,T1'why ?

[dga]

I wanted more ram options so I can experiment a bit with different settings. Say from 512 to 2048 MB per thread adjustable by 256MB… no idea this could take a lot of work maybe.

And you were right about the rejects, beta4 update increased the reject rate to over 30% in my case lol

Gotcha.  The thing to tune isn't RAM - as I said, the goal is actually to solve the problem with as *little* RAM per thread as possible, because it's faster if you can do that.  Google a bit about the TLB and L2 DTLB if you're curious to understand the background behind this.  Some of the big changes between the beta2 and beta5 releases were related to using less memory in order to make things faster.

The thing to play around with tuning is the number of threads.  If you're not also doing GPU mining, you want to use at least as many threads as your CPU has real cores.  But you might also want to use more - but the optimal number is tricky.  On a 4 core CPU, the right answer might be anywhere from 4-7.