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

[tc_]

yes it supports monero v7, i myself mine with it right now

params for monero v7 :

-o POOL:PORT -u WALLET -p x --variation 3 --any --auto --low

example:
-o xmrpool.eu:3333 -p x -u WALLET -p x --variation 3 --any --auto --low

Where WALLET is your wallet of course. the trick is the --any param to use.
what coin did you want to mine ? on what pool ?

Found out that my wallet (copy and paste) had a unknown character at the end, corrected it.  it does work.
with XMR-STAK in windows I get around 90-100, but with JCE i get much lower.  I will post my CPU config and maybe i am doing something wrong.
but I do not let it mine using xmr-stak 243 my cpu CPU 0 is not affiliated with it, just 1,2,3 and set to 5x thread.
Not sure how i can do the same with jce.

update: this is what my xmr-stak cou set to: 70-90.  highest 110.hashrate

"cpu_threads_conf" :
[
    { "low_power_mode" : 5, "no_prefetch" : true, "affine_to_cpu" : 1 },
    { "low_power_mode" : 5, "no_prefetch" : true, "affine_to_cpu" : 2 },
    { "low_power_mode" : 5, "no_prefetch" : true, "affine_to_cpu" : 3 },

],

how do i set to same with jce config, i7-4600u.

[1715575276]

1715575276

[1715575276]

1715575276

[1715575276]

1715575276

[1715575276]

1715575276

[1715575276]

1715575276

[JCE-Miner]

thanks, everybody should give the equivalent stak config, it's a lot more understandable.

