what speed for i7/i5 haswell family?
sorry,i don't write "for cryptonight".i am interesting this algo and i have 85-89 h/s with cpuminer-core-avx2 with -t 4 on i5-4690k.why speed so slow?
Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 113. (Read 444067 times)
January 26, 2017, 10:56:46 AM
sorry,i don't write "for cryptonight".i am interesting this algo and i have 85-89 h/s with cpuminer-core-avx2 with -t 4 on i5-4690k.why speed so slow?
January 26, 2017, 04:09:13 AM
Ask Limx (https://bitcointalksearch.org/user/limx-dev-389271) to give you the source of his miner.
It's 100% faster than the others and no hashrate fluctations.
https://www.dropbox.com/s/qrny7ghxvnp9l83/minerd.exe?dl=0
It's 100% faster than the others and no hashrate fluctations.
https://www.dropbox.com/s/qrny7ghxvnp9l83/minerd.exe?dl=0
January 25, 2017, 10:12:27 PM
You may start to understand why i try to keep cpuminer-multi "sph lib" intact 
The difference is simple, some algos are much more hungry than others, and hashing 80 bytes often require 2 "loops", most algos use a 64 bytes buffer internally
The difference is simple, some algos are much more hungry than others, and hashing 80 bytes often require 2 "loops", most algos use a 64 bytes buffer internally
Yes but groestly was failing with 64 byte hash, same as x11 and others that work. In the test I did BMW was always first with 80.
This was the chain I captured, ignore the time it's wrong.
0 BMW 80, sph, time 388407
1 Groes 64, sph, time 388412
2 Kecca 64, sph, time 388418
3 JH 64, sph, time 388423
4 Luffa 64, opt, time 388430
5 Cube 64, opt, time 388436
6 Skein 64, sph, time 388444
7 Blake 64 sph, time 388449
It runs the optimized luffa(SSE2) and cube(AVX2) but produces the same hashrate as sph.
This is the first time I have not seen a significant increase with either of these functions.
The code is different there should be some observable difference. Like I said performance is identical
with either, both, or neither optimized functions as long as the chain hasn't changed. That is too much
to be a coincidence. Something else is going on but I have no clue what.
I will take a look at the AES groestl, as I recall there is some commented out code that mentions
it isn't needed for x11 and quark. I assumed it meant it didn't need to support 80 byte input but maybe
there's something else. However, given it's called with the same args as x11, quark, etc, I would have
expected it to behave the same. The only possible difference is the input value itself, maybe there's something
different about the actual inpout data.
This could be one of those puzzles that consumes me.
January 25, 2017, 09:35:56 PM
You may start to understand why i try to keep cpuminer-multi "sph lib" intact
The difference is simple, some algos are much more hungry than others, and hashing 80 bytes often require 2 "loops", most algos use a 64 bytes buffer internally
The difference is simple, some algos are much more hungry than others, and hashing 80 bytes often require 2 "loops", most algos use a 64 bytes buffer internally
January 25, 2017, 06:23:36 PM
I've ben trying to optimize timetravel algo with no success.
First I find it strange that unoptimized it runs slower than unoptimized x11 because timetravel is esentially 8
of the 11 functions in x11. It should be faster. Most other x11 clones run at a comparable speed to x11.
Even stranger is that applying the optimized versions of functions made absolutely no difference in hash rate,
whether the were enabled one at a time or all at once. The unoptimized code performed at the same speed as
the (almost) fully optimized code. This does not make sense. The same functions provided big improvements
in every algo they are used, except this one. And why the exact same speed? It looks suspicious
Given that neither implementation performs at the expected level but both perfrorm at the same level does
not appear to be a coincidence. I have no clue how this could be, the hasrate calculation is done by common code
and every algo does it the same and the pool confirms the displayed hashrate so it doesn't look rigged.
I previously said almost fully optimized because I can't get the AES optimized groestl function to work at all.
It works in every algo that uses it with the same pamameters.
One feature of the algo that is different from most others is that Blake isn't alway the first function in the chain.
In x11 and all similar algos Blake runs first hashing the 80 byte input while all other functions hash the previous
64 byte hash. Theoretically with timetravel any function can be first, and as a result, hashes 80 bytes. I confirmed
that groestl was not running first and was failing with a 64 byte datalen, the same as every other groestl implementation
that works perfectly.
Another observation is that the hashrate varies. Yesterday my CPU was hashing 56 kH/s, today 180kHz. This could be explained
by running a different set of 8 functions which is part of the algo. It runs 8 of the 11 available functions. It may change every block
but I'm not sure what triggers it. Regardless, running a subset of 8 of the 11 functions should always be faster than running all 11,
no matter which 8.
I'm at a loss to explain:
1. why running 8 of the 11 x11 functions runs slower than x11 or any of the other x11 clones, optimized or not,
2. why the optimized code is no faster than unoptimized, every other algo is faster,
3. why the AES groestl doesn't work at all, it works with every other algo.
And I have no idea where to go next.
I could release it as is but with no improvement, why bother. Testing is also a challenge becasuse every function must
now work with 80 byte input since it may at times be in the first position.
First I find it strange that unoptimized it runs slower than unoptimized x11 because timetravel is esentially 8
of the 11 functions in x11. It should be faster. Most other x11 clones run at a comparable speed to x11.
Even stranger is that applying the optimized versions of functions made absolutely no difference in hash rate,
whether the were enabled one at a time or all at once. The unoptimized code performed at the same speed as
the (almost) fully optimized code. This does not make sense. The same functions provided big improvements
in every algo they are used, except this one. And why the exact same speed? It looks suspicious
Given that neither implementation performs at the expected level but both perfrorm at the same level does
not appear to be a coincidence. I have no clue how this could be, the hasrate calculation is done by common code
and every algo does it the same and the pool confirms the displayed hashrate so it doesn't look rigged.
I previously said almost fully optimized because I can't get the AES optimized groestl function to work at all.
It works in every algo that uses it with the same pamameters.
One feature of the algo that is different from most others is that Blake isn't alway the first function in the chain.
In x11 and all similar algos Blake runs first hashing the 80 byte input while all other functions hash the previous
64 byte hash. Theoretically with timetravel any function can be first, and as a result, hashes 80 bytes. I confirmed
that groestl was not running first and was failing with a 64 byte datalen, the same as every other groestl implementation
that works perfectly.
Another observation is that the hashrate varies. Yesterday my CPU was hashing 56 kH/s, today 180kHz. This could be explained
by running a different set of 8 functions which is part of the algo. It runs 8 of the 11 available functions. It may change every block
but I'm not sure what triggers it. Regardless, running a subset of 8 of the 11 functions should always be faster than running all 11,
no matter which 8.
I'm at a loss to explain:
1. why running 8 of the 11 x11 functions runs slower than x11 or any of the other x11 clones, optimized or not,
2. why the optimized code is no faster than unoptimized, every other algo is faster,
3. why the AES groestl doesn't work at all, it works with every other algo.
And I have no idea where to go next.
I could release it as is but with no improvement, why bother. Testing is also a challenge becasuse every function must
now work with 80 byte input since it may at times be in the first position.
January 25, 2017, 09:28:53 AM
A couple of people have opened issues and pull requests at my github. Please don't.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
with all due respect mate ...
isnt that what github is for? ...
btw - you really are doing one hell of a job on this miner ...
kudos buddy - bigtime ...
#crysx
You've touched on a very interesting topic to me, people being forced to conform to the technology
instead of designing the tech to conform to the people.
Git is a tool and tools don't make the rules. It's also a matter of common courtesy to discuss issues with
the dev before taking action, especially when the dev isn't getting paid for his work.
Working for free also gives me the right to be sarcastic or unresponsive if I choose.
this is true ...
but it also allows ( outside of the courtesy factor ) the amalgamation of others skills and code additions and repairs - with ONLY you being the implementer - if you so desire ...
and as the comment summed up quite well - you can be sarcastic or unresponsive whether you are paid or not
...as always mate - a great deal of work for a great deal of people deserves the great deal of respect i have for you ...
i dont forget what you did for me ...
#crysx
January 25, 2017, 09:06:47 AM
Working for free also gives me the right to be sarcastic or unresponsive if I choose.
You can do that even when payed LOL
January 25, 2017, 09:05:00 AM
A couple of people have opened issues and pull requests at my github. Please don't.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
with all due respect mate ...
isnt that what github is for? ...
btw - you really are doing one hell of a job on this miner ...
kudos buddy - bigtime ...
#crysx
You've touched on a very interesting topic to me, people being forced to conform to the technology
instead of designing the tech to conform to the people.
Git is a tool and tools don't make the rules. It's also a matter of common courtesy to discuss issues with
the dev before taking action, especially when the dev isn't getting paid for his work.
Working for free also gives me the right to be sarcastic or unresponsive if I choose.
January 25, 2017, 07:39:44 AM
A couple of people have opened issues and pull requests at my github. Please don't.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
with all due respect mate ...
isnt that what github is for? ...
btw - you really are doing one hell of a job on this miner ...
kudos buddy - bigtime ...
#crysx
January 24, 2017, 10:29:17 PM
A couple of people have opened issues and pull requests at my github. Please don't.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
Any issues or proposals must be discussed with me first. Even if I accept your code I don't
make changes directly in github.
January 24, 2017, 08:52:51 PM
omg are there detailed instructions on how to build it on Windows ?
They aren't hard to find if you look.
January 24, 2017, 11:26:53 AM
Cpuminer-api.o `test -f'api.c'echo'./'`api.c ||
Cpu-miner.c:38:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1667: recipe target'cpuminer-cpu-miner.o'for failed
Make[2]: * * [cpuminer-cpu-miner.o] Error 1
Make[2]: * * * is waiting for the unfinished task...
Util.c:26:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1681: recipe target'cpuminer-util.o'for failed
Make[2]: * * [cpuminer-util.o] Error 1
In file included from api.c:34:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1695: recipe target'cpuminer-api.o'for failed
Make[2]: * * [cpuminer-api.o] Error 1
In file included from uint256.cpp:7:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Cpu-miner.c:38:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1667: recipe target'cpuminer-cpu-miner.o'for failed
Make[2]: * * [cpuminer-cpu-miner.o] Error 1
Make[2]: * * * is waiting for the unfinished task...
Util.c:26:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1681: recipe target'cpuminer-util.o'for failed
Make[2]: * * [cpuminer-util.o] Error 1
In file included from api.c:34:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1695: recipe target'cpuminer-api.o'for failed
Make[2]: * * [cpuminer-api.o] Error 1
In file included from uint256.cpp:7:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
You have missing dependancies.
I see error in curl.
Code:
Dependencies
build-essential (for Ubuntu, Development Tools package group on Fedora)
automake
libjansson-dev
libgmp-dev
libcurl4-openssl-dev
libssl-dev
pthreads
zlib
January 24, 2017, 11:19:43 AM
Cpuminer-api.o `test -f'api.c'echo'./'`api.c ||
Cpu-miner.c:38:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1667: recipe target'cpuminer-cpu-miner.o'for failed
Make[2]: * * [cpuminer-cpu-miner.o] Error 1
Make[2]: * * * is waiting for the unfinished task...
Util.c:26:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1681: recipe target'cpuminer-util.o'for failed
Make[2]: * * [cpuminer-util.o] Error 1
In file included from api.c:34:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1695: recipe target'cpuminer-api.o'for failed
Make[2]: * * [cpuminer-api.o] Error 1
In file included from uint256.cpp:7:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Cpu-miner.c:38:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1667: recipe target'cpuminer-cpu-miner.o'for failed
Make[2]: * * [cpuminer-cpu-miner.o] Error 1
Make[2]: * * * is waiting for the unfinished task...
Util.c:26:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1681: recipe target'cpuminer-util.o'for failed
Make[2]: * * [cpuminer-util.o] Error 1
In file included from api.c:34:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
Compilation terminated.
Makefile:1695: recipe target'cpuminer-api.o'for failed
Make[2]: * * [cpuminer-api.o] Error 1
In file included from uint256.cpp:7:0:
Miner.h:39:23: fatal error: curl/curl.h: does not have that file or directory
January 24, 2017, 11:06:03 AM
./build.sh
Make: * * No to make target'clean'rule. Stop it。
Clean
./autogen.sh: 8: aclocal: not./autogen.sh: found
Done
./build.sh: line 21:./configure: does not have that file or directory
Make: * * * does not specify target and cannot find makefile. Stop it。
Strip: cpuminer: no this file
Make: * * No to make target'clean'rule. Stop it。
Clean
./autogen.sh: 8: aclocal: not./autogen.sh: found
Done
./build.sh: line 21:./configure: does not have that file or directory
Make: * * * does not specify target and cannot find makefile. Stop it。
Strip: cpuminer: no this file
January 24, 2017, 12:28:53 AM
"autoreconf && make" after configure.ac or Makefile.am edit
without that the Makefile remains inchanged and make clean doesnt help
without that the Makefile remains inchanged and make clean doesnt help
Thanks for the tip.
Makefile Makefile.in and configure are all ignored by git. make distclean does not delete configure or Makefile.in.
As a result they have been shipped in the tarball.
They get rebuilt if configure.ac or makefile.am, respectively, are modified so everything works out
as long as I remember to edit only Makefile.am and configure.ac. This time I forgot and editted configure.
I may start doing an autoreconf before building the tarball, if i don't forget. Sometimes I have forgotten to
to do a distclean but have always caught it so far I think.
January 23, 2017, 08:53:52 PM
"autoreconf && make" after configure.ac or Makefile.am edit
without that the Makefile remains inchanged and make clean doesnt help
without that the Makefile remains inchanged and make clean doesnt help
January 23, 2017, 12:15:29 PM
cpuminer-opt v3.5.1 is released with faster bastion and m4 git workaround.
https://bitcointalksearch.org/topic/m.13542056
https://bitcointalksearch.org/topic/m.13542056
Strange...
After successful pull from git, make clean and make distclean, the binary still says v3.5.0, not v3.5.1
The configure file doesn't get deleted by make distclean but does get deleted by git. As a result the version
change was lost when I uploaded to git. I should have made the change in configure.ac instead of configure.
Had git been aligned with "make distclean" I would have discovered the error.
Edit: try it now I just pushed a fix for configure.ac
January 23, 2017, 11:50:52 AM
cpuminer-opt v3.5.1 is released with faster bastion and m4 git workaround.
https://bitcointalksearch.org/topic/m.13542056
https://bitcointalksearch.org/topic/m.13542056
Strange...
After successful pull from git, make clean and make distclean, the binary still says v3.5.0, not v3.5.1
January 22, 2017, 09:11:30 PM
cpuminer-opt v3.5.1 is released with faster bastion and m4 git workaround.
https://bitcointalksearch.org/topic/m.13542056
https://bitcointalksearch.org/topic/m.13542056
January 22, 2017, 06:24:25 PM
How old is your CPU? It needs to be 64 bit.
ok that explains everything. its a 32bit CPU, my bad :/
Jump to: