I am using this solution candidate skipping approach in my custom solvers for long years.
The idea is that it should not be looked at given key range as hexadecimal representation of number and instead it should be seen as set of '0..9' and 'a..f' characters, numbers and letters, a 'string'.

Considering the fact that BTC puzzle keys were generated using Deterministic wallet and not by human mind, not intentionally formed, it is very unlikely that private keys, hexadecimal strings of longer range puzzle keys will be numbers only ('0..9') or letters only ('a..f').
Such as 0x20124579147074121, or 0x3FCAFDCBEDCABEFDA in case of puzzle #66, no way.

In 17 characters long key range, that is randomly generated, it is so unlikely that you can put your hand in the fire for the fact that there are numbers as well as letters in range string of correct solution leading to private key of puzzle #66 BTC address.

So why to waste hardware device resources to compute something that will never lead to desired solution? There is no point for that at all.
Those private key candidates can be effectively skipped without any hashing computation, thus resulting in solution finding speed-up.

How much speed-up depends on amount of ruled out potential key candidates that will very likely never lead to desired solution and doing it by far more parameters than just simple numbers only ('0..9') or letters only ('a..f').
Choosing correct prediction is the most essential in the way that will minimize the risk of skipping the right solution.

Such as guessing that not only there will be at least some letters ('a..f'), but also how much of those, will there be at least one letter, two letters, three letters?
Will be some letters repeated? Or next to each other, such as 'FF' or 'AA', or in-between 'letter-number-letter', 'letter-letter-number-number' somewhere in private key hexadecimal string, etc.
Same for numbers.

Ruling out key candidates like that results in hardware computational speed-ups that are tens, hundreds or even thousands multiplies of the original speed of the device, but naturally depending on parameters greatly increase risk of skipping the right solution.
This is of course primitive approach just for sake of example.

I went further with it and made approach tunable by far more advanced parameters, probability and combination of prediction systems that resulted in significant speed-up per hardware device, but is keeping it in relatively safe area for risk of skipping the right solution.
Safety and approach being tunable to reach right balance between risk and speed-up.

It is definitely far more fun than plain brute-force of one-by-one scanhashing and much more effective when keeping within safe parameters.

Btw. I effectively implemented the same method to cryptocurrency mining in various mining algorithms where my mining kernels by fine-tuning probability using prediction systems approach algorithmically manipulate chances, move chances of finding nonce to miner side, skipping non-interesting nonce candidates without any hashing at all giving miner the house edge, fine-tuneable to balance risk and the right solution.

That results in nonce being found more often in contrast to old-fashioned one-by-one scanhash brute-force mining, thus overall faster miner, how faster depending on internal fine-tuning.

Bruteforce mining one-by-one scanhash is sooooooo boring, 'prediction mining' and skipping nonce candidates without hashing is fully according to my taste.
But well that is another story.

Funny, I do this all the time, running two instances of the same miner program, at the same time, on the same hardware, both instances using the same GPUs, with different algorithm settings and intensities.
One algorithm memory heavy the other one core heavy, both mining to my own wallets and in the end I make more when those incomes are added together, than if I was just mining single algorithm with only one single miner instance.

I really don’t care whether those two instances are "fighting", as you say, or whether they "like" it or not, or what they do.
All I care is that my rig is running rock stable and in the end I make more – that's what matters to me when mining.

But of course everyone is free to do what he believes is best for him and his rig.

The simpliest way is to run 2 instances of mining program. One with high intensity the other one with very low intensity, each mining to it's own/different address all the time.
Miner with low enough intensity will not eat much hashrates from the miner with high intensity, so the one with low intensity can be actually considered "custom devfee".

Doing it this way can be actually even better and more profitable than letting miner to switch addresses every hour or so.

Btw. depending on algorithms and settings, sometimes running two instances of miner program on the same hardware can be even more profitable – the algorithms will not eat much hashrates from each other, if any! So when those hashrates are added together they can be even higher and more profitable in the end!
Hence, that's probably the way how Claymore came to it, that it can be more profitable to run two instances/threads on the same rig.

It works even with any regular single miners. Just run two instances of your favorite miner on the same rig with various algorithms at the same time and see.
If one algorithm is memory heavy and the other one is core heavy, the resulting profitability will be higher in the end when income is added together.  

Nice benchmark website, but I am missing intensity and other parameters, such as launch config for CryptoNight and other setup data of respective miners used for benchmarking.
Those pareameters are also very important and can have huge influence on resulting hashrate and that's why they should be definitely shown near every benchmark on your website.

The Intel HD Graphics 4000 is a graphics card running on processor - CPU. It supports OpenCL, so you can mine with it using miners supporting OpenCL.
However, do to nature of this "GPU" it is in fact better to directly use your CPU power for mining using CPU designed algorithm, such as CryptoNight, or Hodl on NiceHash getting payout in BTC.
Then you can exchange BTC to Zcash, it will be more profitable in your case than directly mining Zcash.

Every single leaked/stolen sp_ miner put to open contains (real) trojan! So beware using those otherwise that 20% "improvement" can be in fact very pricey at the end.
Only those sp_ miners that are purchased by a donation directly to sp_ are safe to use!

Unfortunately, there is no universal sweet spot. Every single card and every single mining algorithm is different and thus reacts differently to various OC settings.

You must experiment and find best OC settings by yourself.
Please also keep in mind that sweet OC spot is different per every single mining algorithm, so every time you switch mining algorithm you should also change OC settings of your cards for best possible performance!

Try to physically swap/mix order of those cards in risers on motherboard to see whether problem will be reported on the exactly same GPU or different one.
This way you will see if it is hardware failure of GPU, or riser failure, or software driver problem.

If you are mining on Windows 64-bit version best free skunk miner is tpruvot's ccminer 2.2, 32-bit, x86 version.
It is about 5% faster than x64 – that's deference of about 3MH/s, just by running/compiling x86!

Also more hashes can be achieved fine-tuning miner intensity to decimal numbers, until you reach best results for your setup.
Try it, go by really really small decimal steps for intensity, it can make some pretty BIG differences.

I found out that for me intensity of 21.0956 makes difference of about 1-2MH/s more per every single 1080 Ti compared to default skunk intensity of 21!
But when I set intensity to higher than that, my skunk hashing speeds just go slightly down from there.
Simply for me intensity of 21.0956 is the best possible maximum for skunk algorithm.

I mean intensity of 21.0956 mining skunk in tpruvot's ccminer 2.2, 32-bit, x86 version gives me about 59MH/s, sometimes it jumps even little bit over 60MH/s per 1080 Ti card in contrast to plain default intensity of 21 which gives just about 2MH/s less with the same OC settings. I described my OC settings some posts ago.
Skunk hashes on my Aorus 1080 Ti Xtremes faster with overclocking/underclocking at core +120 (1841MHz) and memory -2000 (9010MHz) with power limit at 85%.

Also compiling tpruvot's ccminer 2.2 with CUDA 9 gives a little bit better performance.

What good is a screenshot if there is a page that is far better than simple screenshot:
http://yiimp.ccminer.org/bench?algo=neoscrypt&chip=387

On there you can see realtime benchmarks of mining 1080 Tis, including their clocks, exact miner version and other infos.
As you can see they are running around 1.6 MH/s at neoscrypt in tpruvot's ccminer 2.2 and that is really about 30% boost compared to 1070, so Schleicher is right.

I use Aorus native utility called "GRAPHICS ENGINE" for overclocking/underclocking.
I am not sure whether that tool would work also for 1080 Tis of other brands and manufacturers, but probably not.  

Skunk algorithm is pretty sensitive for overclocking/underclocking of 1080 Ti in a good and most efficient power consumption way for me.

I overclocked /underclocked my Aorus 1080 Ti Xtremes to core +120 (1841MHz) and memory -2000 (9010MHz) with power limit at 85% and getting around 59 MH/s in tpruvot's ccminer x86 2.2 per every single card!

It seems that lowering memory clocks to lowest possible value helps gaining hashes in this specific algorithm.

For example at stock settings (1721MHz / 11010MHz) and power limit at 100% these Aorus 1080 Ti Xtreme cards are giving only about 52 MH/s per card in the same miner with each card pulling 100W more of the wall in contrast that when they are actually underclocked to settings I described, pulling 100W less of the wall per each card, yet still running about 7 MH/s more per card at skunk!

I guess it is because of GDDR5X memory types these cards have and that's why lowering memory clocks a lot surprisingly gains more hashes at these cards.