[JCE]Fast & stable CN/v8/Heavy/Tube/XHV miner, CPU+GPU, Vega56 1800+ RX580 1200+

[JCE-Miner]

Even in assembly, we have very few control of the cache level. Just a few instructions: the movntdqa and some prefetchnt (nt == non temporal == no cache). JCE mostly let the CPU handle everything, except in "use_cache":false mode.

Progressing on assembly for multi-hash on AES-64 (the easiest to write).
I reach 79 h/s on Hexa-hash on CV-v7, which is very bad, but when using IPBC where the JCE multihash does marvels, i get some interresting results. More tests and optims to do.

Surprisingly, i didn't run out of registers in x64 with 6 hashes at the same time. But on 32 bits it will be terrible. I'll provide hexa-hash 32-bits for code symetry, but probably useless.

edit : i reach 1700 h/s on on IPBC my stock ryzen 1600 with JCE 0.26 and its multihash, with config multi
3+1+1+1+1+1+3+1+1+1+1+1
so 12 threads, two triple and ten simple. Curiously the double are less good...
That's the fastest combination I found. On CN-v7 still cannot beat the default 8x simple

[1714058208]

1714058208

[1714058208]

1714058208

[Bazzaar]

The CN-lite variants are producing surprising results.
You get an n² hashrate. Half the cache memory used, four times the hashrate.

Even odder, on my 2630L I got best results using 2+1+2+1+2+1+2+1+2+1+2+1
            and on my 5640 best with just one thread one core.

Also with the 5640, couldn't run 12 threads(12Mb cache), ran into cache flooding when more than 10 threads, no other apps running.

Baz

[Larvitar]

Even in assembly, we have very few control of the cache level. Just a few instructions: the movntdqa and some prefetchnt (nt == non temporal == no cache). JCE mostly let the CPU handle everything, except in "use_cache":false mode.

Progressing on assembly for multi-hash on AES-64 (the easiest to write).
I reach 79 h/s on Hexa-hash on CV-v7, which is very bad, but when using IPBC where the JCE multihash does marvels, i get some interresting results. More tests and optims to do.

Surprisingly, i didn't run out of registers in x64 with 6 hashes at the same time. But on 32 bits it will be terrible. I'll provide hexa-hash 32-bits for code symetry, but probably useless.

edit : i reach 1700 h/s on on IPBC my stock ryzen 1600 with JCE 0.26 and its multihash, with config multi
3+1+1+1+1+1+3+1+1+1+1+1
so 12 threads, two triple and ten simple. Curiously the double are less good...
That's the fastest combination I found. On CN-v7 still cannot beat the default 8x simple

Damn! Awesome for a stock hexa-core Ryzen!

How to setup this? I can do some testes in Ryzen 7 to see the scalling with 8 cores (but the same cache)

[JCE-Miner]

sorry bro but that's on the 0.26 not released yet.
i over pumped my assembly and now reach 1704 on ipbc and 1733 on Turtle (cryptolight v7)

64 bits almost done, 32 still to be written.

[aGeoM]

Hi

Having problems with an FX8300 JCE 0.25:

Code:

19:40:05 | Thread 3 finds a Share, value 40000
19:40:05 | Rejected by the pool.
19:40:05 | Message from the pool: Low difficulty share
19:40:24 | Thread 6 finds a Share, value 40000
19:40:24 | Rejected by the pool.
19:40:24 | Message from the pool: Low difficulty share

[Iamtutut]

Hi

Having problems with an FX8300 JCE 0.25:

Code:

19:40:05 | Thread 3 finds a Share, value 40000
19:40:05 | Rejected by the pool.
19:40:05 | Message from the pool: Low difficulty share
19:40:24 | Thread 6 finds a Share, value 40000
19:40:24 | Rejected by the pool.
19:40:24 | Message from the pool: Low difficulty share

exact same issue with GRAFT, switch back to XTL.

[aGeoM]

I am on CrytonightV7

[cryptoinvestor_x]

Even in assembly, we have very few control of the cache level. Just a few instructions: the movntdqa and some prefetchnt (nt == non temporal == no cache). JCE mostly let the CPU handle everything, except in "use_cache":false mode.

Progressing on assembly for multi-hash on AES-64 (the easiest to write).
I reach 79 h/s on Hexa-hash on CV-v7, which is very bad, but when using IPBC where the JCE multihash does marvels, i get some interresting results. More tests and optims to do.

Surprisingly, i didn't run out of registers in x64 with 6 hashes at the same time. But on 32 bits it will be terrible. I'll provide hexa-hash 32-bits for code symetry, but probably useless.

edit : i reach 1700 h/s on on IPBC my stock ryzen 1600 with JCE 0.26 and its multihash, with config multi
3+1+1+1+1+1+3+1+1+1+1+1
so 12 threads, two triple and ten simple. Curiously the double are less good...
That's the fastest combination I found. On CN-v7 still cannot beat the default 8x simple

