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

[pbfarmer]

Your miner with CN-heavy is solid ! I have better hashrate on 24avg than cnv7 !

Speed of heavy algo on 8Gb+ cards allways faster than on V7. It's normal.

I thought it was 1,5KH/s on CN Heavy (Vega 56/64) and 2K/s on V7.

Vegas took a hit.  RX4/5XX 8Gb got a 5-10% bump from heavy.

[ustcstone]

I don't know it's a bug or not!my miner work find on cn-saber with 8K,but after a disconnected from pool and reconnected again,the hashrade drop to about 7300 and won't restore to 8K,i have to restart the miner to get 8K again... here is the log


05:01:03 | Hashrate GPU Thread 0: 500.58 h/s
05:01:03 | Hashrate GPU Thread 1: 500.58 h/s - Total GPU 0: 1001.15 h/s
05:01:03 | Hashrate GPU Thread 2: 502.17 h/s
05:01:03 | Hashrate GPU Thread 3: 502.12 h/s - Total GPU 1: 1004.28 h/s
05:01:03 | Hashrate GPU Thread 4: 500.68 h/s
05:01:03 | Hashrate GPU Thread 5: 500.68 h/s - Total GPU 2: 1001.35 h/s
05:01:03 | Hashrate GPU Thread 6: 502.12 h/s
05:01:03 | Hashrate GPU Thread 7: 499.15 h/s - Total GPU 3: 1001.26 h/s
05:01:03 | Hashrate GPU Thread 8: 502.17 h/s
05:01:03 | Hashrate GPU Thread 9: 500.68 h/s - Total GPU 4: 1002.84 h/s
05:01:03 | Hashrate GPU Thread 10: 500.68 h/s
05:01:03 | Hashrate GPU Thread 11: 500.68 h/s - Total GPU 5: 1001.35 h/s
05:01:03 | Hashrate GPU Thread 12: 502.12 h/s
05:01:03 | Hashrate GPU Thread 13: 500.68 h/s - Total GPU 6: 1002.79 h/s
05:01:03 | Hashrate GPU Thread 14: 502.02 h/s
05:01:03 | Hashrate GPU Thread 15: 502.12 h/s - Total GPU 7: 1004.14 h/s
05:01:03 | Total: 8019.11 h/s - Max: 8022.47 h/s
05:01:12 | GPU 2 Thread 5 Lane 820 finds a Share, value 400015
05:01:12 | Accepted by the pool in 406 ms.
05:01:16 | Pool sends a new Job.
05:02:09 | Pool xxx.xxx.xxx.xxx:xxxx
05:02:09 | Reconnections 0
05:02:09 | Currency BitTube (TUBE)
05:02:09 | Current pool Difficulty 400015
05:02:09 | Accepted Shares 1154
05:02:09 | Total Hashes 461617310
05:02:09 | Miner uptime 15:40:05
05:02:09 | Effective net hashrate 8183.98 h/s
05:02:09 | Devices results - Shares Accepted/Ignored/Rejected - Net Hashrate
05:02:09 | * GPU 0 - 149/0/0 - 1056.68 h/s
05:02:09 | * GPU 1 - 129/0/0 -  914.85 h/s
05:02:09 | * GPU 2 - 147/0/0 - 1042.50 h/s
05:02:09 | * GPU 3 - 137/0/0 -  971.58 h/s
05:02:09 | * GPU 4 - 127/0/0 -  900.66 h/s
05:02:09 | * GPU 5 - 148/0/0 - 1049.59 h/s
05:02:09 | * GPU 6 - 164/0/0 - 1163.06 h/s
05:02:09 | * GPU 7 - 153/0/0 - 1085.05 h/s
05:02:58 | Pool sends a new Job.
05:03:55 | GPU 7 Thread 15 Lane 88 finds a Share, value 400015
05:04:11 | Connection failed: Pool response timeout.
05:04:11 | Connection interrupted, waiting 5s then retry, attempt #1
05:04:15 | Connecting to mining pool xxx.xxx.xxx.xx:xxxx ...
05:04:15 | Connected to pool. Now logging in...
05:04:16 | Successfuly logged as bxdLhsWY56SNjVN2aQ5Yyb6hhCFfAQJVbYsxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.400000
05:04:16 | Pool changes Difficulty to 400015.
05:04:28 | GPU 5 Thread 10 Lane 279 finds a Share, value 400015
05:04:28 | Accepted by the pool in 391 ms.
05:04:29 | GPU 0: Temp: 57C - Fan: 99% -- Shares: Good: 149 Bad: 0
05:04:29 | GPU 1: Temp: 56C - Fan: 99% -- Shares: Good: 130 Bad: 0
05:04:29 | GPU 2: Temp: 53C - Fan: 99% -- Shares: Good: 148 Bad: 0
05:04:29 | GPU 3: Temp: 54C - Fan: 99% -- Shares: Good: 138 Bad: 0
05:04:29 | GPU 4: Temp: 56C - Fan: 99% -- Shares: Good: 129 Bad: 0
05:04:29 | GPU 5: Temp: 55C - Fan: 99% -- Shares: Good: 151 Bad: 0
05:04:29 | GPU 6: Temp: 56C - Fan: 99% -- Shares: Good: 166 Bad: 0
05:04:29 | GPU 7: Temp: 52C - Fan: 99% -- Shares: Good: 155 Bad: 0
05:04:36 | Pool sends a new Job.
05:04:36 | Hashrate GPU Thread 0: 458.10 h/s
05:04:36 | Hashrate GPU Thread 1: 456.86 h/s - Total GPU 0: 914.96 h/s
05:04:36 | Hashrate GPU Thread 2: 453.18 h/s
05:04:36 | Hashrate GPU Thread 3: 453.18 h/s - Total GPU 1: 906.35 h/s
05:04:36 | Hashrate GPU Thread 4: 454.44 h/s
05:04:36 | Hashrate GPU Thread 5: 453.18 h/s - Total GPU 2: 907.61 h/s
05:04:36 | Hashrate GPU Thread 6: 453.18 h/s
05:04:36 | Hashrate GPU Thread 7: 453.18 h/s - Total GPU 3: 906.35 h/s
05:04:36 | Hashrate GPU Thread 8: 488.96 h/s
05:04:36 | Hashrate GPU Thread 9: 493.35 h/s - Total GPU 4: 982.31 h/s
05:04:36 | Hashrate GPU Thread 10: 458.79 h/s
05:04:36 | Hashrate GPU Thread 11: 456.82 h/s - Total GPU 5: 915.61 h/s
05:04:36 | Hashrate GPU Thread 12: 453.18 h/s
05:04:36 | Hashrate GPU Thread 13: 455.07 h/s - Total GPU 6: 908.25 h/s
05:04:36 | Hashrate GPU Thread 14: 453.18 h/s
05:04:36 | Hashrate GPU Thread 15: 451.42 h/s - Total GPU 7: 904.59 h/s
05:04:36 | Total: 7346.00 h/s - Max: 8022.47 h/s


