Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
