Date: Thu, 25 Jul 2013 00:04:37 +0100 From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Rafael's weekly report #6 Hello Alexander, I have some questions about the next task. 2013/7/20 Solar Designer <solar@...nwall.com> > > Rafael, > > On Mon, Jul 15, 2013 at 11:32:51PM +0100, Rafael Waldo Delgado Doblas > wrote: > > 3. Start parallella.port > > Have you started looking into that already? > > As I mentioned recently, I now think we should do Litecoin mining on > Parallella in cgminer codebase, separately from JtR (at least > initially). We promised Litecoin mining to the Parallella community, > but we did not promise it to be part of JtR, and I think they're not > very interested in it being part of JtR (although we may consider this > later). We may nevertheless use this mailing list, as I expect that > some of what we'd be discussing would also be relevant to Katja's > project, and vice versa. I hope this project won't take too long, and > we'd have time left for some JtR tasks before the end of summer as well. > > Alexander I need your advice, Do you think that I should go with this task or do you prefer that I work in something different?. In any way we need to plan milestones for the next task and goals, I think that this is the faster way to develop something. 2013/7/21 Solar Designer <solar@...nwall.com>: > 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"? ;-) > > Alexander Ok, if finally you want that I work on this project, I will work on CGMiner fork ignoring JtR code. I will develop a new driver based on thee existing ARM driver, I think that it wil be better use it as base even if we don't use the ARM CPU. I will compute different instances of scrypt on each Parallella core. Anyway tell me if you really want that I work on this project because looks like it's not that much profitable to do Liteconin minning on Parallella and I would be working on CGMiner instead of JtR. 2013/7/21 Solar Designer <solar@...nwall.com>: > 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 (the >> main problem will be the memory in each core) > > BTW, see this thread: > > "Make Parallella suitable for Litecoin mining" > http://forums.parallella.org/viewtopic.php?f=8&t=276&start=10 > > Alexander I will check it. Best regards, Rafa. Content of type "text/html" skipped
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.