You can see a Connection interrupted and reconnect at 05:04:11, then the hashrade drop to about 7.3K!This happend on all of my miners so i think i have to report this!

[lebuawu2]

I don't know it's a bug or not!my miner work find on cn-saber with 8K,but after a disconnected from pool and reconnected again,the hashrade drop to about 7300 and won't restore to 8K,i have to restart the miner to get 8K again... here is the log

You can see a Connection interrupted and reconnect at 05:04:11, then the hashrade drop to about 7.3K!This happend on all of my miners so i think i have to report this!

it's known issue for Heavy variant after reconnecting JCE not doing warm up again. what I do is put watchdog and if miner close then restart rig.

[sxemini]

Hi JCE,

i updated my 3 Rigs to JCE Miner. It works great, effective hash increase, but i have a problem.



At around 3:30 o´clock all 3 rigs deliver stale shares for around 1.5 hours, 5 days in a row. Other people in this pool don´t have this problem, other miner (for example SRB) don´t have this problem. If it is on 1 Rig then i say ok to much OC, but 3 realy different rigs with different cards and different drivers make the same problem? i think it is a jce miner problem. A Ryzen R5 1600 delivers also stales shares and with the older version 0.32m it works.
I use jce 0.32q at the moment. Any solution or other guys with this problem?

