[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130720235722.GA8601@openwall.com>
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.
