sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 07:51:57 AM |
|
Thanks crysx. The difference is mainly for the compute 5.2 devices, but I hope you will get a boost on your system as well.
|
|
|
|
chrysophylax
Legendary
Offline
Activity: 2828
Merit: 1091
--- ChainWorks Industries ---
|
|
December 12, 2015, 08:08:41 AM |
|
Thanks crysx. The difference is mainly for the compute 5.2 devices, but I hope you will get a boost on your system as well. all good sp ... compiled and rebooted just now ... lets see ... edit - its active ... ------- Compiled with GCC 5.1 using Nvidia CUDA Toolkit 7.5 Based on pooler cpuminer 2.3.2 and the tpruvot@github fork CUDA support by Christian Buchner, Christian H. and DJM34 Includes optimizations implemented by sp, klaust, tpruvot, tsiv and pallas. [2015-12-12 18:39:17] Adding 3774720 threads to intensity 22, 7969024 cuda threads [2015-12-12 18:39:21] Starting Stratum on stratum+tcp://donate-sp.granitecoin.com:7012/ [2015-12-12 18:39:21] NVML GPU monitoring enabled. [2015-12-12 18:39:21] 3 miner threads started, using 'quark' algorithm. [2015-12-12 18:39:21] Binding thread 0 to cpu 0 (mask 1) [2015-12-12 18:39:21] Binding thread 2 to cpu 0 (mask 4) [2015-12-12 18:39:21] Binding thread 1 to cpu 1 (mask 2) [2015-12-12 18:39:22] Stratum difficulty set to 0.04 [2015-12-12 18:39:23] donate-sp.granitecoin.com:7012/ quark block 2557680 [2015-12-12 18:39:28] donate-sp.granitecoin.com:7012/ quark block 2557681 [2015-12-12 18:39:36] donate-sp.granitecoin.com:7012/ quark block 2557682 ------ #crysx
|
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
December 12, 2015, 04:01:51 PM |
|
yep 76 is a 50% slow down for neo scrypt from 586 to 234 and quark is up 1.04 % from 17206 to 17972 time to run two folders
Has anyone compiled r76 for sm5.2 using cuda 6.5 (windows or linux to do a direct comparison with cuda 7.5? I could only do it with 750ti's on Linux and there was virtually no difference. Edit: however, they were both slower than 1.5.74-cuda6.5. The numbers (gpu0/gpu1) both EVGA 750ti SC no OC. 1.5.74(6.5) 1.5.76(6.5) 1.5.76(7.5) x11 3090/3145 2985/3050 2980/3045 quark 6360/6450 6335/6380 6340/6400 lyra2v2 4715/4755 4680/4715 4680/4715
What a pain getting this to display correctly, this ain't WYSIWYG. im compiling the the latest as we speak ... i was well enough to drive - so im here in the office at the moment ... the only thing i can give a comparison rate to is quark ( from 74 - 76 ) on c7.5 ... that doesnt exactly hep what you are asking - but it may be of interest to you regarding the last compiles i had with fedora ... btw - i have upgraded to fedora23x64 on the test machine - and compiling with c7.5 and ccminer-spmod76 ... #crysx Unfortunately with Linux there are very few versions that support both cuda 6.5 & 7.5 so it's difficult to do direct comparisons. I'm compiling r76 for cuda 6.5 on Windows (had to fiddle with the project file) so I can directly compare the difference between r74-cuda6.5 vs r76-cuda6.5 and r76-cuda6.5 vs r76-cuda7.5. Compiling on Windows is a pain. I have to rebuild my compile environment every month because VS shuts down unless I register. I had to create a virtual machine snapshot before installing VS the first time, otherwise the tombstone from the previous install would trigger the forced registration imediately.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 04:36:50 PM |
|
Compiling on Windows is a pain. I have to rebuild my compile environment every month because VS shuts down unless I register. I had to create a virtual machine snapshot before installing VS the first time, otherwise the tombstone from the previous install would trigger the forced registration imediately.
Compile with visual studio express 2013. It is free
|
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
December 12, 2015, 05:02:28 PM |
|
Compiling on Windows is a pain. I have to rebuild my compile environment every month because VS shuts down unless I register. I had to create a virtual machine snapshot before installing VS the first time, otherwise the tombstone from the previous install would trigger the forced registration imediately.
Compile with visual studio express 2013. It is free VS community is advertised as free but it only works for a month without registering. The registration might be free but I haven't tried it. I don't recall beig able to download VS Express, I'll take another look, thanks. Got the test results on a EVGA 980 reference standard clocks. 76-7.5 76-6.5 74-6.5 quark 19.9 19.3 19.3 x11 9850 9920 10000 lyra2v2 10.7 11.4 11.6 neo 220 635 640 These results confirm the increase in quark is purely due to cuda 7.5. It also shows no degradation in cuda 6.5 performance, a win-win for quark. The neo degradation is also purely due to cuda 7.5 with no significant difference between r74 & r76 when compiled with cuda 6.5. X11 is interesting, the 76-6.5 performance is lower than 74-6.5 and the 76-7.5 performance is lower still, a lose-lose. Since quark was the focus of the most recent changes it proves that cuda 7.5 can perform better than 6.5. I hope these results translate to the other algos.
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
December 12, 2015, 05:13:29 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid. Tested working on Linux. Here's the procedure:
- build ccminer with cuda 7.5 as usual - remove all the object files in the neoscrypt folder: rm neoscrypt/*.o - edit Makefile - replace all the instances of "7.5" with "6.5" - run make again - you just made a ccminer executable with all the algos on 7.5 except neoscrypt on 6.5 :-) - revert the Makefile changes to build it again in the future
If you find this useful, please donate to the BTC address in my signature.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 05:28:25 PM |
|
Got the test results on a EVGA 980 reference standard clocks.
76-7.5 76-6.5 74-6.5 quark 19.9 19.3 19.3 x11 9850 9920 10000 lyra2v2 10.7 11.4 11.6 neo 220 635 640
Thanks for testing. Can you please try to compile release 74 with x86 build and cuda 7.5?
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 05:54:52 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid.
This is not a solution, this is a workaround. x11 was hashing @ 1900KHASH in release 74 on the 750ti when building with cuda 7.5(x86) I modded it to go to 2940 in release 76, wich is a bit below release 74 buildt with cuda 6.5. After changing the compiler version in the project, all the kernals need to be retuned. I haven't finished yet. My 5% increase in the quark hashrate has only given me a little more than 0.1 btc in donations. Please donate some more guys. I need your support. Here you can see my latest opensource work: https://github.com/sp-hash/ccminer/commits/windows... Since cude 7.5 is increasing the register and stack usage in the table based AES algos, I reduced the number of threads per block to compensate. I also had to move some precalc tables into the instruction cache. (inlined in the instructions.) I also have reduced the codesize abit since cuda 7.5 seems to loop bether. etc..etc..
|
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
December 12, 2015, 06:00:27 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid. Tested working on Linux. Here's the procedure:
- build ccminer with cuda 7.5 as usual - remove all the object files in the neoscrypt folder: rm neoscrypt/*.o - edit Makefile - replace all the instances of "7.5" with "6.5" - run make again - you just made a ccminer executable with all the algos on 7.5 except neoscrypt on 6.5 :-) - revert the Makefile changes to build it again in the future
If you find this useful, please donate to the BTC address in my signature.
If I undertstand the result neo is compiled with 6.5 and eveyrthing else with 7.5. Then it is all linked with 6.5. I'm not sure linking object files from different compilers is safe. I prefer to use a script to select the prefered executable based on the algo. Less work, less risk, more flexible. Edit: but it's still a workaround.
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
December 12, 2015, 06:09:25 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid. Tested working on Linux. Here's the procedure:
- build ccminer with cuda 7.5 as usual - remove all the object files in the neoscrypt folder: rm neoscrypt/*.o - edit Makefile - replace all the instances of "7.5" with "6.5" - run make again - you just made a ccminer executable with all the algos on 7.5 except neoscrypt on 6.5 :-) - revert the Makefile changes to build it again in the future
If you find this useful, please donate to the BTC address in my signature.
If I undertstand the result neo is compiled with 6.5 and eveyrthing else with 7.5. Then it is all linked with 6.5. I'm not sure linking object files from different compilers is safe. I prefer to use a script to select the prefered executable based on the algo. Less work, less risk, more flexible. Edit: but it's still a workaround. Linking object files from different compilers: I've often linked object files create with a C compiler and others created with an assembler. In ccminer, some objects are compiled with gcc, some others with nvcc... you get the picture.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 06:15:17 PM |
|
Since quark was the focus of the most recent changes it proves that cuda 7.5 can perform better than 6.5. I hope these results translate to the other algos.
I have showed that it can be done with quark. I believe the other algos can be tuned faster as well with more work.. 0.01 BTC guys. This is all I am asking
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
December 12, 2015, 06:18:08 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid.
This is not a solution, this is a workaround. I don't see a problem. Most people already have both cuda 6.5 and 7.5. With some little changes to the Makefile, you could compile each kernel with its best cuda version, in a single executable.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 06:19:52 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid.
This is not a solution, this is a workaround. I don't see a problem. Most people already have both cuda 6.5 and 7.5. With some little changes to the Makefile, you could compile each kernel with its best cuda version, in a single executable. Don't you want to know if cuda7.5 can make your code faster?. A recoding is probobly required.
|
|
|
|
pallas
Legendary
Offline
Activity: 2716
Merit: 1094
Black Belt Developer
|
|
December 12, 2015, 06:21:55 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid.
This is not a solution, this is a workaround. I don't see a problem. Most people already have both cuda 6.5 and 7.5. With some little changes to the Makefile, you could compile each kernel with its best cuda version, in a single executable. Don't you want to know if cuda7.5 can make your code faster?. A recoding is probobly required. You can do both things. On amd we've been doing this forever.
|
|
|
|
sp_ (OP)
Legendary
Offline
Activity: 2912
Merit: 1087
Team Black developer
|
|
December 12, 2015, 06:23:37 PM |
|
// // Generated by NVIDIA NVVM Compiler // // Compiler Build ID: CL-19805474 // Cuda compilation tools, release 7.5, V7.5.16 // Based on LLVM 3.4svn // cuda 6.5 is 1.5 years old.
1.5 year development of compiler technology.
I think we need this to reach the optimal kernal speed.. It worked in the quark kernal, and it should work in the others as well.
|
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
December 12, 2015, 06:33:52 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid. Tested working on Linux. Here's the procedure:
- build ccminer with cuda 7.5 as usual - remove all the object files in the neoscrypt folder: rm neoscrypt/*.o - edit Makefile - replace all the instances of "7.5" with "6.5" - run make again - you just made a ccminer executable with all the algos on 7.5 except neoscrypt on 6.5 :-) - revert the Makefile changes to build it again in the future
If you find this useful, please donate to the BTC address in my signature.
If I undertstand the result neo is compiled with 6.5 and eveyrthing else with 7.5. Then it is all linked with 6.5. I'm not sure linking object files from different compilers is safe. I prefer to use a script to select the prefered executable based on the algo. Less work, less risk, more flexible. Edit: but it's still a workaround. Linking object files from different compilers: I've often linked object files create with a C compiler and others created with an assembler. In ccminer, some objects are compiled with gcc, some others with nvcc... you get the picture. I get the picture. I got a pascal program to call a fortran subroutine several decades ago. No available linker could handle it I had to link it manually. The examples you gave are where it is explicitly supported by the respective linkers. I wouldn't expect that support in different major versions of the same compiler. ABI changes can be introduced. I'm not saying it can't be done, just that it's probably not supported and might not always work.
|
|
|
|
djm34
Legendary
Offline
Activity: 1400
Merit: 1050
|
|
December 12, 2015, 06:38:31 PM |
|
Since quark was the focus of the most recent changes it proves that cuda 7.5 can perform better than 6.5. I hope these results translate to the other algos.
I have showed that it can be done with quark. I believe the other algos can be tuned faster as well with more work.. 0.01 BTC guys. This is all I am asking so you need donation because you believe it can be done ?
|
djm34 facebook pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
djm34
Legendary
Offline
Activity: 1400
Merit: 1050
|
|
December 12, 2015, 06:55:59 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid. Tested working on Linux. Here's the procedure:
- build ccminer with cuda 7.5 as usual - remove all the object files in the neoscrypt folder: rm neoscrypt/*.o - edit Makefile - replace all the instances of "7.5" with "6.5" - run make again - you just made a ccminer executable with all the algos on 7.5 except neoscrypt on 6.5 :-) - revert the Makefile changes to build it again in the future
If you find this useful, please donate to the BTC address in my signature.
If I undertstand the result neo is compiled with 6.5 and eveyrthing else with 7.5. Then it is all linked with 6.5. I'm not sure linking object files from different compilers is safe. I prefer to use a script to select the prefered executable based on the algo. Less work, less risk, more flexible. Edit: but it's still a workaround. Linking object files from different compilers: I've often linked object files create with a C compiler and others created with an assembler. In ccminer, some objects are compiled with gcc, some others with nvcc... you get the picture. I get the picture. I got a pascal program to call a fortran subroutine several decades ago. No available linker could handle it I had to link it manually. The examples you gave are where it is explicitly supported by the respective linkers. I wouldn't expect that support in different major versions of the same compiler. ABI changes can be introduced. I'm not saying it can't be done, just that it's probably not supported and might not always work. used for quite some time c++ programme linked to old fortran libraries, this was done automatically (well in a script). Also regarding nvcc, there are different way to link and compile. You can very well compile one part or the other with one cuda version or another and do the linking with gcc (and I am not entirely sure, but I think for linking cuda is just calling the default compiler (gcc or visual stuff... so actually it doesn't really matter that you compile with various cuda version...
|
djm34 facebook pageBTC: 1NENYmxwZGHsKFmyjTc5WferTn5VTFb7Ze Pledge for neoscrypt ccminer to that address: 16UoC4DmTz2pvhFvcfTQrzkPTrXkWijzXw
|
|
|
joblo
Legendary
Offline
Activity: 1470
Merit: 1114
|
|
December 12, 2015, 07:18:48 PM |
|
Got the test results on a EVGA 980 reference standard clocks.
76-7.5 76-6.5 74-6.5 74-7.5 quark 19.9 19.3 19.3 19.7 x11 9850 9920 10000 7680 lyra2v2 10.7 11.4 11.6 10.9 neo 220 635 640 220
Thanks for testing. Can you please try to compile release 74 with x86 build and cuda 7.5? Done, results included above. The quark rate with 74-7.5 was unexpected, some of the previous changes must have provided a bigger improvement on cuda 7.5 than 6.5
|
|
|
|
scryptr
Legendary
Offline
Activity: 1796
Merit: 1028
|
|
December 12, 2015, 07:22:13 PM |
|
I've found a solution to the neoscrypt problem: building a cuda 6.5/7.5 hybrid.
This is not a solution, this is a workaround. I don't see a problem. Most people already have both cuda 6.5 and 7.5. With some little changes to the Makefile, you could compile each kernel with its best cuda version, in a single executable. PLEASE POST THE FRANKEN-WEENIE WORKAROUND-- If you could post a Windows executable with the promised features, I'll donate. Quark is faster with release dot 76. I want to use the executable with NiceHash Miner and auto-switch. On Linux, I could compile it myself... but I don't have a working autoswitch script. --scryptr
|
|
|
|
|