JCE there is a problem in your code or something like this.

Rig1 with JCE 0.32q mining on nanopool normal port -> all fine
Rig2 with SRB 1.6.7 mining on nanopool ssl port -> all fine
Rig3 wtih JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row
Test GPU with JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row

[UnclWish]

Hi JCE,

i updated my 3 Rigs to JCE Miner. It works great, effective hash increase, but i have a problem.



At around 3:30 o´clock all 3 rigs deliver stale shares for around 1.5 hours, 5 days in a row. Other people in this pool don´t have this problem, other miner (for example SRB) don´t have this problem. If it is on 1 Rig then i say ok to much OC, but 3 realy different rigs with different cards and different drivers make the same problem? i think it is a jce miner problem. A Ryzen R5 1600 delivers also stales shares and with the older version 0.32m it works.
I use jce 0.32q at the moment. Any solution or other guys with this problem?

JCE there is a problem in your code or something like this.

Rig1 with JCE 0.32q mining on nanopool normal port -> all fine
Rig2 with SRB 1.6.7 mining on nanopool ssl port -> all fine
Rig3 wtih JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row
Test GPU with JCE 0.32q mining on nanopool ssl port -> from 3:30 to around 5 o´clock only stale shares, tested 3 days in a row

I'm use ssl port on nicehash pool with CPU and GPU on 0.32q without any issues during several days in a row. Maybe nanopool did something with ssl port in your pointed time?

[JCE-Miner]

Hi all!

Again I do very little support, i'm focusing on the v8 assembly. I've one that works, but i'm not satisfied with the performance yet, so i need to improve it. If i'm really stuck, i'll write some parts in C and rewrite to ASM later. I also need to keep room for the tests. I'll skip the formal performance benchmark against other miners like I did for V7 in april, i just have no time.

About the hashrate drop every 24h: i still did a quick review of my netcode, and really found nothing with a 24h period. Could it be some bottleneck with your wifi or ISP?
The fee session period is ~100 mn, like Claymore or SRB, but really not 24h. Also, stale shares are amplified by a high ping, hence why i suspect your network.
The symptom may not arise on other miner because we have different stale share aggressivity, JCE is mid-high aggressive while Claymore is smooth, so this latter provides a lower effective hashrate, but is less sensitive to bad ping.

Bad warmup: yeah it's a known problem, but can by avoided with a combination of Watchdog and script (.bat) that restarts the miner in case of disconnect that makes it slower. Also the option -q quits the miner at first network problem, it can be used in place of the watchdog, or even both. Since JCE starts in a few seconds now, it's an convinient workaround.

What's sad is that is would be very simple to re-trigger the warmup after a disconnect in my netcode, just that v8 forks eats all my dev time.

[heavyarms1912]

Some results from threadripper 1920x

XMR mining,
1090 H/s @ 3.8 Ghz 1.050V 96w


1030 H/s @ 3.6 Ghz 0.975V 84w


AEON mining,
4550 H/s @ 3.8 Ghz 1.050V 122w

[JCE-Miner]

My CPU code is now ready, version 0.33a to be released soon, with:

Monero-v8 (enabled by default for XMR and WOW), that's --variation 15
32-bits and 64-bits support
Windows and Linux
Fix a bug that could make high multi_hash (x4 to x6) produce bad shares on Electroneum.
More shitcoins (Tritanium, Zelerius, HospitalCoin, PyrexCoin)

Now entering test phase, planned release in less than 24h hours

Threadripper 1920X

Your config lacks some multihash, with 32M cache and 24 logical cores, you can achieve more performance.
For monero, enable 16 threads, on logical CPUs:
0, 1, 2, 4, 6, 8, 10, 11, 12, 13, 14, 16, 18, 20, 22, 23

