[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121008155323.GA8250@openwall.com>
Date: Mon, 8 Oct 2012 19:53:23 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Password hashing at scale (for Internet companies with millions of users) - YaC 2012 slides
On Mon, Oct 08, 2012 at 10:05:44AM +0530, Sayantan Datta wrote:
> On Mon, Oct 8, 2012 at 12:48 AM, Solar Designer <solar@...nwall.com> wrote:
>
> > A few months ago, when Xeon Phi was first announced under this name,
> > Intel supported OpenMP for it, but not OpenCL yet. An Intel person
> > commented on a forum that OpenCL would likely be available later. So I
> > doubt that there's OpenCL for these yet.
>
> I've read somewhere that next generation of Nvidia gpus code named maxwell
> will tightly integrate some ARM cores with them. I guess then we could use
> the gpus for efficient password generation too. Also AMD's next generation
> of APUs(excavator or later) intends to do the same with x86 instead of
> ARM.
The above has a lot of things mixed up, making it difficult to comment
on. We're already able to use GPUs for efficient password generation -
we just haven't implemented that in JtR in particular yet. As to future
devices from NVIDIA and AMD with tightly coupled CPU and GPU cores, I
expect these will be quite different from Xeon Phi, although I must
admit I haven't read the currently available documentation on them yet.
With Xeon Phi, each of its CPU'ish cores directly controls its SIMD
unit - just like normal CPUs do, but with a simpler CPU core (based off
the original Pentium, so no out-of-order execution, etc.) and with wider
SIMD vector width (512-bit vs. AVX2's 256-bit). With tightly coupled
CPU and GPU cores in APUs, the architecture is more similar to what we
have in computers with discrete CPU and GPU chips now - that is, I
expect those embedded GPUs to run code on their own rather than have
their SIMD units directly controllable by the CPU cores.
> Accorinding to the picture(in your slides) the xeon phies seems to be
> running on a PCIe bus. But if it can load an OS then does it mean we can
> use the phi as the host system and the cpu/gpus as the supporting devices?
Perhaps a Xeon Phi will technically be able to control GPU cards nearby,
but I doubt this is going to be officially supported. The host CPU has
more than enough computing power to control a typical system's GPUs
anyway, so there's no need to offload that to a faster coprocessor.
For tasks that require computation on both Xeon Phi and GPUs at once
(not just GPU control, but actual computation on the Xeon Phi), I guess
it'd be most straightforward for the host to arrange DMA transfers
between the devices, but to keep the control logic on the host.
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.
