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.

Replying to a bunch of the previous comments:

- I'll disable the "aborting scan" message in the next set of changes.  I still want to put in a slightly better method for doing this, because I think it is increasing the reject rate a little bit.  @ptsrush, my guess is it's a little bit because of latency and a little bit because the miner works in bigger chunks.  I'll make it a priority to get that in the next build.

@allano, re source code to github: 
  (a)  Which opteron do you have?  I'm running the SSE one on AMD CPUs with SSE support.  It works just fine.
  (b)  I have a few reasons I'm not pushing the source yet:  First, the build is a mess, and I need to move it to using autoconf or some other method.  There are currently four different makefiles that the project inherited from ptsminer, and part of my recent optimization adds different code that runs on different CPUs.  The combination of this is currently unmanageable.

  Second, I'm trying to figure out what the right strategy is for this one to fund development.  It's pretty clear based on what happened with the GPU miners that if I release all of my tricks without supporting more pools and windows, a whole lot of clones will spring up with binary builds for other platforms with high dev fees that go to someone else.  I'm fine with that in the long term, but I want to be careful.  I've put .. um .. rather a lot of work into the current optimized CPU version.

  My current thought is that I'm going to wait until *I* can provide easy-to-use binaries for both linux and windows with a 1-2% dev fee that supports both beeeeer and ypool, and then release the source as well.  Of course, I'd also be happy to go with a sponsored code release again or explore other options, but the dev fee really does seem like a very equitable way.

@noobster: Agreed.  The 3% dev fee is temporary.  I'm going to cut it down to 2% pretty soon.
  - Do you mind the 60 second dev mine starting time?  I'd rather increase the user time from 2000 to 3000 seconds than reduce dev mine from 60 to 40 --- it's more efficient to run for longer.

- Amount of RAM per thread:  The algorithms I'm using in this are completely different from what previous miners did.  There's no way to use less RAM because of the way I store the data, and using more RAM will actually make it slower.

Did you want to use *less* RAM, or more because you want it go to faster?

  -Dave

model name   : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz

http://ark.intel.com/products/48768/Intel-Xeon-Processor-E5645-12M-Cache-2_40-ghz-5_86-gts-Intel-qpi

The SSE one.  LMK if it works - I haven't tested on that model.

  -Dave

Hi dga,

beta4 avxsse has 315 - 320 cpm in my e3-1230 v2 avx gentoo box.

the yam is about 305 - 310 cpm.

so you win about 3% ahead

Hah.  Thanks!  Not quite enough to justify that dev fee, though.  I'll see if I can make it a bit faster and earn my keep.

In the meantime, I'm just going to go ahead and admit that I have a problem.  I can't keep my toes out of optimizing the avx2 build, so I've put beta5 online.  This one is even more annoyingly architecture-specific, so ONLY haswell / avx2 people should even bother with it.  I just put the static build online because I'm still working out more kinks I introduced into the build process for optimization.  It's getting about 530 cpm on my stock i7-4770.

  -Dave

the static bin does not work for me as well i am using non avx cpu (1st gen. core i3)
I get

Code: [Select]

Illegal instruction

Right.  The pre-built one is *just* my advanced preview for avx2.  For other architectures, just grab the current version from the open source release and build.

  -Dave

anyway I did notice one thing, why using so many hugepages if the miner @ 4 threads only uses 4 hugepages:

Code: [Select]

# cat /proc/meminfo |grep -i hugepages
AnonHugePages:         0 kB
HugePages_Total:     512
HugePages_Free:      508
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
perhaps

Code: [Select]

echo 4 > /proc/sys/vm/nr_hugepagescould be enough? more than that i would consider waste of memory, or may it use more hugepages over time?

ps. still getting this:

Code: [Select]

Could not mmap hugepage, reverting to malloc: Cannot allocate memoryeven after I recompiled my kernel with

Code: [Select]

CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
thanks

Each hugepage is 2MB.  Each thread needs about 600MB.  I'll reduce that by another 50MB in beta4 later today, but for now, that's the math.  so you need 300 hugepages per thread.  With 6 threads, that's 1800 hugepages.

echo 2048 > /proc/sys/vm/nr_hugepages

for 6 threads, or something a little higher if you want to try more threads.

  -Dave

Quote from: dga on January 16, 2014, 06:17:04 pm

Quote from: noobster on January 16, 2014, 06:08:48 pm

yea, i did that already but thanks anyway

and I'm getting this now:

Code: [Select]

Could not mmap hugepage, reverting to malloc: Cannot allocate memory


btw is there any way to reduce memory usage to say 512 or 768 MB per thread?

Not from the command line.  That's my next planned optimization.  I need to finish poking at some other constants to figure out how aggressive I want to be about pushing the memory.

Stay tuned.  I think I can get that into the binary by tonight.  For now, you can run on fewer threads -- you'll find that 4 is actually nearly as happy as 6, and 6 is typically happier for me than 8.

  -Dave

Ok.  I've replaced the binary at the old URL with a new build that uses about 600MB of RAM per thread.  Thanks for the feature request - I'd been meaning to implement this optimization, and it looks from here like it's giving a very pleasant speedup just from using less memory (for those who care, this helps reduce TLB misses).  I haven't run it long enough to get a stable number out of it, but it's looking like 460-475 cpm on an i7-4770.  The 4770k users should be cracking 500cpm.

  -Dave

Slight update:  There's now a beta3 that tries to reduce rejects a bit

http://www.cs.cmu.edu/~dga/ptsminer/

The miner works by processing an entire block of 2^26 hashes at once, and so if new work came in, it would still submit anything found in the previous block.  This could lead to excessive numbers of rejects (and thus, a disconnection).  Beta3 tries a little harder to avoid this - and the wasted work it entails - and also bumps up the number of rejects before reconnecting a bit for safety.

There are some small speed tuning-related changes, but probably not anything measurably different.  I'm still seeing in the 450-475 range on i7-4770.   The reconnect changes I just made + the beta2 dev mining changes should make it a lot easier for people to get longer-running performance measurements out of this code.

I've figured out several of these changes that should help improve performance on non-avx2 systems.  Once I get to that phase, if there's interest in beta testing a linux avx build for sandybridge/ivybridge, I can do that too.  Perhaps one optimized for Amazon's machines?  *grin*

yea, i did that already but thanks anyway

and I'm getting this now:

Code: [Select]

Could not mmap hugepage, reverting to malloc: Cannot allocate memory


btw is there any way to reduce memory usage to say 512 or 768 MB per thread?

Not from the command line.  That's my next planned optimization.  I need to finish poking at some other constants to figure out how aggressive I want to be about pushing the memory.

Stay tuned.  I think I can get that into the binary by tonight.  For now, you can run on fewer threads -- you'll find that 4 is actually nearly as happy as 6, and 6 is typically happier for me than 8.

  -Dave