Date: Sun, 9 Dec 2012 05:23:26 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: bitslice DES on GPU On Thu, Dec 06, 2012 at 11:32:41PM +0200, Milen Rangelov wrote: > Why do you want to patch your kernels? Primarily to reduce the register pressure, but also likely reduce the number of instructions. Like I mentioned, on CPU this makes for a 7% speed difference (not currently implemented in JtR, I did not care enough - although I did measure this). On GPU, according to a test Sayantan ran (hard-coding the values for a specific salt), "performance increased from 67M to 110M" - and this speedup matches my expectation. > I used to patch the kernel binaries for BFI (before AMD mapped it to [...] > that we have the ELF-inside-ELF situation. Once I understood that, I was > finally able to find out where the binary code starts so that I could > reliably patch the opcode. Thank you for describing this! I think you could do it differently (maybe simpler): build two variations of the kernel, either with different suitable placeholder instructions in place of BFI or with different operands. Then diff the two to find just the right places. No need to parse ELF headers, then. > Note that this is a rather simple case, for more advanced binary patching, > this would become much more complex. Right. > I've seen in the AMD forums some > people posting stuff about IL patching inside kernel. I don't really know > how that works. Perhaps they compile from source, patch the IL section > inside binary, strip the text section, then again pass that to > clBuildProgram to get the final binary, but I am not quite sure about this. We actually prefer to patch at ISA level, I think - so it'd be more similar to what you were doing - except that we need to patch immediate offset fields rather than opcodes. 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.