Q: When I click on minerd.exe a black window flashes up and then disappears.A: This is a command-line application, it has no graphical interface. You'll need to learn how to use the command line interface (CLI) of your operating system first.

Q: Can I mine (insert your cryptocoin here) with this miner?A: Only if its proof-of-work algorithm is scrypt or SHA-256d. This miner does not currently support other algorithms such as Keccak, scrypt-jane, X11, etc. Forks of this project may provide additional algorithms, but I do not maintain them and they are not discussed here, so if you have questions about them please contact their authors.

Q: When running configure I get the error "C compiler cannot create executables".A: Make sure you typed CFLAGS="-O3" with a big O, not with a zero.

Q:autogen.sh dies with "error: possibly undefined macro: AC_MSG_ERROR".Q:configure chokes on something like "LIBCURL_CHECK_CONFIG(, 7.15.2, ,'".A: Make sure you have installed the development package for libcurl. If you have and you're still getting the error when compiling from git, try compiling from tarball instead.

Q: I'm trying to connect to a Stratum server, but I get "HTTP request failed: Empty reply from server".A: Make sure you specified the correct protocol in the server URL (stratum+tcp://).

Q: Is there any command-line option I can play with to make it mine faster?A: No. The miner automatically picks the best settings for the CPU it is run on.

Q: What's the difference between the two algorithms, scrypt and sha256d?A: They are completely different proof-of-work algorithms. You must use scrypt for Litecoin, and you must use sha256d for Bitcoin. The default algorithm is scrypt, so for Bitcoin mining you have to specify --algo=sha256d.

Q: Will this miner use a lot of RAM when using the scrypt algorithm?A: No, that's a GPU thing.

Q: How do I make the miner write its output to a file instead of printing it to the screen?A: Just redirect the standard error stream to file:

Code:

minerd [OPTIONS] 2> myfile

You may also want to use the --quiet/-q option to disable the per-thread hashmeter.On *nix, you probably also want to use the --background/-B option to fork in the background.

Original post (December 19, 2011) follows. Please note that most of the technical details are now outdated.I have recently rewritten the heart of the scrypt hashing function used by the jgarzik/ArtForz cpuminer in assembly language, to see if this could bring some more speed. Apparently it did. The source code is now available at GitHub:https://github.com/pooler/cpuminerThe build process for Linux should be the same as before.

In the new code I tried to take full advantage of SSE2 instructions, which are available since the Pentium 4. Unfortunately, AMD's implementation of these instructions is not as fast as Intel's... well, ok, sadly it's nearly two times slower. For this reason, I had to write separate versions of the hashing functions. You don't need to worry about this, though, since the new function should be able to auto-detect your cpu and automatically select the best algorithm.

Long polling patchThis release also includes a new --timeout option that I originally added to solve a problem with long polling. Apparently the LP thread doesn't behave nicely under certain network conditions, as reported by various users. So, if you experienced high stale rates with the previous miner, you should definitely try out this new version.Many thanks to SockPuppet, aka shawnp0wers, who helped me nail down the issue!

Some Technical DetailsThe current release includes four different implementations of the scrypt core, each one designed for a different hardware.

A fallback plain x86 version, to be used when SSE2 instructions are not available (Pentium III, Athlon XP and earlier processors).

A 32-bit version using SSE2, for use on the Pentium 4, Pentium M, Core, Atom, plus all 64-bit cpus running in a 32-bit OS.

A 64-bit version for Intel processors, i.e. Core 2, i3, i5, i7. This version can in most cases double the speed of the previous miner.

A 64-bit version for AMD processors, i.e. Athlon 64, Phenom, Sempron and the like. The speed increase here can range from 5% to 80%.

The first two versions only get compiled in the 32-bit miner, the last two only in the 64-bit miner. The miner uses the CPUID instruction to choose which version to use.

Compiler FlagsOne cool aspect of assembly code is that users no more need to play with compiler flags to get the best performance. Configuring the build with just CFLAGS="-O3" is now more than enough to get efficient code. This also means that we no more need separate specialized binaries for Intel and AMD cpus. Just a 32-bit and a 64-bit version.

Final NotesSomeone on IRC asked me why I am releasing this miner, instead of keeping it for myself or for my pool. Well, that's exactly the point. It is important for Litecoin that everybody has access to the most efficient mining software!Someone might worry about the effect of this release on market prices, but consider this: if everybody starts using the new miner, the hash rate will go up, but so will difficulty, so nothing will ultimately change. I actually think this new miner will be very beneficial to Litecoin, because it should make mining easier for beginners (see compiler flags).As crazy_rabbit wrote in another thread, one big plus of Litecoin is that everybody can participate. Well, consider this: now you can effectively mine on an Atom!

Alright folks... I hope you enjoy the performance boost. Consider this as my Christmas present to the community!

My part was little more than that of a trained monkey, but I was happy to help troubleshoot.

One huge thing we hashed out just last night was the OSX compatibility stuff. I'm not sure if pooler has updated the github repo with the changes required for OSX compilation, but if nothing else I can post an OSX 10.6 compatible binary here. (It works with 10.7 too, 10.4 requires a bit more work and will be available later...)

That's the same exact problem SockPuppet and I faced yesterday. I still don't know why but apparently the assembler available on MacOS doesn't like my macros.We finally got it to compile by expanding all macros in the source, but don't ask me to do that again (ok, if you insist I can send you the temporary patched file.)I will try to solve the issue with SockPuppet as soon as possible, I am really curious about where the problem actually lies.

Coblee, yeah -- those are some of the issues we worked through last night. It took hours, because pooler doesn't have a mac, and I don't have any assembly skillz.

The short version is, all macros need to be expanded (ie, eliminated), and then if he hasn't changed them, a few MOVQ ops need to be changed to the incorrect-but-still-works-and-makes-apple-happy MOVD.

The reason I'm still having problems with 10.4 is that we didn't do any work on scrypt-x86.S, and it has even more macros than the 64 bit one.

In case you're wondering why the SSE2 version sucks on K8 and K10 ... reason is rather simple.the salsa20 function is a long string of data dependent 4*32-bit vector integer operations (i.e. output of one operation is used as input to the next).And the execution latencies for the most used instructions in the salsa20 core (shift r/l immediate, add, xor) are all 2 clocks on K8/K10, all 1 clock on Atom/Core/Core2/Nehalem/SB.End result ... sse2 salsa20 needs roughly twice the clocks/round on AMD compared to any modern intel.