[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