Any reccomendations for IPBC settings on a ryzen 1700? I cant seem to top 1800hsh

Trying 12 threads two double ten simple.
Also tried 14 threads two double 12 simple

[JCE-Miner]

problem with graft ? ok i'll focus to test it more. maybe it selects the wrong fork.
what mode do you use (32 or 64 bits, simple or double hash ?)

the best IPBC mode for ryzen 6 Cores is two triple and ten double hash, but triple not avaiaible yet, need more tests. will be in 0.26 to be released soon.

with my assembly i run at 1698 with peaks at 1704, while 0.25 maxed at 1662, on my ryzen 1600

Edit: i just switched my rig to Graft and got only bad shares. when forcing CN V7 with --variation 3 it works fine.
so it seems Graft switched to v7 recently

to mine Graft with JCE add parameter --variation 3
it will be automatic in 0.26

[Larvitar]

@JCE-Miner

I did some tests using double_hash with Ryzen 7 1700 at IPBC, and I think it's worse than single hash. Ya, the cache is the problem.

Ryzen 7 1700 runs with 16 threads around 2200 at 3.6GHz 2933 RAM/L3. With double hash, more than 16MB cache is used. With Ryzen 5 1600, with just 12 threads, there is 4MB free to play .

Is nice to see R5 1600 shinning. I'm thinking about a second RIG with a R5, but I was reluctant about mining performance.

[JCE-Miner]

same for me, triple hash is better than double, and even two single is better than double.
but double alone is almost twice faster than simple. ipbc gives strange results...

planned for next release:
triple to hexa hash
graft defaults to cn-v7
more stable Hashrate on double AES 64

[KriptoGuruTR]

@JCE-Miner

Any recommendation for a 6-7 GPU Ryzen motherboard? Thanks.

[JCE-Miner]

with so many gpus, you probably cannot use all cache for cpu mining, you may have better perfs with 2x Triple plus nine simple for IPBC
for cn-v7 i'd say seven or six simple on a ryzen 1600/1700. you'll get ~430 I predict on a r5 1600

However the cheap way would be to stay with 8x simple threads and with --low parameter and let the GPU miners take the cache they need. that's what i do, but my ryzen has only 3 GPU. This way JCE drops from 506 (alone) to 497, quite limited drop, and no impact on gpu mining.

[UnclWish]

with so many gpus, you probably cannot use all cache for cpu mining, you may have better perfs with 2x Triple plus nine simple for IPBC
for cn-v7 i'd say seven or six simple on a ryzen 1600/1700. you'll get ~430 I predict on a r5 1600

However the cheap way would be to stay with 8x simple threads and with --low parameter and let the GPU miners take the cache they need. that's what i do, but my ryzen has only 3 GPU. This way JCE drops from 506 (alone) to 497, quite limited drop, and no impact on gpu mining.

What GPU's you're talking about? For wich GPU's it's need CPU cache? More specifically, please.

[4ward]

Added miner to Forager - automatic profit switching miner with MSI Afterburner integration
[/end_shameless_ad]

[JCE-Miner]

nothing gpu-special, but each round of gpu mine xmr needs 88 bytes of input cpu side, for each gpu thread, and there are often ~1000 of them per gpu, time 7 gpu you get ~500K of cache flooded in your cpu, enough to annoy a minig thread.

[JCE-Miner]

Added miner to Forager - automatic profit switching miner with MSI Afterburner integration
[/end_shameless_ad]

thanks bro, not a shameless ad, mining tools and miners work together
i'll add a ref to your tool next time i update the doc

[UnclWish]

nothing gpu-special, but each round of gpu mine xmr needs 88 bytes of input cpu side, for each gpu thread, and there are often ~1000 of them per gpu, time 7 gpu you get ~500K of cache flooded in your cpu, enough to annoy a minig thread.

Oh.... I didn't know that... Thanks for info!

[4ward]

Added miner to Forager - automatic profit switching miner with MSI Afterburner integration
[/end_shameless_ad]

thanks bro, not a shameless ad, mining tools and miners work together
i'll add a ref to your tool next time i update the doc

Cheers
If you also add API, would be great. It would add the ability to properly benchmark and monitor the miner.
Or as a simple solution, since I'm basically capturing output to detect hash rate - to show it more often (or add a switch that does that)

[JCE-Miner]

you mean http server API ?
I'm not a big fan of that but i admit it's needed to get integrated to 3rd party tools. i'll do it but i think i'll do the Linux port first. once the multihash is done.
i've several hundreds of assembly to maintain now, just the 6 multihash times the 6 forks are 36, times the cpu archi, times dualthread mode, times 32/64 bits...

edit: i'll go for the http api, better than hacking the log system.