The scrypt algorithm seems to be a prominent feature in the "CPU friendly" Bitcoin clones for the proof-of-labor part. I've heard claims that it's relatively slow on Windows and/or Intel compared to Linux/AMD.

Is this true? By how much? Does anyone have concrete data on this? Is there a difference between 32 bit and 64 bit OS?

Bonus : could it be implemented more efficiently (power consumption and/or hardware cost wise) on dedicated hardware?

  • $\begingroup$ There are no "CPU friendly" cryptocurrencies, only "GPU hostile, custom-hardware-friendly" cryptocurrencies. See bitcoin.stackexchange.com/questions/1305/… $\endgroup$
    – eldentyrell
    Oct 10, 2011 at 10:13
  • $\begingroup$ Any measurements for specific CPUs will depend quite hard on the memory/CPU factor $N$. If all the hashes needed still fit in some cache, this will be quite than if they don't fit. $\endgroup$ Oct 10, 2011 at 18:29

3 Answers 3


I've heard claims that it's relatively slow on Windows and/or Intel compared to Linux/AMD.

The claim that it could be Windows/Linux is a little off. It is more likely to be Intel/AMD, if anything. This will be an implementation detail based on the relative costs of processor instructions on each architecture; for example inc instructions are cheap on AMD, but costly on core 2 processors (relative to the speed of processors. You won't notice this difference unless you measure it).

In order to see numbers I suggest having a read of the x86 latency measurements made during the development of libgmp. They're slightly dated, but give you a fair idea that in fact not all assembly instructions cost equal.

Does this mean scrypt performs better on one processor or the other? Not at all. It means the implementation of scrypt measured performs better on one processor or the other. You should be able to produce optimised versions of scrypt for each architecture. This is, internally, what libgmp does for your multiprecision arithmetic - the optimised code for your architecture is the one you link to.

I'm not really a compiler expert, so I can't really comment on the behaviour of C compiled versions, but to achieve full optimisation you'd likely need to start from the assembler output of a compiler anyway.


I think linux thing is a case of "real programmers code and test under linux, then cross-compile", which results in a code that is far more tailored to linux systems.

Intel processors (especially lower-end ones) tend to have a smaller L2 cache and if I read the scrypt paper right, that somewhat hobbles them. See comparison here http://www.hardwaresecrets.com/article/819 Apparently, Core i5-750 specifically has whole 256k of L2 cache less, while scrypt as implemented in Tenebrix eats up no less than 128k of cache. This not only "keeps intel down" but will (obviously) reduce the potential benefits of HT.

Now, obviously good compile flags might mitigate that a bit, but you can't make the CPU grow some more cache, so some AMD superiority is to stay.

As for windows/linux programming, I am not a programmer (just an overclocking enthusiast) so I can't give much useful info on that

EDIT P.S. (to some comments above)

You know, I am starting to get mildly annoyed at the "Scrypt-PoWs are friendly to custom hardware" myth.

No they are not.

Even in their meekest weakest incarnation, they render CPUs the most likely winners in bang-per-buck competition, simply because CPUs crunch them decently with bearable power consumption and, due to economies of scale are cheap.

Custom hardware would need to compete with something vastly cheaper and vastly more available.

A Rational Well-Funded Attacker won't deploy thousands of exotic computation devices $5000-10 000 a pop. He will use his huge money supply to build a huge cluster using COTS CPUs.

Having said that, idea of defending against a Well-Funded attacker via technological tweaks is a fallacy - like I already said elsewhere, it does not matter whether your algo is CPU friendly, GPU friendly, or Babbage engine friendly. Attacker will just buy a bigger pile of "most efficient hardware" than you could afford.

That's the benefits of being well-funded.

  • 1
    $\begingroup$ Sure, an infinitely-funded attacker can just buy a bigger pile of whatever works best. But these different techniques have vastly different ratios of attacker dollars to non-attacker dollars. Whether an attack is possible in practice or only in theory makes a huge difference. $\endgroup$ Oct 10, 2011 at 20:26
  • $\begingroup$ That is basically an argument about what works "best", not the general principle. However, to return to scrypt specifically, even in relatively meek cases seen in alt-coins so far it's already pretty mean to FPGAs and likely to ASICs (though I'd suggest a beefier version that was discussed on the forum just in order to quench paranoia of the "government will deploy ASICs" sort). Of course we can hypothesize a cost-efficient and powerful scrypt supersolver unlike nothing seen before. We can hypothesize same for plain BTC PoW too. If anything, I'd say it has better attacker$/legitimate$ rate $\endgroup$
    – Black
    Oct 10, 2011 at 21:07

There is no technical reason why Windows binaries would underperform Linux binaries when it comes to computing scrypt. Any delta in performance is simply due to immature code on windows platform. Despite ripper not liking the answer above both miners using scrypt were built on Linux and then simply quickly ported over. One of the developers admits to having limited knowledge in Windows programming and has no intention on optimizing Windows performance. Obviously a quick and dirty port from one OS to another isn't going to achieve full potential however a sample size of 2 doesn't make a trend. If there is enough demand someone will eventually produce a miner with equivalent performance on Windows platform.

  • $\begingroup$ You could even compile the core code to assembly using GCC on Linux and then run the assembly code on Windows where it would perform almost exactly the same. $\endgroup$ Oct 10, 2011 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.