For aeon, AMD cpu are more complicated, enable all logical CPU as you did, plus turn some as multi_hash:2
try turning 0 and 12, and if you get more perf, also try 6 and 18, then also 3 and 15, and finally 9 and 21

[claypaky]

Some times miner say "low difficulty share" and "rejected by pool"

my setting

jce_cn_gpu_miner64.exe --auto --any --no-cpu --forever --variation 12 --low -o %POOL%:%PORT% -u %WALLET% -p %PASSWORD% %SSL% %*

in other miner programs, there is no such problem

exp: SRB Miner

whats wrong ?

[Primus Pilus]

Hello, is there a JCE miner update coming for the new algorithm coming soon?

[JCE-Miner]

whats wrong ?

Are there messages before the reject that say "stale share, may be rejected by the pool" ?
If yes, so here's the answer. We all have different netcode aggresivity about stale shares, it's very possible JCE is more aggressive than other, like Claymore or SRB. Please look at your pool to see if your effective hashrate is better with JCE, even with the rejecteed shares, if yes, so it's still a good deal for you.

Also try to lower the multi_hash parameter, it sometimes helps, but may also make the miner slower, so do the math if it worth to be changed.

CPU version to be released very soon, i'm testing it right now.
GPU will come next.

[heavyarms1912]

Your config lacks some multihash, with 32M cache and 24 logical cores, you can achieve more performance.
For monero, enable 16 threads, on logical CPUs:
0, 1, 2, 4, 6, 8, 10, 11, 12, 13, 14, 16, 18, 20, 22, 23

For aeon, AMD cpu are more complicated, enable all logical CPU as you did, plus turn some as multi_hash:2
try turning 0 and 12, and if you get more perf, also try 6 and 18, then also 3 and 15, and finally 9 and 21

Thanks.  i get lower hashrate with that 16 core config as below on xmr (~750).  Perhaps due to dual channel ram.

Code:

     { "cpu_architecture" : "auto", "affine_to_cpu" : 0, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 1, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 2, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 4, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 6, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 8, "use_cache" : true },	 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 10, "use_cache" : true },	
     { "cpu_architecture" : "auto", "affine_to_cpu" : 11, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 12, "use_cache" : true },	
     { "cpu_architecture" : "auto", "affine_to_cpu" : 13, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 14, "use_cache" : true },		 
     { "cpu_architecture" : "auto", "affine_to_cpu" : 16, "use_cache" : true },	
     { "cpu_architecture" : "auto", "affine_to_cpu" : 18, "use_cache" : true },	
     { "cpu_architecture" : "auto", "affine_to_cpu" : 20, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 22, "use_cache" : true },
     { "cpu_architecture" : "auto", "affine_to_cpu" : 23, "use_cache" : true },	

for cn-lite I already have enabled all logical cores and multi_hash:2 for 4 core; 0,6,12,18

[ruk55]

help me Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
 
Starting GPU Mining thread 0, on GPU 1
Created OpenCL Context for GPU 1 at 000001b693433c40
Created OpenCL Thread 0 Command-Queue for GPU 1 at 000001b6933169c0
Scratchpad Allocation success for OpenCL Thread 0
Allocating big 3072MB scratchpad for OpenCL Thread 0...
Compiling kernels of OpenCL Thread 0...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10

Starting GPU Mining thread 1, on GPU 1
Created OpenCL Thread 1 Command-Queue for GPU 1 at 000001b693316720
Scratchpad Allocation success for OpenCL Thread 1
Allocating big 3072MB scratchpad for OpenCL Thread 1...
Compiling kernels of OpenCL Thread 1...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
Devfee for GPU is 0.9%

16:56:34 | OpenCL Thread 1 failed, Stop.
16:56:34 | Connecting to mining pool stellite.ingest-asia.cryptoknight.cc:16222 ...
16:56:34 | Stellite (XTL) Mining session starts!

During mining time, press:
 h      display hashrate for each mining thread.
 r      display full report.
 p      pause all.
 u      pause CPUs.
 0-F    pause GPU 0-15.
 t      GPU temperature and fan speed.
 q      quit.

16:56:34 | GPU Compute allocation starts at 80% and reaches 100% after ~5min,
16:56:34 | during this time, the hashrate may be unstable and inconsistent.
16:56:34 | Let the miner warm-up if you're tuning for performance.
16:56:34 | Unloaded OpenCL kernels of GPU Thread 1
16:56:34 | OpenCL Thread 0 failed, Stop.
16:56:34 | Unloaded OpenCL kernels of GPU Thread 0
16:56:34 | Released OpenCL Thread 1 Scratchpad at 000001b698146d40
16:56:34 | Released OpenCL Thread 0 Scratchpad at 000001b6933e7580
16:56:34 | Released OpenCL Thread 1 Command-Queue of GPU 1 at 000001b693316720
16:56:34 | Released OpenCL Thread 0 Command-Queue of GPU 1 at 000001b6933169c0
16:56:34 | Released OpenCL Context 000001b693433c40 of GPU 1
16:56:34 | Connected to pool. Now logging in...
16:56:34 | Successfuly logged as Se3zVwDh8JdKPqXyDWqjQVQFbSGX9oLs7YQHAyTqtyDbQATZmg4Jc1vH2vnhz4kcqo6mnVT4AwfMv8R rJxKwH7mk3A6Sc1vDU
16:56:34 | Pool connection socket closed.
16:56:34 | Mining thread 0 stopped.
16:56:34 | Mining thread 1 stopped.
Press any key to continue . . .

[HardKano]

help me Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
 
Starting GPU Mining thread 0, on GPU 1
Created OpenCL Context for GPU 1 at 000001b693433c40
Created OpenCL Thread 0 Command-Queue for GPU 1 at 000001b6933169c0
Scratchpad Allocation success for OpenCL Thread 0
Allocating big 3072MB scratchpad for OpenCL Thread 0...
Compiling kernels of OpenCL Thread 0...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10

Starting GPU Mining thread 1, on GPU 1
Created OpenCL Thread 1 Command-Queue for GPU 1 at 000001b693316720
Scratchpad Allocation success for OpenCL Thread 1
Allocating big 3072MB scratchpad for OpenCL Thread 1...
Compiling kernels of OpenCL Thread 1...
Compilation of OpenCL kernels failed.
Error: CL_BUILD_PROGRAM_FAILURE Code: O-2.10
Devfee for GPU is 0.9%

16:56:34 | OpenCL Thread 1 failed, Stop.
16:56:34 | Connecting to mining pool stellite.ingest-asia.cryptoknight.cc:16222 ...
16:56:34 | Stellite (XTL) Mining session starts!

During mining time, press:
 h      display hashrate for each mining thread.
 r      display full report.
 p      pause all.
 u      pause CPUs.
 0-F    pause GPU 0-15.
 t      GPU temperature and fan speed.
 q      quit.

16:56:34 | GPU Compute allocation starts at 80% and reaches 100% after ~5min,
16:56:34 | during this time, the hashrate may be unstable and inconsistent.
16:56:34 | Let the miner warm-up if you're tuning for performance.
16:56:34 | Unloaded OpenCL kernels of GPU Thread 1
16:56:34 | OpenCL Thread 0 failed, Stop.
16:56:34 | Unloaded OpenCL kernels of GPU Thread 0
16:56:34 | Released OpenCL Thread 1 Scratchpad at 000001b698146d40
16:56:34 | Released OpenCL Thread 0 Scratchpad at 000001b6933e7580
16:56:34 | Released OpenCL Thread 1 Command-Queue of GPU 1 at 000001b693316720
16:56:34 | Released OpenCL Thread 0 Command-Queue of GPU 1 at 000001b6933169c0
16:56:34 | Released OpenCL Context 000001b693433c40 of GPU 1
16:56:34 | Connected to pool. Now logging in...
16:56:34 | Successfuly logged as Se3zVwDh8JdKPqXyDWqjQVQFbSGX9oLs7YQHAyTqtyDbQATZmg4Jc1vH2vnhz4kcqo6mnVT4AwfMv8R rJxKwH7mk3A6Sc1vDU
16:56:34 | Pool connection socket closed.
16:56:34 | Mining thread 0 stopped.
16:56:34 | Mining thread 1 stopped.
Press any key to continue . . .