in short, you cannot yet. max low-power (i call it multi-hash in jce because that's a multihash, not related to power...) is 1 in 0.24d and will be 2 in the upcoming 0.24e
i will raise this limit to 5 or 6 in subsequent releases. if you use any low power >1 current jce cannot win just because it does not support that feature yet. it's not a fair compare btw, as i said in previous post, Hashrate comparison must be done on exact same config.

i plan to release multihash enabled version in a few days, once i did all tests. with max multihash at 2 for now, and there will be a light speed increase on aes version in all cases, even with single-hash, on both 32 and 64 bits
i now reach 504 on my ryzen on CN-v7, while 0.24d peaks at 502

edit:
https://ark.intel.com/products/76616/Intel-Core-i7-4600U-Processor-4M-Cache-up-to-3_30-GHz

a 4MB cache cpu... strange you want to use three x5 thread... i would expect the best config be two threads on core 0 and 2 (or 1 and 3) in x1 mode.
try run jce with no config file, with --auto -t N where N from 2 to 4. i'd be interrested into what N is the best, and what Hashrate you get in each case.

[djkice]

will the update help heavy?

yeah i know i cant compare to old CN but is there any optimisations to use all 16 threads for higher hashrate or nah?

[Iamtutut]

Will test in +/- 2 weeks with Ryzen 5 2400G, I will use 3 cores / 6 threads in "heavy duty" mode.

[JCE-Miner]

you'll get +1h/s about, on all algo including heavy, with simpleshare, and dualshare will be enabled for heavy too, so it won't be an improvement but a whole new feature.
32 bit aes will be improved too, and maybe 32 bits non-aes if my tests are good

it's rarely possible to use all cores with heavy because each share consume 4M of cache.

i don't have a ryzen g yet, no idea how jce works on it. i plan to buy one to test jce gpu.

[Iamtutut]

Don't bother, you'll make me try different settings and we'll see how it will work. I hope to get 250-300H/s.

[tc_]

jce here ya go:  anymore testing let me know.

xmr-stak HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   37.6 |   39.1 |   36.8 |  1 |   28.9 |   30.0 |   30.3 |
|  2 |   29.5 |   30.4 |   30.3 |
Totals (CPU):    96.1   99.5   97.4 H/s
-----------------------------------------------------------------
Totals (ALL):     96.1   99.5   97.4 H/s
Highest:   101.9 H/s
-----------------------------------------------------------------


jce -t 2
22:19:11 | Hashrate Thread 0: 28.62 h/s
22:19:11 | Hashrate Thread 1: 28.99 h/s
22:19:11 | Total: 57.60 h/s

jce -t 3
22:24:11 | Hashrate Thread 0: 11.98 h/s
22:24:11 | Hashrate Thread 1: 23.96 h/s
22:24:11 | Hashrate Thread 2: 25.70 h/s
22:24:11 | Total: 61.62 h/s

jce -t 4
22:20:30 | Hashrate Thread 0: 11.02 h/s
22:20:30 | Hashrate Thread 1: 18.85 h/s
22:20:30 | Hashrate Thread 2: 16.13 h/s
22:20:30 | Hashrate Thread 3: 23.03 h/s
22:20:30 | Total: 69.02 h/s

[JCE-Miner]

thanks, that's very surprising to me !

first i see the normal speed of one core is about 29-30 on both miners, that's what i pretend : jce on par on intel with aes.
but... the more threads you add the more speed you get. jce max at four threads single hash, by construction, and you get 69, a lot more than the autoconfig default of 2 threads.

stak allows penta-share and with a whooping 15 shares (three penta) you rise to 100
i wish i have such a cpu to test. that's so different from the ryzen behavior !

btw dualshare to be released soon, and so you'll be able to do four doublehash but i expect stak still being better with its penta feature. i'll add it to jce but assembly takes a lot more time to write.

[UnclWish]

jce here ya go:  anymore testing let me know.

xmr-stak HASHRATE REPORT - CPU
| ID |    10s |    60s |    15m | ID |    10s |    60s |    15m |
|  0 |   37.6 |   39.1 |   36.8 |  1 |   28.9 |   30.0 |   30.3 |
|  2 |   29.5 |   30.4 |   30.3 |
Totals (CPU):    96.1   99.5   97.4 H/s
-----------------------------------------------------------------
Totals (ALL):     96.1   99.5   97.4 H/s
Highest:   101.9 H/s
-----------------------------------------------------------------


jce -t 2
22:19:11 | Hashrate Thread 0: 28.62 h/s
22:19:11 | Hashrate Thread 1: 28.99 h/s
22:19:11 | Total: 57.60 h/s

jce -t 3
22:24:11 | Hashrate Thread 0: 11.98 h/s
22:24:11 | Hashrate Thread 1: 23.96 h/s
22:24:11 | Hashrate Thread 2: 25.70 h/s
22:24:11 | Total: 61.62 h/s

jce -t 4
22:20:30 | Hashrate Thread 0: 11.02 h/s
22:20:30 | Hashrate Thread 1: 18.85 h/s
22:20:30 | Hashrate Thread 2: 16.13 h/s
22:20:30 | Hashrate Thread 3: 23.03 h/s
22:20:30 | Total: 69.02 h/s

Huge pages are availible? Maybe it's through normal memory work?

[JCE-Miner]

Sure it's an important detail, but here i think his report is fair. Just to see the 4 threads is faster than the 2 thraeds is crazy, on my core2 and ryzen that's the opposite, going above the cache is counter-productive. But on his Strange i7 low power U, he continualy gets more perfs with more threads, far above cache limit.

New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.

Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.

I add some more coins on the fly, and i do a last test session. Ready in a few hours.

[UnclWish]

Sure it's an important detail, but here i think his report is fair. Just to see the 4 threads is faster than the 2 thraeds is crazy, on my core2 and ryzen that's the opposite, going above the cache is counter-productive. But on his Strange i7 low power U, he continualy gets more perfs with more threads, far above cache limit.

New version done, it will be 0.25 major update. I now reach on CN-v7 the perf the 0.24d had on CN classic. I'm right now mining at 504 h/s some CN-v7 with Claymore GPU running in background. stak max at 491 in such condition.

Also 32-bits AES will have a huge perf increase, i jump from 435 to 441
64-bits non aes and 32-bits non aes will have no noticeable increase, just +0.1h/s, beraly noticeable outside a test bench.

I add some more coins on the fly, and i do a last test session. Ready in a few hours.

On my Core i3 on my work 32-bit also this situation. 1 thread gives about 12-15 h/s, 2 threads - about 24-27 h/s, 3 threads - 35-42, 4 threads - 37-45.
As you can see only after 3 threads hashspeed drop significant. But up to 3 threads speed grows normal. But how it's possible? Core i3 have only 3Mb L3 cache. It must drop speed allready on 2 threads.

[JCE-Miner]

32-bits and non aes are different, the AES/cryptonight compute is so costly here than compute power is more important than cache. you have better result with more threads, period.
but his i7 has AES, so that's very surprising...

note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode

[UnclWish]

32-bits and non aes are different, the AES/cryptonight compute is so costly here than compute power is more important than cache. you have better result with more threads, period.
but his i7 has AES, so that's very surprising...

note : the upcoming double hash on non-aes 32-bits will give a big perf boost compared to 0.24d, and seems you're using that mode

No, on 32-bit no-EAS double mode gives nothing in speed on other miners. So I just use usual threads on Core i3.
Double threads I use at home on my FX8320.

Reason why I use double threads on 8320 is next:
1 thread gives about 50-60 h/s, 2 threads - 100-120 h/s, etc. L3 cache is 8Mb. When cache is full - on 4-5 threads CPU gives hashspeed about 250 h/s.
1 double thread gives about 75 h/s. What i'm do - I'm use 1 double thread and 2 single threads or 2 double and 1 single. Result is the up to 225-235 h/s. 3 single threads gives only 150-180 h/s.

In help of double threads I win nearly 1 thread - so less power usage and temperature.
All this possible because of using AMD turbo technology. When CPU uses less than 4 cores it set's on some cores higher frequency and increase hashspeed on them.
If CPU uses 4+ cores turbo technology didn't enables.

Other important notice to use my method - it's not assign threads to cores, or turbo wouldn't work!
And don't forget that it's possible to overclock only turbo frequency, leaving usual frequency the same )))) F.e. my FX8320 is 3,5GHz and 4GHz on turbo. But it's safe to OC turbo clock up to 4,5GHz without any issues and didn't require to up CPU core voltage))))

