[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 9 Aug 2013 16:03:56 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Intel OpenCL on CPU and MIC
On 8 Aug, 2013, at 23:32 , Solar Designer <solar@...nwall.com> wrote:
> -cl-strict-aliasing was not understood by (and resulted in errors from) Intel's OpenCL compiler. (Should we make this change standard?)
This is a violation of OpenCL, that option is mandatory ever since 1.0 afaik. We can drop it for now but we should probably use it selectively - some compilers may produce faster code with this option, right?
> I am fairly certain that the kernel was not vectorized, which is why the poor speed.
My experience with different CPU drivers is that some do best from a scalar kernel (auto-vectorizes and uses SIMD) while other drivers do better from a vectorized kernel. No one-size-fits-all unfortunately. Some of my formats & kernels honor the --request-vectorize option just to experiment with that.
> I am getting roughly the same cumulative speed by building the whole JtR right for Xeon Phi and running it there. No OpenMP that way for a subtle reason that I can explain separately, but I did run with --fork=228, for a cumulative speed at bcrypt of around 6000 c/s.
A good speed would be at least 10x that, no? What could be the reason for such a low figure? What speed do you get from one core?
I'm hoping I will find time to start experimenting on 'well' within a few weeks.
magnum
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.
