Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Oct 2012 19:53:23 +0400
From: Solar Designer <>
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 <> 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.


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.