[JCE-Miner]

On JCE, 32-bits doublehash does give a noticeable perf boost, at least that's what i observed on my Core2. My assembly code is completely different than other miners in non-aes and 32 bits

on aes 64, well, there's a dedicated instruction for every step of cryptonight (AES, Multiply-128 and for Heavy, also Divide-64) so my assembly is pretty the same than a compiler result, except a few optim than makes me ~3% faster.

Very interresting info about turbo, i'll redo some test with double hash and no CPU core assignment to check
thanks

[rednoW]

speaking about 32 bit code for legacy cpus - are you hoping to get some fees from botnet runners? Isn't it bad? ))

[JCE-Miner]

i don't get it... 
JCE itself is not a botnet, not malicious at all. Just a miner. So what's the point with botnets? do you think it will be emmbeded into botnets by some hackers? Maybe, but it could be done with any other miner, just JCE is faster on old CPUs. Faster, but not malicious. And i'm probably the only dev not to have stolen code from Wolf0, among with Claymore who also wrote his one from scratch in 2014.

[rednoW]

I mean what is the reason to release 32-bit code ? It will be useful only for botnets or non-honest sysadmins to run on large old networks.
No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable

[UnclWish]

I mean what is the reason to release 32-bit code ? It will be useful only for botnets or non-honest sysadmins to run on large old networks.
No miner uses win32 nowadays. Legacy cpus consume more than earn. Only if you steal computer power it will be profitable

If you don't needed 32-bit, it didn't means that nobody needs them.

[JCE-Miner]

Ohh, yeah, that's a larger topic you talk about.

One-word answer : niche

xmrig and stak are good miners. Just borrowing code from Wolf0 with no value added, but they are good. JCE beats them by a few percent, that's probably not enough to make everyone move to me, like the Vega users moved to Cast because it's a lot faster. JCE remains the most profitable cpu miner, even on AES-64, even fees deduced, but the difference is like 2%.

But.. on 32-bits and non-aes (which include a lot of cpu) JCE is a lot faster, enough to make users switch, or even mine with otherwise unused CPU, because with +40% free compute hash power, even a Core2 is profitable again.

(And also technically that's a good challenge to optimize on 32-bits. 64 bits assembly is boring to write)

So here you are.
To make you happier, note that JCE netcode on purpose is locked to explicit mine to explicit pools on real internet. A botnet using some dark proxies to mine in the hood would be blocked, unless the botnet really manages to bypass every protection. Claymore did the same on his miners, and he was probably right.

0.25 online - major update

Code:

multi-hash (max multi: 2 for now)
optimization on all algos, with variable increase (aes-32 gets +5h, aes-64 +1h, other less than 1h)
more coins:
Alloy (XAO)
BBSCoin (BBS)
BitcoiNote (BTCN)
Elya (ELYA)
Iridium (IRD)
Italo (ITA)
Lines (LNS)
Niobio (NBR)
Ombre (OMB)
Solace (SOL)
Triton (TRIT)
Truckcoin (TRKC)
Qwertycoin (QWC)

Multi-hash is never used by autoconfig for now, you must rely on manual config, example from my Xeon 12M cache:

Code:

"cpu_threads_conf" : 
[ 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true, "multi_hash": 2 },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 3, "use_cache" : true, "multi_hash": 2 },
]

[UnclWish]

0.25 version is not bad. Doublehash mode works good. Hashrate is not slower than XMRig, but i didn't noticed that JCE faster... Looks like it gives the same speed but with 1,5% devfee against 1% XMRig...