Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 64. (Read 444067 times)

I don't recommend coins. Do your own research, there's lots of info available.

Typical whiny little child. Accuse me of being a bully then launch a personal attack with false accusations
of deleting your post. Just go away.

whats most profitable to cpu mine right now or best long term coins to hol;d onto that this program can do?
also how bout XMR (monero) music coin and DMD diamon
are any of those profitable cpu mining on a core i5 7600k

Sorry, no MAC support. I should be possible (it compiles on FreeBSD) but I know nothing about MAC development
so I can't help.

is this miner compatible with mac os x . i can't build it. can anyone send  builded version with xevan alog support ?

Thanks.

You complained about AES_NI when it's the same as AES.
You complained about a crash while using the AVX2 build on a CPU without AVX2.
You failed to provide the key error message (it's not a crash).
You failed to mention it worked with fewer threads (this is a FAQ with verium).
And now your're complaining that it's only using SSE2 on an algo that only supports SSE2.

Stop complaining and learn something.

You're using the wrong exe, your CPU doesn't have AVX2. Use the exe that matches your CPU's features.
AES is the same as AES-NI.

Thanks for the response albeit a bit over my head. I saw that X299 and future Ice Lake CPUs will support AVX-512.

Interesting question, did this come from the Xeon Phi thread? The short answer is no.

AVX512, as its name suggests. introduces 512 bit vector processing. This means it can only be used on arrays
of multiples of 512 bits (8*64, 16*32 etc) and only if the same operation is performed on all array elements.
This limits the applicability of AVX512 depending on what kind of processing is performed to hash the algorithm.

Vectorizing improves compute performance by reducing the number of instructions but it doesn't help memory performance.
If you need to process 512 bits you srtill need to load the same amount of data from memory. If an algo is memory
hard vectorizing it just means the CPU spends more time idle while it waits for data.

Some algos have segments of code that can be vectorized, some to 128 bits, fewer to 256 and even fewer to 512.
However converting these sections adds overhead because the vector instructions use a different register set than
scalar instructions. Switching back and forth from scalar to vector instructions on the same data means extra instructions
are required to move the data from one register set to the other and back.

I haven't looked deeply into AVX512 but I don't see much opportunity to optimize any algos with it. Anything that can be
vectorized further is likely more efficient on a GPU which is essentially a vector processor. At best, vectorizing a CPU miner
simply reduces the performance deficit slightly compared to GPUs. Many "CPU" algos are designed to be difficult to vectorize.

An interesting article about AVX512:

https://www.hpcwire.com/2017/06/29/reinders-avx-512-may-hidden-gem-intel-xeon-scalable-processors/

Does any algorithm use AVX-512?

Specify the address in the bat file --coinbase-addr = .....

Soon.  Soon.

I have a Ryzen 7 that's OC'd to 3.7 GHz (very mild OC) on stock cooler.  I only mine m7m and xevan (autoswitching).  I get around 208 kh/s with m7m and around 182 kh/s with xevan.  Stock is 3.5 GHz, and i get about 15-20 kh/s less for both IIRC.

I am building a 1950X soon.  Just waiting for that damn backordered motherboard.  However, since it's just basically 2 Ryzen cores, I'm going to assume roughly 2x the speeds if clocked at the same 3.7 GHz.  Since base clock is 3.4 GHz, then maybe around 376 kh/s for m7m and 330 kh/s for xevan.

This video from ServeTheHome with AMD EPYC says mining is prefect for the Zen architecture.

Threadripper expands the concept of the CCXs, 4 core modules that are combined to form a 8, 12 or 16 core CPUs.
The side effect of this is each CCX has it's own piece of the L3 cache. This makes it inefficient for a CCX to access
data from the L3 cache on a different CCX. Ryzen also uses this architecture.

In many ways this is like a multi-CPU system.

Higher hashrates may be achieved by running seperate miner instances for each CCX module to prevent data accesses
that cross CCXs. This will require a different cpu-affinity mask for each instance. I don't know exactly how AMD
maps logical cores to CCXs, particularly when hyperthreading (AMD calls it SMT) is enabled. It may take some trial
and error to reverse engineer the mapping and determine the best affinity mask for each miner instance.

Ryzen CPUs and multi-CPU systems may also benefit from multiple miner instances.

Unfortunately I am just a spectator as I don't have a Ryzen or Threadripper CPU (yet) to do the work myself.

I'm not sure I understand the problem. It is normal to have fewer hash reports when solo mining because you have to solve
the entire block, not just a share.

My misunderstanding. The impact will be infrequent share submissions.

No, its not what i meant.. its just the minimal static diff is now limited

Hi there. Joblo, thanx for your great work. Can u please check the possible issue? The problem is hashrate reporting while solo mining (getwork):

         **********  cpuminer-opt 3.6.8  ***********

[2017-08-14 09:29:31] Binding process to cpu mask f
[2017-08-14 09:29:31] Binding thread 0 to cpu mask f
[2017-08-14 09:29:31] Binding thread 1 to cpu mask f
[2017-08-14 09:29:31] Binding thread 2 to cpu mask f
[2017-08-14 09:29:31] Binding thread 3 to cpu mask f
[2017-08-14 09:29:31] 4 miner threads started, using 'cryptonight' algorithm
[2017-08-14 09:29:32] Current block is 19325
[2017-08-14 09:29:32] No payout address provided, switching to getwork

Then it may take about 10+ minutes to display hashrate, or even up to 1 hour (the result will be printed for all that time though). Tried several coins and several algos, as well as sse42 and avx/avx2 versions, and the previous 3.6.7 version. No changes there. I personally do not see some walls to avoid hasrate output, as all built-in-wallet miners do that. This reproduces both on win7 and win10.

It's hard to tune settings (I'm not about cryptonote algo, of course) for new coins with such a wait I had to use shitpool with zero miners and broken payouts to tune Cos on stratum work there's no issues.

I use some kinda stock .conf file, which is similar for all the coins.

Maybe there're some solutions rather than miner's code? Thanks.

Thank you joblo for this great tool.  I just started my test run with it.  Can't wait to see the results.  Thanks.

A heads up for those mining on yiimp with a CPU, you may see rejected shares for low difficulty.

https://bitcointalksearch.org/topic/m.20854352