Start diff is not the problem, minimum diff is.

Since when does yiimp require registration? Seems dodgy to me.

OK, enough replies to these spam threads, let them die.

cpuminer-opt-3.11.1 is released.

https://github.com/JayDDee/cpuminer-opt/releases/tag/v3.11.1

Faster panama for x25x AVX2 & AVX512.

Fixed echo VAES for Xevan.

Removed support for scryptjane algo.

Reverted macro implemtations of hash functions to SPH reference code
for SSE2 versions of algos.

Use older release for scryptjane of SSE2 mcro support.

The user who plagiarized me has been deleted. The user wo I called out and suspect of
retaliating against me is...

https://bitcointalk.org/index.php?topic=5214465.0

It's time to revive this thread because the're back.

In an added twist they are plagiarizing me and posting malware pretending to be cpuminer-opt.

As always, be careful.

Yet another asshole is posing as me and posting malware as cpuminer-opt. As always be careful.

Unfortunately AVX512 only improves algos that have already been taken over by GPUS and ASICS
and they are improvimng faster than CPUs can. That's because GPUs are real vector processors
while CPU SIMD just emulates vector processing with strict restrictions on data organization.
A GPU can run thousands of threads while the biggests CPUs with AVX512 can barely crack 100.

The secret is in the algorithm, those can can be vectorized can be vectoized better on a GPU.
The only way to speed up M7M is more CPU cores and faster clocks.

VAES has some potential as a few CPU algos use can use it. But VAES will only help with linear
vectorizing (loop unrolling) rather than enabling parallel operation.

cpuminer-opt-3.11.0 introduces full support for Intel's Icelake CPUs.

Iclelake architecture includes AVX512, SHA, and VAES. AVX512 and SHA are already supported on
Intel Skylake-X and AMD Ryzen, respectively. VAES is new with Icelake and is an extension of
AES_NI and AVX512 that provides 4 way parallel AES encryption and decryption in a 512 bit vector.

Icelake is only available for mobile at this time, desktop availability is unknown.

VAES support is only available as source code and requires GCC 8.

See the OP for more details about v3.11.0

This release marks the end of the rapid development of the past several weeks. Things
will slow down considerably with mostly bug fixes and minor tweaks.

I am also planning a cleanup to remove some troublesome and useless code, namely the macros
for blake, bmw, etc used by algos like x11, as well as scrypt-jane algo. The macros don't provide
any noticeable performance difference from the refernce code and srypt-jane hasn't been used
for several years. There are other dead algos but they don't cause problems so there is no need to
remove them. This will also reduce the bloat. If anyone has concerns wwith this plan, please speak up.

There's your mistake. Learn first, spend second.

Your question is the never ending question. Most answers will be people promoting their favorite coin.
No one who knows anything will give a serious answer because such knowledge is a competitive
advantage.

Thanks, Those results are in line with mine. The 100% AVX512 algos are pretty close to double the
hash rate so that indicates no significant scaling issues with AVX 512 unless memory accesses are
bottlenecked.

The long X chains are showing the effects of diminishing returns. Further optimization of previously
optimized code has less effect as it represents a diminishing proportion of the complete algo.

Heat will  accelerate aging of everything inside, not just the battery, though a battery failure
can be more dramatic.

The drain fully before recharge, as well as always recharge fully, rules applied to old NiCad batteries
in the 1960's. The theory was they developped a memory of their charging range. I'm not sure
it was ever true but my father told me that when he I got me a set for my Johnny Express.

What is true now is battery capacity diminishes with age and use.

But the OP doesn't care about all that.

Given your disclaimer it's no different than a desktop. It's all about the CPU specs: number of cores, clock speed,
cache size etc, except the specs are lower on a laptop. Any advice for a desktop applies to a laptop, it's just another
x86_64 CPU.

As you seem to be aware cooling is a bigger problem on a laptop. Choosing a "cool" currency to mine
is a bit misleading because it means your CPU is not performing at it highest efficiency. A better comparison
would be to compare at equal temperatures by reducing the number of threads on the "hot" coin to match
the cool coin. Then you can compare the hashrates and determine the profitability on equal terms.

Then when you add more threads to the hot coin it's like having a bigger CPU but much hotter.

There are things you can do to improve cooling. If you live in the northern hemisphere there's the obvious
at this time of year. There are also cooling pads available, even putting it in the fridge if the wifi can
pass through the walls.

The POS tried to copy my ANN but couldn't even do that right, A real winner.

I reported it to Mod and it seems to have been deleted.

Scam warning

A user is posting fake links to cpuminer-opt. Don't download.

The only real cpuminer-opt is here and only here:

https://github.com/JayDDee/cpuminer-opt

Just use the latest release compiled for avx2. That will provide the most direct comparison. If you have Windows
it's already compiled for you. With Linux just compile with "-march=skylake" instead of "-march=native".

You can confirm that the SW features only list AVX2 but the CPU still lists AVX512.

Thanks for posting. It would be nice to compare with AVX2.

I'm seeing genarally around 30% increase in most X algos as they are a mix of optimized
and unoptimized hash functions. Algos like lyra2v3, which are 100% optimized are getting
nearly double.

It's too bad CPUs don't have a chance with those algos anymore.

The previous optimization request got me thinking. It raised concerns similar to
another request I resisted and raises an interesting question.

How far should a miner go for optimizing performance?

Should it modify system configuration?

Should the miner be required to run with root/admin privileges?

The 2 cases that illustrate the issue are the one imediately above. The miner makes a system
configuration change that will affect all applications, and it can't restore the original config itself.

The other case is huge pages. Huge pages requires system configuration changes as well
but only to enable the feature. It does not affect applications that don't explicitly use it.
Buit it requires the miner to be run by administrator on Windows.

My opinion is these features may be appropriate on a dedicated mining system but maybe not
for a typical desktop PC.

The ideal would be able to handle both environments transparently but that takes a lot of work.

Automated config changes that affect everything and aren't automatically reversed is
completely unnacceptible, IMO. If manual intervention is reruired to "undo" it should also
be required to "do".

My only concern is with the automation of the change and lack of automated reversal.
That has a simple solution. Don't do it in the miner.

HW prefetch changes should be done manually by the user before starting to mine, and then
undone when no longer mining.  It's completely up to the user which algos to use it with
and requires no complex logic in the miner.

Huge pages is not so risky but does have the issue of requiring the miner to be run by admin.
My other concern is the lack of transparency.

Huge pages should be completely transparent. The system should be smart enough to allocate
huge pages for large datasets. I don't see why any application changes should be required,
it should all happen behind the scenes in malloc. And it shouldn't require root/admin.

My stubbornness on this point may be part of the issue.

Both of these optimizations could help some algos and hurt others, they have to be set for
each algo individually. With nealry 100 algos that a huge task.

So aside from the technical concerns I don't know if it's worth the work.

Comments are welcome.

Ah, reasoning! It's what prevents people from falling for scams like yours. I see why you
don't like it.

You're targetting naive newbies with your scam.

First of all there aren't very many good developpers and the existing miners
are already highly optimized. There is no way a new better faster miner
suddenly appears, especially from a newbie with no credentials or reputation.

You promoted no original work and can't even write your own ANN.

But the biggest problem is the risk of malware. Crypto miners make an attractive vehicle
because they are known to be flagged by AV. It's the perfect cover for real malware.

And, of course, the source code is not available for review.