Date: Fri, 17 Aug 2012 08:46:38 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: bitslice DES on GPU Sayantan - On Thu, Aug 16, 2012 at 10:14:35PM +0530, Sayantan Datta wrote: > What is the use of parameter DES_bs_cpt? cpt stands for "crypts per thread". We have these not only for DES, but also for md5crypt and bcrypt. It is the relative increase in number of candidate passwords hashed per call to crypt_all() per thread, as compared to what crypt_all() does in a non-OpenMP build. The purpose for having such an increase is to reduce overhead on thread management and to let threads run for longer without being forcibly synchronized. On the other hand, large cpt settings increase the working set size of crypt_all() (as well as of hash comparisons) and thus may be slower if things no longer fit in the same cache level. Also, they may make the program less interactive. Hence, some tuning is needed, as well as consideration of different realistic speeds and salt counts (to ensure that the .rec file is updated frequently enough). With a GPU implementation, you will only have one thread on the CPU side (unless you try to use the CPU for computation as well, which is tricky), so you will probably not have a cpt parameter in your revision of the code. However, if you choose not to use a huge DES_BS_DEPTH value, you would instead need an array of a large number of structs similar to DES_bs_combined, and then you'd have some variable or constant corresponding to this array's size. It will have some similarity to cpt, as well as to DES_bs_nt. On CPU, we need both of these (and the latter has the former factored into it). When interfacing to GPU, you will only need one - and only if you choose to keep DES_BS_DEPTH low, which you don't have to. 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.