Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Jul 2013 00:04:37 +0100
From: Rafael Waldo Delgado Doblas <>
Subject: Re: Rafael's weekly report #6

Hello Alexander,

I have some questions about the next task.

2013/7/20 Solar Designer <>
> 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 <>:
> 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
>> 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 <>:
> On Sat, Jul 20, 2013 at 11:16:01PM +0100, Rafael Waldo Delgado Doblas
>> 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
>> main problem will be the memory in each core)
> BTW, see this thread:
> "Make Parallella suitable for Litecoin mining"
> Alexander

I will check it.

Best regards,

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.