Open source optimized PTS CPU miner (BETA)

[archit]

Why not AVX2 for SHA256 as well?

Why bother?

Won't improve anything?

[dga]

Why not AVX2 for SHA256 as well?

Why bother?

[archit]

Why not AVX2 for SHA256 as well?

[dga]

Is there any reason not to make it perm by putting vm.nr_hugepages = 2048 in sysctl.conf?

It's what I do on my machines.  It may tie up a little more memory on your system, but if it's used for a lot of mining, it's a good plan.

My miner uses them less than yam does, I believe, so you'll get a boost on yam also, if it's not going under the covers and enabling them for you. :-)

  -Dave

[zvs]

Looked like it was faster than yam on my two junk servers, but slower on the rest

it was also dumping cores everywhere with mmap failing

Thanks for the report.  The mmap failure is just a warning - it falls back to malloc.

To silence - and run a little faster with both yam and my code - run:

echo "2048" > /proc/sys/vm/nr_hugepages

But the dumping cores is bad.  Could you send me a little more detail, or a stack trace?  (And on what kind of machine?)

The slower on the rest isn't too surprising.  There are a lot of optimizations to be done yet, particularly for huge servers with respect to thread affinity and other things.  And the SHA512 code is virtually untouched from the Intel release.  The goal isn't to beat yam with this release, it's just to start the ball rolling a little bit.

There are some constants to play with to tune for different platforms, but it's not worth going there yet (unless you're interested in poking in the code).

  -Dave

Hmm, I'll try it out again later tonight.  I did check  /proc/sys/vm/nr_hugepages and it comes back as 0, yet proc/meminfo shows:

AnonHugePages:   4194304 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

and afterwards:

AnonHugePages:   4194304 kB
HugePages_Total:    2048
HugePages_Free:     2048
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

....  so even though it had the size allocation, it couldn't create any?  d'oh.  I guess maybe once I fix that everywhere it'll run faster. 

Is there any reason not to make it perm by putting vm.nr_hugepages = 2048 in sysctl.conf?

[dga]

you replaced by "Hello, World!" log output

keep up the good work & thank you

Oops.  I didn't think anyone would notice.  *grins*

Also, I've reduced the severity of that "oh my god no huge pages" message.  It now presents it as a suggestion for how to get better throughput.

[xolokram]

you replaced by "Hello, World!" log output

keep up the good work & thank you

[dga]

Looked like it was faster than yam on my two junk servers, but slower on the rest

it was also dumping cores everywhere with mmap failing

Thanks for the report.  The mmap failure is just a warning - it falls back to malloc.

To silence - and run a little faster with both yam and my code - run:

echo "2048" > /proc/sys/vm/nr_hugepages

But the dumping cores is bad.  Could you send me a little more detail, or a stack trace?  (And on what kind of machine?)

The slower on the rest isn't too surprising.  There are a lot of optimizations to be done yet, particularly for huge servers with respect to thread affinity and other things.  And the SHA512 code is virtually untouched from the Intel release.  The goal isn't to beat yam with this release, it's just to start the ball rolling a little bit.

There are some constants to play with to tune for different platforms, but it's not worth going there yet (unless you're interested in poking in the code).

  -Dave

[zvs]

Looked like it was faster than yam on my two junk servers, but slower on the rest

it was also dumping cores everywhere with mmap failing

[r05]

Went from 80c/m to 160c/m on a Q9550.

Outstanding, dga.

[dga]

Following up on yvg1900's release of yam, I figured I'd improve the state of the art of the open source versions a bit:

https://github.com/dave-andersen/ptsminer

I haven't made it build yet on windows (it just needs to compile the avx2 assembly code - should be straightforward if someone wants to clue me in on how to appropriately invoke gcc there), but it should work on other platforms.  As a warning, I've only really tried it on avx2, since I'm a fan of Haswell.  THIS SOFTWARE SHOULD BE CONSIDERED A BETA QUALITY RELEASE.  At best. 

As with my GPU release, this one is based very directly on ptsminer, so it's tied to beeeeer for the moment.  I plan to fix that and let it be used with other pools in the near future, but that's going to take some dev work.  sigh.

There's a lot of optimization to be done, but this gets the basics as far as memory subsystem optimization, and bridges a lot of the gap between the old OSS version and yam M7i.  I haven't tried out M7j, mind you -- it's probably a bit faster still, but this release should bridge the gap considerably.

It incorporates the same optional, extendible 1% dev fee that the gpu miner does.  Prior ptsminer devs, if you feel like you should be in the list, please PM me and I'll get you added!

With gratitude to FreeTrade for the donation that kept me interested in hacking on and releasing this stuff, and to yvg1900 for some very engaging unofficial competition. *grin*

  -Dave