Please direct me to somewhere else if this has already been answered.

I have a 32 core machine and I only want to use 16, easy enough -t 16.
But that loads up 1 processor and it runs hot, I would prefer to use half of the cores on each processor, every other would be perfect.

In comes the --cpu-affinity, which I cannot figure out.
I tried:
  --cpu-affinity 2863311530 and it seems to ignore it.
  --cpu-affinity and no -t but it just used all cores.
  --cpu-affinity AAAAAAAA and everything was moved to processor 2 (At least it did something)
 
I am probably just being a stupid human!

there always is VertCoin (VTC) using Lyra2re, might be that?

oh indeed

Maybe it's the new Vertcoin classic and the monacoin classic? (Old fork's brought back to life?)

Coincidentally Nicehash's Lyra2RE stopped working for me since the weekend, I am getting "stratum_recv_line failed" from all 4 (usa,eu,hk,jp) of their servers. Can anybody please check it because I am going crazy:

cpuminer -a lyra2re -o stratum+tcp://lyra2re.usa.nicehash.com:3342

@joblo just ran the test for windows:

- i5-3330 from ~60-70 to ~210
- A6-6400K from ~40 to ~60


amd overall not that impressive

Did you compile yourself? I haven't seen CMB post their bins yet.

The A6 is not a real CPU, kinda like Celerons. Since they are new you would think they have all the
technology but they don't. They have some new tech, but not all so it's difficult to find an optimum
pre-compiled build.

Some AMD users that have compiled their own have found better performance by specifying the -march
directly instead of -march=native.

On a tangent I'm curious about the mining performance of the A6's IGPU. The CPU alone is weak but CPU+IGPU
might make up for it.

Seems a little harsh, they should only block multiple IPs using the same BTC addr simultaneously. If all miners have
the same IP it's a farm not a botnet.

I did some playing around with AVX, trying to use it to xor arrays 256 bits at a time.
My results were not encouraging. I got code working but with occasional segfaults,
likely due to alignmnet issues. That should be fixable. The discouraging part is there was
no performance improvement. I tried it looping and inline but it didn't seem to make a difference.
I'll poke around some more but it doesn't look good.

Edit: There are a coule of reasons why I may not have seen any performance increase. It is possible,
likely, the process was memory bound in which case optimizing CPU performance wouldn't help.
The other possibility is the compiler may be auto-vectorising which occurs with the -O3 flag.
The code I vectorised was almost identical to the example of auto-vectorising.

The coding is also quite strange with load and store functions like assembly language instructions.
I would expect the compiler to do that transparently.

Edit2:

Things are looking up. I solved the alignment problem and made progress with performance. I've added 3%
to Lyra2 so far and I have a few functions left to convert. So far I've only implemented AVX2, I still have to do
AVX implementations of al functions. The improvements are to the lyra2 core so they should also help lyra2v2.

You are talking about Lyra2RE, right? So it will get sped up? Because so far tpruvot-cpuminer-multi's Lyra2RE is faster than yours by some 3.8% on my servers. I guess it might be because of -flto that I use with his but can't use with yours (doesn't compile)