jgarzik (OP)
Legendary
Offline
Activity: 1596
Merit: 1100
|
|
March 30, 2011, 08:11:32 PM |
|
This is expected. As mentioned, sse2_64 only works on 64-bit Linux at the moment, so this high speed is not available under Windows.
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
enigmatic
Newbie
Offline
Activity: 1
Merit: 0
|
|
March 30, 2011, 08:47:03 PM |
|
I just downloaded bitcoin a few days ago and since I have MinGW and MSYS installed and built some programs from source before, I downloaded and built all of the prerequisite libraries and statically compiled the latest git revision of this miner. It requires no DLLs or other external files and it's only 609KB compressed with UPX. I tried attaching it to this post, but there's a 128KB limit.
To build a static minerd.exe for Windows: 1. Get MSYS and MinGW. I couldn't get autoconf to work so I just used the ./configure from minerd version 0.8.1. 2. Download libiconv, libidn, libssh2, openssl, zlib, curl, and pthreads-w32 sources. 3. Build libiconv, libidn, zlib, and openssl first (with "./configure --enable-static --disable-shared" and then "make"). 4. Install (with "make install") each of those libraries. 5. Build and install libssh2 (same process as before), which should detect the libcrypto and libssl from openssl and the other things. 6. Build and install libcurl (same process as before), which should detect the previous libraries. 7. Build pthreads using "make clean GC-static" and then copy pthread.h, sched.h, and semaphore.h to your "include" folder and rename libpthreadGC2.a to libpthread.a and copy it to your lib folder. 8. Edit the ./configure from minerd 0.8.1 and change "libcurl_cv_lib_curl_usable=no" to "libcurl_cv_lib_curl_usable=yes" which is needed because of a bug in the ./configure script. 8. Use ./configure --host=i686-w64-mingw32 (or whatever your MinGW is called) to configure the CPU miner. 9. After ./configuring the CPU miner, edit the makefile and add "-DCURL_STATICLIB -DPTW32_STATIC_LIB -DHAVE_STRUCT_TIMESPEC=1 -msse2" to the end of the "CFLAGS =" line. 10. Edit cpu-miner.c and add "ptw32_processInitialize();" just before the "pthread_mutex_init(&time_lock, NULL);" in the main() function. 11. Then make it, and if all worked well there should be a file called minerd.exe. 12. Use "strip minerd.exe" to remove unused code and labels from the EXE which will greatly reduce its size. 13. Optionally compress the EXE using UPX.
I might have forgotten a few steps but the EXE that I made works and contributes shares to slush's pool. The good thing is that you only need to do steps 10-13 if you want to update it since the libraries are installed already. Maybe an "#ifdef PTW32_STATIC_LIB" for the "ptw32_processInitialize();" call would make things easier.
|
|
|
|
chromicant
Newbie
Offline
Activity: 40
Merit: 0
|
|
March 30, 2011, 09:08:01 PM |
|
This is expected. As mentioned, sse2_64 only works on 64-bit Linux at the moment, so this high speed is not available under Windows.
For those who want to take on a challenge, what you need to do to allow sse2_64 to run on Win64 boxes is to change the assembly to handle the Windows ABI for x86_64. This is a useful starting point: https://secure.wikimedia.org/wikipedia/en/wiki/X86_calling_conventions#Table_of_x86_Calling_Conventions.5B1.5DSince I don't do Windows development, I'm not going to port it. However, I'll look at pull requests on my SSE2 branch.
|
|
|
|
adv
|
|
April 01, 2011, 02:33:11 AM |
|
Default user/password dont work in 0.8.1.
|
U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
|
|
|
jgarzik (OP)
Legendary
Offline
Activity: 1596
Merit: 1100
|
|
April 01, 2011, 03:30:23 AM |
|
Default user/password dont work in 0.8.1.
You're not really supposed to use the default name/password...
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
adv
|
|
April 01, 2011, 05:21:25 AM |
|
Default user/password dont work in 0.8.1.
You're not really supposed to use the default name/password... I do not see much point in using a password for mining. What can an attacker? Solve instead of me a couple of blocks? :^) Another thing that bitkoin's bad design allows the machine that has access to getwork use the rest of the RPC-calls. So I use a simple proxy, which transmits to bitcoin only specified calls. P.S. Also short options -u and -p dont work in my build. btc-cpuminer --url http://aaa:bbb@localhost:8334 -u ccc --pass ddd btc-cpuminer: invalid option -- 'u' P.P.S. Generally speaking curl supports the standard pattern of URI and you just can use user name and password directly in the URL like " http://user:pass@example.net/some/page". And you can remove the unnecessary handling of the three options from the program. : ^) Seriously I think is worth preserving the opportunity specify the user name and password are separate options, but must also be able to omit them and use specified in the URL. And in this case "userpass" option dont need totally.
|
U may thank me here: 14Js1ng1SvYBPgUJnjNAEPYH4d6SHF79UF
|
|
|
pedropants
Newbie
Offline
Activity: 1
Merit: 0
|
|
April 03, 2011, 08:56:21 PM |
|
Try replacing "-f elf64" with "-f macho64" in the x86_64/Makefile as a workaround.
Unfortunately, sha256_xmm_amd64.asm will not assemble into a macho64 binary, with this error: $ yasm -f macho64 sha256_xmm_amd64.asm sha256_xmm_amd64.asm:106: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.
And even though it assembles to an ELF64 binary just fine, the mac linker can't handle ELF objects. Googling that yasm error shows some promising hits, but sadly I do not know assembly at all, so I'm out of my league trying to fix it.
|
|
|
|
lfm
|
|
April 05, 2011, 05:57:11 AM |
|
the "-algo cryptopp_asm32" just seg faults for me on linux 32bit, via C7 cpu.
It seems it dosen't even build on linux64 (hence the name)
Has anyone run this algo successfully?
|
|
|
|
ancow
|
|
April 11, 2011, 09:21:46 PM |
|
I just noticed this - the date reads a month in the past in the CPU miner. Is this a problem on my end? My computer's date/time are set correct.
Actually it seems like an off-by-one error in the code. If memory serves me right (and it has been a few years since my last brush with C), tm_mon is zero-based, so the following diff should be applied to util.c: --- cpuminer-git/util.c 2011-04-11 21:12:43.469374001 +0200 +++ cpuminer-compile/util.c 2011-04-11 21:22:49.149374000 +0200 @@ -80,7 +80,7 @@ f = alloca(len); sprintf(f, "[%d-%02d-%02d %02d:%02d:%02d] %s\n", tm.tm_year + 1900, - tm.tm_mon, + tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min,
|
BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 11, 2011, 09:51:52 PM |
|
Good spotting. Pushed off-by-one fix into git.
|
|
|
|
lfm
|
|
April 11, 2011, 09:53:53 PM |
|
I just noticed this - the date reads a month in the past in the CPU miner. Is this a problem on my end? My computer's date/time are set correct.
Actually it seems like an off-by-one error in the code. If memory serves me right (and it has been a few years since my last brush with C), tm_mon is zero-based, so the following diff should be applied to util.c: --- cpuminer-git/util.c 2011-04-11 21:12:43.469374001 +0200 +++ cpuminer-compile/util.c 2011-04-11 21:22:49.149374000 +0200 @@ -80,7 +80,7 @@ f = alloca(len); sprintf(f, "[%d-%02d-%02d %02d:%02d:%02d] %s\n", tm.tm_year + 1900, - tm.tm_mon, + tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, should just use strftime() instead! something like : strftime(f, len, "[%F %T]", &tm);
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 11, 2011, 10:56:56 PM |
|
Yeah, strftime can help, but must be certain of the format string being supported in Windows.
|
|
|
|
Zenitur
|
|
May 06, 2011, 09:59:52 AM Last edit: May 06, 2011, 10:12:04 AM by Zenitur |
|
the "-algo cryptopp_asm32" just seg faults for me on linux 32bit, via C7 cpu.
It seems it dosen't even build on linux64 (hence the name)
Has anyone run this algo successfully? I successfuly started this algo with 64-bit Gentoo and was Segmentation fault with 32-bit Kanotix LiveUSB. Same problem. Update: tried latest GIT and saw same error.
|
|
|
|
singpolyma
|
|
May 06, 2011, 01:53:48 PM |
|
As an interesting data point: 4way with 3 threads gave me 700 khash/s, whereas the normal c impl gets me 930khash/s
|
|
|
|
walidzohair
|
|
May 07, 2011, 12:06:08 PM |
|
Why sse2_amd64 algorithm did not compiling? My system is ubuntu 10.04 64 bit and Core2Duo P8400 cpu.
As I can see in miner.h there is a definition WANT_X8664_SSE2, with checking sse2 support. But checking don't passing. When i comment this checking and try to 'make' there is an error:
Don't do that. There's a reason the check is failing. If you looked at config.log, it probably says your version of yasm is 0.8.0. You need 1.1.0. For Ubuntu, you either compile it yourself or get the right version from Debian's repository. I have yasm 1.1 and it shows it is ok on ubuntu natty but still no 4way in the compiled minderd. any help ?
|
|
|
|
walidzohair
|
|
May 07, 2011, 12:07:55 PM |
|
As an interesting data point: 4way with 3 threads gave me 700 khash/s, whereas the normal c impl gets me 930khash/s
So which algo is the fastest on teh same intel CPU ? c or crpto or arypto_asm32 or 4way ?
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
May 10, 2011, 02:17:57 AM |
|
Version 1.0 release. See top post for URLs.
Changes: - jansson 2.0 compatibility - correct off-by-one in date (month) display output - fix platform detection - improve yasm configure bits - support full URL, in X-Long-Polling header
|
|
|
|
Spoddy
Newbie
Offline
Activity: 2
Merit: 0
|
|
May 10, 2011, 09:42:38 AM |
|
Configure runs ok, but I'm getting a make error, . sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available sha256_4way.c:458: sorry, unimplemented: called from here sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available sha256_4way.c:458: sorry, unimplemented: called from here sha256_4way.c:51: sorry, unimplemented: inlining failed in call to ‘ROTR’: function body not available sha256_4way.c:458: sorry, unimplemented: called from here make[1]: *** [sha256_4way.o] Error 1 make[1]: Leaving directory `/home/spoddy/cpuminer-1.0' make: *** [install-recursive] Error 1 spoddy@bob:~/cpuminer-1.0$ cd ../bitcoin-0.3.21/
I'm a *nix newbie so any help would be appreciated.
|
|
|
|
walidzohair
|
|
May 10, 2011, 11:28:12 AM |
|
If anybody is interested, this is the assembly code from Intel Compiler which gives me the fastest 4way code on AMD K10. 1.13 GH/s MH/s per 1 GHz per physical core. https://gist.github.com/853566Compile cpuminer-0.7.1, download the above code, issue: gcc -c sha256_4way.s and do make again to link the object file to the executable. It's about 7% faster than the gcc version. That is what I get sha256_4way.s:11221: Error: bad register name `%rbp' sha256_4way.s:11223: Error: bad register name `%rbx' sha256_4way.s:11225: Error: bad register name `%r15' sha256_4way.s:11227: Error: bad register name `%r14' sha256_4way.s:11229: Error: bad register name `%r13' sha256_4way.s:11231: Error: bad register name `%r12' a lot of this when i tried gcc -c sha256_4way.s
|
|
|
|
walidzohair
|
|
May 10, 2011, 11:40:28 AM |
|
A new CPU miner is now available, making use of the new 'getwork' RPC command. In the beginning, this is intended largely to demonstrate a 'getwork' miner. It is written in straight C, with minimal dependencies (libcurl, jansson). It has successfully generated blocks on testnet, mainnet and almost all pools. Linux/BSD release tarball: http://yyz.us/bitcoin/cpuminer-1.0.tar.gzWindows installer: http://yyz.us/bitcoin/cpuminer-installer-1.0.zipgit repository: git://github.com/jgarzik/cpuminer.git Contributions welcomed! (GPL v2 license) anyway to support sse2 on ubuntu ?
|
|
|
|
|