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.