Date: Sun, 21 Jul 2013 03:57:22 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: Rafael's weekly report #5 Rafael, Going forward, inline quoting of relevant context will help. Really. Regarding Litecoin mining on Parallella: On Sat, Jul 20, 2013 at 11:16:01PM +0100, Rafael Waldo Delgado Doblas wrote: > Well, I was thinking about it and maybe if we want to reach ASAP this > target, we can adapt the opencl implementation to work with parallella You could try that, although I am skeptical. > (the main problem will be the memory in each core) Actually, cgminer supports configurable "gap" on GPUs, so reducing scrypt's memory needs as appropriate should be easy. As to whether the OpenCL kernel itself will easily fit, I am not sure. Besides, if it does fit, but uses much memory, we'd have to set the gap higher, which will reduce performance. With a manual approach (C and possibly asm), we probably have greater control over our code size, so we can use lower gap (and thus achieve higher speed). > and also we can use the CPU > to raise the mining power (there an ARM litecoin implementation). Yes, but I don't care about it very much. The reason why I brought up the issue of (not) using ARM cores in context of Katja's project is because bcrypt cracking on Parallella may actually be more than a PoC on 64-core boards (with speeds comparable to normal desktop CPUs, so someone with one or more of these boards would possibly make use of them for cracking as well). Litecoin mining on Parallella, I'm afraid, is just a PoC - to show whether e.g. 1024-core boards would achieve "profitable" speeds right now (which, unfortunately, would not mean that they would still be profitable if/when actually produced at best e.g. a year later). At these core counts, two extra cores won't matter much. Also, if you don't waste the ARM cores then someone would be able to start a second instance of cgminer on them. (This works for JtR, too, but may be less convenient since the workload would need to be distributed to the two instances manually or at best with "--node". Also, Katja's current implementation actually keeps one ARM core at 100% load with active polling.) A reason why bcrypt fits Epiphany better than Litecoin/scrypt does, as compared to running these two on current x86 CPUs, is that bcrypt uses 32-bit memory lookups a lot, which were unavailable in SIMD form prior to AVX2 (and are slow with AVX2 on Haswell). Litecoin/scrypt uses 128-bit SIMD efficiently. So this gives a ~4x efficiency gap between these two on current x86 CPUs, whereas there's no such gap on Epiphany (on the contrary, we have to do 2x+ more computation to compensate for the limited local memory size, as compared to merely doing cache line sized L2 cache reads on x86). Overall, the current 64-core Epiphany will likely run slower than current x86 CPUs, and as you're aware (such as from cgminer dropping this code) it is already not profitable to do Litecoin mining on CPUs, with electricity costs considered - maybe by a factor of 10 or so. (Some people get "free" electricity, though.) Maybe it'd be OK in terms of electricity costs on 64-core Parallella, but the earnings would still be low in dollar terms. > Otherwise I'll need to implement from scratch a Parallela driver for > cgminer. Yes, almost - although you can reuse e.g. official scrypt's "-nosse" implementation and implement your changes (such as adding TMTO) based on that C code. You can probably also reuse some pieces of code from other cgminer drivers. Are you looking for "integration" type of work (like what you have been doing with JtR and cgminer so far) or "actual programming"? ;-) Regarding: > > > Priorities: > > > 1. Debug errors. > > > 2. Make documentation you wrote: > About the first two point I'm working on it and I will have finished it by > Monday. OK. Please also implement other changes/cleanups that I pointed out in the lengthy message today (well, except for those that you may disagree with - state it if so), and document that version. Thanks! Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.