title: GPU Brute-Force Implementation
body: <p>I am asking for an advise for the following problem:</p>
  
  <p>For a research-project I am writing a brute-force algorithm based on a GPU with (py)OpenCl. </p>
  
  <p>(I know JTR is out there)</p>
  
  <p>Right now I do have a Brute-Force-Generator in Python which is filling up for each round the buffer with words (amount=1024*64).I pass the buffer to the GPU Kernel. The GPU is calculating for each value in the buffer a MD5 Hash Value and compares it with a given one. Great that it works!</p>
  
  <p>BUT:</p>
  
  <p>I don't think this is really the full performance i can get from the GPU - or is it? Isn't there a bottleneck when i have to fill up the buffer by the CPU and pass it to the GPU 'just' for a Hash calculation an comparison - or am i wrong and this is already the fastet or almost the fastet performance i can get?</p>
  
  <p>I have done a lot of Research before I consider to ask this question here. I couldn't find a brute force implementation on the GPU kernel so far - why?</p>
  
  <p>Thx </p>
  
  <p>EDIT 1:</p>
  
  <p>I try to explain it in a different way what I want to know. Lets say I have an average computer. Performing an brute-force-algorithm on a GPU is faster than on a CPU (if you do it right). I have looked through some GPU brute-force tools and couldn't find one with the whole brute-force implementation on the GPU Kernel. </p>
  
  <p>Right now I am passing "word packages" to the GPU and let them do the work (hash &amp; compare) there - looks like this is the common way . Isn't it faster to 'split' the brute-force algorithm so each Unit on the GPU will generate its own "word packages" by itself. </p>
  
  <p>All I do is wondering why the common way is to pass packages with values from the CPU to the GPU instead of doing the CPU work also on the GPU work! Is it because it is not possible to split a brute-force algorithm on a GPU or isn't the improvement worth the effort to port it to the GPU?</p>