Date: Sat, 24 Mar 2012 01:17:09 +0100 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Unifed OpenCL/[CUDA/]CPU formats I got this idea today, I will try it out but here are the general thoughts: A problem with all OpenCL formats is they perform very poor in Single mode because they don't get a full batch of keys. Another problem is that the user need to choose between OpenCL and CPU versions of the same formats - end-users should not have to think about that. A third problem is the sheer number of formats in Jumbo. Having two versions of RAR does not help. So my idea is this: I will not release a "rar-opencl" format. Instead, I will add OpenCL functionality to the existing rar format, #ifdef'ed if building for OpenCL. Furthermore (and this is the punch line), even if built for OpenCL, the format will run in CPU if we got a count less than our announced max_keys_per_crypt. Is there a downside of this? I can think of a couple of caveats: * The self-tests will run on CPU (as they do not fill MKPC). This is a good thing in terms of test time (see separate thread) but the OpenCL part will never get tested and that is a problem. * The benchmark will run on GPU (as it does fill MKPC). This is good, but it will be hard to compare CPU vs GPU performance for this format. I believe the benchmark just measures crypt_all() and cmp_all() but it never checks the result of cmp_all(), right? Maybe we should add such a check in the end - I suppose it could be done after stopping the clock (if that is wanted). BTW I am now approaching 1000 c/s for RAR on GTX280 - still without really profiling it. cRARk does about 3000 c/s for the same length, on same card. I regard that as par and I intend to make a birdie (at some point in space-time). Any ideas, comments, hollers or suggestions are welcome. 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.