Topic: New demonstration CPU miner available - page 11. (Read 386323 times)

As an interesting data point: 4way with 3 threads gave me 700 khash/s, whereas the normal c impl gets me 930khash/s

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.

Yeah, strftime can help, but must be certain of the format string being supported in Windows.

should just use strftime() instead! something like :

     strftime(f, len, "[%F %T]", &tm);

Good spotting.  Pushed off-by-one fix into git.

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:

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?

Unfortunately, sha256_xmm_amd64.asm will not assemble into a macho64 binary, with this error:


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.

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.
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:[email protected]/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.

You're not really supposed to use the default name/password... 

Default user/password dont work in 0.8.1.

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.5D
Since I don't do Windows development, I'm not going to port it. However, I'll look at pull requests on my SSE2 branch.

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.

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.

moving from https://bitcointalksearch.org/topic/m.75264 till end of page #24


http://bayimg.com/KaEgHaADl

win xp sp3 32bit

Q9550 @ 2,83Ghz

tuned all threads affinity with task manager to one core

That was taken for granted, yeah.

Really? Double checking myself. 0.o I'd disagree about the macro abuse though. The unrelated code I'm working on has quite a bit of macro usage removed with the help of template metaprogramming.

Edit: After double checking I can safely and easily say I was wrong indeed
is right. My mind must be playing tricks on me sorry. :S Now to go eat!

Sorry, I wasn't suggesting replace all your code, obviously the initialisation and the (some code) block would be retained. It's just the if {} block I meant.

LMGTFY's code is correct, and you are mistaken (about not only this, but macro abuse etc. also)

It would be if it were correct but it's not, the program flow would change regardless of whether or not rc were initialized.