sp_
Legendary
Offline
Activity: 2926
Merit: 1087
Team Black developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 09:18:44 AM |
|
How much do you get on the G1840 celeron? (Cryptonight)
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 11:17:07 AM |
|
@Joblo would it be cool with you if I mine to your BTC donation address at nicehash as donation time for your work? I'll mine one full day per week as donation. Every other user can do the same as well.
That's a very generous and motivating offer. I took a quick look at the mod text you linked. With that and the Nicehash source code there should be no problem implementing it. I'll dig into it more later today and provide an update.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 11:21:04 AM |
|
How much do you get on the G1840 celeron? (Cryptonight)
I don't have one to test with but I don't expect much, it doesn't even have AES_NI.
|
|
|
|
NeuroticFish
Legendary
Offline
Activity: 3794
Merit: 6495
Looking for campaign manager? Contact icopress!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 11:27:09 AM |
|
corei7 nehalem, westmere
I did a test on Nehalem. cpuminer-corei7.exe works well for m7m and cryptonight. Joblo, if you need other test on my CPU, just PM me, if I don't see your request in thread within 24h.
|
|
|
|
ryen123
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 12:54:08 PM Last edit: August 25, 2016, 01:07:11 PM by ryen123 |
|
@Joblo would it be cool with you if I mine to your BTC donation address at nicehash as donation time for your work? I'll mine one full day per week as donation. Every other user can do the same as well.
That's a very generous and motivating offer. I took a quick look at the mod text you linked. With that and the Nicehash source code there should be no problem implementing it. I'll dig into it more later today and provide an update. I just started mining to your BTC address, just don't expect a lot since I only running 2 cpus. Hope other users would donate some cpu time to you as well. https://www.nicehash.com/index.jsp?p=miners&addr=12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
|
|
|
|
NDBob
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 02:14:37 PM |
|
@joblo --- I'd be happy to test the AES w/o AVX configurations --- do you have a patch file or a link to the downloaded files with the patches?
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 03:51:39 PM |
|
@joblo --- I'd be happy to test the AES w/o AVX configurations --- do you have a patch file or a link to the downloaded files with the patches?
Thanks for the offer. I assume you have a Westmere CPU, and you use Windows. You can test with the current cpuminer-corei7 binary. As another user discovered Hodl algo failed to compile on his Westmere so I don't suggest you attempt hodl. I also have a fix coming shortly for that algo. Cryptonight also has AES code that may or may not work on a Westmere. There is another block of AES code shared among many algos including x11. Both of these would be good tests. Don't test cryptonight on Nicehash yet, I'm still working on that. If you did test either or both of them please include in your report whether the miner chose to use the AES code: Start mining with SSE2 AES AVX It will display both AES and AVX or neither. At this time I'm treating them as a single architecture level. If your tests prove there is AES code that does not also contain AVX I can split them up and improve performance on Westmere on some algos. Otherwise Westmere will have to dumb down and use the SSE2 code only as had to be done with Hodl.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 03:54:26 PM |
|
corei7 nehalem, westmere
I did a test on Nehalem. cpuminer-corei7.exe works well for m7m and cryptonight. Joblo, if you need other test on my CPU, just PM me, if I don't see your request in thread within 24h. Thanks for testing. Could you post the capabilities check ouput when the miner starts. I'd like to confirm it is correct.
|
|
|
|
NDBob
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 04:08:54 PM |
|
@joblo ---
Mining LYRA2RE to NiceHash:
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz CPU features: SSE2 AES SW built on Aug 24 2016 with GCC 4.8.3 SW features: SSE2 Algo features: SSE2 AES AVX AVX2 AES not available, starting mining with SSE2 optimizations...
Mining HODL to NiceHash:
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz CPU features: SSE2 AES SW built on Aug 24 2016 with GCC 4.8.3 SW features: SSE2 Algo features: SSE2 AES AVX AVX2 AES not available, starting mining with SSE2 optimizations...
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 04:34:06 PM |
|
@joblo ---
Mining LYRA2RE to NiceHash:
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz CPU features: SSE2 AES SW built on Aug 24 2016 with GCC 4.8.3 SW features: SSE2 Algo features: SSE2 AES AVX AVX2 AES not available, starting mining with SSE2 optimizations...
Mining HODL to NiceHash:
CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz CPU features: SSE2 AES SW built on Aug 24 2016 with GCC 4.8.3 SW features: SSE2 Algo features: SSE2 AES AVX AVX2 AES not available, starting mining with SSE2 optimizations...
Excellent, thanks.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 04:45:43 PM |
|
I have an update on supporting cryptonight at nicehash. I implemented the changes and they seem to work and they don't break other pools so there was no need to impmement pool-specific code. My test results on Nicehash are erratic, possibly a pool issue. I was initially submitted 20-25% rejects but that seems to have stopped. The latest session is up to 36 accepts @ 100%, and counting. I also experienced periods of extremely frequent thread hashrate output from one or 2 threads, around 100 per second, showing a hash count of 1 with a normal hashrate. This occurred twice at startup and I killed it. It also happened mid session and cleared itself. This is not associated with the rejects, I still submit valid shares but they show a lower than normal hashrate. This is what it looks like: [2016-08-25 12:23:28] CPU #0: 1 H, 72.57 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 56.63 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 55.92 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 64.27 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 67.63 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 54.73 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 55.19 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 71.66 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 69.21 H/s
More testing to do.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 05:21:20 PM |
|
Joblo ...
OK, had a chance to play around a bit with the GCC 6.1.0 compiling and I think I found a pretty simple fix to this problem at least. The min/max macros which are causing collisions in the HODL C++ code are only referenced locally in the decred.c file, but are defined manually in miner.h. So ....
1) Comment out or remove the macro definitions for min and max in miner.h 2) add a local definition of the min macro to decred.c
After that I was able to get it to compile on one of my Haswell systems. Still having trouble compiling on an older westmere based system due to some AES256CBC complaints.
Bob
Good work. I'll make the change proactively. The AES256CBC problem may be related to AVX code in hodl-wolf. IIRC either Nehalem or Westmere have AES but not AVX. I may have to tighen up the checking to force it to use the unoptimized version. Did you do a native compile? Have you tried corei7? "gcc -Q -march=native --help=target" will tell you which arch is the default for native. Westmere support AES-NI but not AVX. Nehalem doesn't support either. I've successfully compiled for all the AVX platforms on my laptop - haswell corei5 but can't compile with march=westmere or with native on my dev virtual machine which is running on some older servers (Dual Westmere Hex-core) that I wanted to test on. setting march=haswell on the older VM works fine and compiles haswell optimized code (which can't run locally obviously). Appears to be some sort of a conflict in the capabilities check on the HODL AES code. You're right, I only check for AES_NI, not AVX. This may affect some other algos that also have AVX code mixed in with AES. If I can identify which ones are pure AES I can make a distinction otherwise I'll have to use non-AES code unless the CPU also supports AVX. I don't have the necessary HW to test but if you don't mind doing a little more work it would help a lot. There are three groups of AES code. There is code used only by hodl, code only used by cryptonight and code shared among many algos including x11. Those three should cover the entire spectrum of AES optimized code. Those that work on your Westmere can have AES enabled without AVX. Those like Hodl will require a CPU with AVX before AES can be enabled. It just occurred to me that you probably did a native compile. Do you know what arch the compiler mapped that to? A Windows user reported success using the corei7 build on a Nehalem CPU. If yours is different you could try -march=corei7. This will raise my confidence in the fix since I can't test it on the right HW.
|
|
|
|
NDBob
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 05:29:16 PM |
|
Joblo ...
OK, had a chance to play around a bit with the GCC 6.1.0 compiling and I think I found a pretty simple fix to this problem at least. The min/max macros which are causing collisions in the HODL C++ code are only referenced locally in the decred.c file, but are defined manually in miner.h. So ....
1) Comment out or remove the macro definitions for min and max in miner.h 2) add a local definition of the min macro to decred.c
After that I was able to get it to compile on one of my Haswell systems. Still having trouble compiling on an older westmere based system due to some AES256CBC complaints.
Bob
Good work. I'll make the change proactively. The AES256CBC problem may be related to AVX code in hodl-wolf. IIRC either Nehalem or Westmere have AES but not AVX. I may have to tighen up the checking to force it to use the unoptimized version. Did you do a native compile? Have you tried corei7? "gcc -Q -march=native --help=target" will tell you which arch is the default for native. Westmere support AES-NI but not AVX. Nehalem doesn't support either. I've successfully compiled for all the AVX platforms on my laptop - haswell corei5 but can't compile with march=westmere or with native on my dev virtual machine which is running on some older servers (Dual Westmere Hex-core) that I wanted to test on. setting march=haswell on the older VM works fine and compiles haswell optimized code (which can't run locally obviously). Appears to be some sort of a conflict in the capabilities check on the HODL AES code. You're right, I only check for AES_NI, not AVX. This may affect some other algos that also have AVX code mixed in with AES. If I can identify which ones are pure AES I can make a distinction otherwise I'll have to use non-AES code unless the CPU also supports AVX. I don't have the necessary HW to test but if you don't mind doing a little more work it would help a lot. There are three groups of AES code. There is code used only by hodl, code only used by cryptonight and code shared among many algos including x11. Those three should cover the entire spectrum of AES optimized code. Those that work on your Westmere can have AES enabled without AVX. Those like Hodl will require a CPU with AVX before AES can be enabled. It just occurred to me that you probably did a native compile. Do you know what arch the compiler mapped that to? A Windows user reported success using the corei7 build on a Nehalem CPU. If yours is different you could try -march=corei7. This will raise my confidence in the fix since I can't test it on the right HW. Might have gotten lost in the thread above, but I was able to compile with AVX level features on the westemere based system, the obviously just don't get detected or work. The errors only seem to occur when I set the march to westmere or lower. I've been looking through the code for hodl to try to figure out what seems to be causing the problem. It primarily seems to be from different versions of the SHA256CBC algorithm that it is attempting to compile in simultaneously. In going through though, I've come across a question for you with regards to your capabilities tests --- you seem to be excluding a lot of the AES_NI optimized code by wrapping it in the AVX segment even though there don't seem to be any AVX instructions in those code segments. I haven't had a chance to look through it thoroughly, but on a quick scan the only part of wolf's code that utilizes AVX instructions is the SHA512 function used to generate the scratchpad. The rest of the code should be able to be under #ifndef NO_AES_NI. Bob
|
|
|
|
NDBob
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 06:02:28 PM |
|
Joblo ---
I flattened the code int algo/hodl/aes.c and algo/hodl/hodl-wolf.c to remove the "non-AVX" code versions for everything but the SHA512 Function at the top of hodl-wolf.c and the code now compiles and runs for -march=westmere.
For cpuminer-corei7.exe from your download mining HODL to nicehash with 12 threads, isolated to the six cores on one CPU I am getting in the 120-130 H/s range performance
For cpuminer-westmere.exe that I compiled using the above modifications using the same configuration on the other CPU in my server I am seeing 240-250 H/s and it indicates AES optimizations ARE enabled.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 06:03:57 PM |
|
Joblo ...
OK, had a chance to play around a bit with the GCC 6.1.0 compiling and I think I found a pretty simple fix to this problem at least. The min/max macros which are causing collisions in the HODL C++ code are only referenced locally in the decred.c file, but are defined manually in miner.h. So ....
1) Comment out or remove the macro definitions for min and max in miner.h 2) add a local definition of the min macro to decred.c
After that I was able to get it to compile on one of my Haswell systems. Still having trouble compiling on an older westmere based system due to some AES256CBC complaints.
Bob
Good work. I'll make the change proactively. The AES256CBC problem may be related to AVX code in hodl-wolf. IIRC either Nehalem or Westmere have AES but not AVX. I may have to tighen up the checking to force it to use the unoptimized version. Did you do a native compile? Have you tried corei7? "gcc -Q -march=native --help=target" will tell you which arch is the default for native. Westmere support AES-NI but not AVX. Nehalem doesn't support either. I've successfully compiled for all the AVX platforms on my laptop - haswell corei5 but can't compile with march=westmere or with native on my dev virtual machine which is running on some older servers (Dual Westmere Hex-core) that I wanted to test on. setting march=haswell on the older VM works fine and compiles haswell optimized code (which can't run locally obviously). Appears to be some sort of a conflict in the capabilities check on the HODL AES code. You're right, I only check for AES_NI, not AVX. This may affect some other algos that also have AVX code mixed in with AES. If I can identify which ones are pure AES I can make a distinction otherwise I'll have to use non-AES code unless the CPU also supports AVX. I don't have the necessary HW to test but if you don't mind doing a little more work it would help a lot. There are three groups of AES code. There is code used only by hodl, code only used by cryptonight and code shared among many algos including x11. Those three should cover the entire spectrum of AES optimized code. Those that work on your Westmere can have AES enabled without AVX. Those like Hodl will require a CPU with AVX before AES can be enabled. It just occurred to me that you probably did a native compile. Do you know what arch the compiler mapped that to? A Windows user reported success using the corei7 build on a Nehalem CPU. If yours is different you could try -march=corei7. This will raise my confidence in the fix since I can't test it on the right HW. Might have gotten lost in the thread above, but I was able to compile with AVX level features on the westemere based system, the obviously just don't get detected or work. The errors only seem to occur when I set the march to westmere or lower. I've been looking through the code for hodl to try to figure out what seems to be causing the problem. It primarily seems to be from different versions of the SHA256CBC algorithm that it is attempting to compile in simultaneously. In going through though, I've come across a question for you with regards to your capabilities tests --- you seem to be excluding a lot of the AES_NI optimized code by wrapping it in the AVX segment even though there don't seem to be any AVX instructions in those code segments. I haven't had a chance to look through it thoroughly, but on a quick scan the only part of wolf's code that utilizes AVX instructions is the SHA512 function used to generate the scratchpad. The rest of the code should be able to be under #ifndef NO_AES_NI. Bob Can you post the actual errors? I've been speculating it was an AVX issue. If you're seeing multiple definitions I may be going in the wrong direction.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 06:06:43 PM |
|
Joblo ---
I flattened the code int algo/hodl/aes.c and algo/hodl/hodl-wolf.c to remove the "non-AVX" code versions for everything but the SHA512 Function at the top of hodl-wolf.c and the code now compiles and runs for -march=westmere.
For cpuminer-corei7.exe from your download mining HODL to nicehash with 12 threads, isolated to the six cores on one CPU I am getting in the 120-130 H/s range performance
For cpuminer-westmere.exe that I compiled using the above modifications using the same configuration on the other CPU in my server I am seeing 240-250 H/s and it indicates AES optimizations ARE enabled.
This confirms that the corei7 build has AES disabled.
|
|
|
|
NDBob
Newbie
Offline
Activity: 14
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 06:11:59 PM |
|
Yes --- corei7 is definitely running without AES_NI.
For HODL, you are excluding a whole bunch of AES_NI code that doesn't require AVX to execute. The only part of Wolf's implementation that requires AVX is the SHA512 function in the initial scratchpad generation routine. If you take out the AVX checks and "non-AVX" code from the rest of the implementation in algo/hodl/aes.c and algo/hodl/hodl-wolf.c it compiles for westmere and runs just fine with AES-NI enabled. Running 24 threads with no affinity on my server I'm seeing about 215H/s without AES and close to 375H/s average with the modified version to allow the AES_NI code to run.
|
|
|
|
joblo (OP)
Legendary
Offline
Activity: 1470
Merit: 1114
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 06:19:17 PM |
|
Yes --- corei7 is definitely running without AES_NI.
For HODL, you are excluding a whole bunch of AES_NI code that doesn't require AVX to execute. The only part of Wolf's implementation that requires AVX is the SHA512 function in the initial scratchpad generation routine. If you take out the AVX checks and "non-AVX" code from the rest of the implementation in algo/hodl/aes.c and algo/hodl/hodl-wolf.c it compiles for westmere and runs just fine with AES-NI enabled. Running 24 threads with no affinity on my server I'm seeing about 215H/s without AES and close to 375H/s average with the modified version to allow the AES_NI code to run.
I would need to see your code changes and I also want to see the compile errors. I need to make sure your changes don't break other CPus.
|
|
|
|
torsh
Newbie
Offline
Activity: 5
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 07:11:49 PM |
|
Hi, could you tell, whether assembled under windows x86 32-bit? Sorry for my English....
|
|
|
|
felixbrucker
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 25, 2016, 08:09:18 PM |
|
I have an update on supporting cryptonight at nicehash. I implemented the changes and they seem to work and they don't break other pools so there was no need to impmement pool-specific code. My test results on Nicehash are erratic, possibly a pool issue. I was initially submitted 20-25% rejects but that seems to have stopped. The latest session is up to 36 accepts @ 100%, and counting. I also experienced periods of extremely frequent thread hashrate output from one or 2 threads, around 100 per second, showing a hash count of 1 with a normal hashrate. This occurred twice at startup and I killed it. It also happened mid session and cleared itself. This is not associated with the rejects, I still submit valid shares but they show a lower than normal hashrate. This is what it looks like: [2016-08-25 12:23:28] CPU #0: 1 H, 72.57 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 56.63 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 55.92 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 64.27 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 67.63 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 54.73 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 55.19 H/s [2016-08-25 12:23:28] CPU #1: 1 H, 71.66 H/s [2016-08-25 12:23:28] CPU #0: 1 H, 69.21 H/s
More testing to do. thanks for this!
|
|
|
|
|