What is the RAM of your GPU ? you are trying to put more than 6GB in the scratchPAD (on 1 GPU ?) if you have less than 6GB you ned to drop your multi-hash value. Check the github for suggestion with your card.

[JCE-Miner]

Hi!

The Windows Monero v8 CPU version is out!
https://github.com/jceminer/cn_cpu_miner

version 0.33a

I expect it to be the very fastest on 32-bits and non-aes, and in a lesser extent in 64-bits AES, the major assembly.
The Linux build comes next, then i focus on GPU, i'm getting very late now.

I read the report about the bad OpenCL. JCE openCL is generated, unlike SRB which is precompiled or stak which is static. It allows wider optim support but in case of failed build, which is very possible with generated code, please give the GPU detection log that is displayed at start, so at least i know what GPU you use.

I tested the current code (the future v8-capable) on AMD HD7000, RX, Vega and even Intel Graphics, and it compiles. I expect the failure to be caused by a different GPU or different driver version that i tested on.

However i still do very little support for now, must stay on the v8 support.

edit:
The Linux Monero v8 CPU version is out too!

[UnclWish]

Hi!

The Windows Monero v8 CPU version is out!
https://github.com/jceminer/cn_cpu_miner

version 0.33a

I expect it to be the very fastest on 32-bits and non-aes, and in a lesser extent in 64-bits AES, the major assembly.
The Linux build comes next, then i focus on GPU, i'm getting very late now.

I read the report about the bad OpenCL. JCE openCL is generated, unlike SRB which is precompiled or stak which is static. It allows wider optim support but in case of failed build, which is very possible with generated code, please give the GPU detection log that is displayed at start, so at least i know what GPU you use.

I tested the current code (the future v8-capable) on AMD HD7000, RX, Vega and even Intel Graphics, and it compiles. I expect the failure to be caused by a different GPU or different driver version that i tested on.

However i still do very little support for now, must stay on the v8 support.

edit:
The Linux Monero v8 CPU version is out too!

Thanks for your hard work! Now you must focus on GPU v8 version.

[JCE-Miner]

I'm doing it right now. I'll first provide a simple implementation based on the on from the official Monero team, then i'll optimize.
It will also contain a little optim for Heavy/Tube (unrelated to v8, just i'll release it at the same time).

If you wonder why it took so long just to make the CPU version, so that's because

1. v8 is completely different from v7, i couldn't reuse anything but the implode/explode parts
2. I support 32-bits, and the 32-bits version was hell to make, because i run out of registers everywhere
3. Every x1 to x6 multihash has it own assenbly
4. the uncached version adds two more (for 64 and 32)
5. each time, there are specialization for some CPUs like core2, nehalem or ryzen

so that was about one hundred asm to update, bench and test

[bucah]

Just 1 simple question regarding v8 algo setting.

Will it have the same intensity, workload, etc on Vega?

Thanks

[JCE-Miner]

Probably not.

First, it will consume more power. I've even burnt one of my PSU during my tests, because my already power-hungry HD7950 pulled a lot more power when mining v8. So, if like me, you have ultra-fine tuned overclock and PSU, better redo all your tuning as if it was your first rig. v8 is very different.

v8 was obviously made to run fine on AES x64 cpu (because all steps are one-instruction there) and run not fine on GPU, because it involves steps GPU are bad on, typically division and random memory reads. Don't forget a GPU has something like 8G of strachpad and only 512K or 1M or 2M of cache, so all accesses are virtually uncached, and verrrryyy slow.

GPU are good to blit 128M of textures in a row, not to random access chunks of 16 bytes. That's what make CN (and still more CN-v8) CPU friendly, and GPU resistant.

[bucah]

So, when I use auto config, how much is the intensity you set on Vega?