News for hackers. Stuff that matters.
Re:Some math about the Engineyard contest by sophacles on Friday July 17, 2009 @12:17PM (#710184)
So here is my general thinking on this contest, with an eye on computational efficiency:

1. SHA-1 is done in 64 byte chunks, with the result of one chunk being the base of the next. Padding and length only factor in at the last chunk. This means you can half the number of computations (or even 1/3 it...) by computing the first block of a "prefix string" then going from there.

2. Cuda is good on integer ops. SHA-1 is integer ops.

3. All the combinations of <= 5 printable chars can be represented in <60 MB meaning they don't have to keep being generated.

Not saying anything the article says was wrong per-say Im saying that large amounts of computation can be factored out from the naive approach, large enough to be meaningful that is.

Re:Some math about the Engineyard contest by antirez on Friday July 17, 2009 @03:03PM (#710525)
1) you are right, I and a lot of other guys are already doing this.

2) Indeed Cuda can be used with success, and this is probably the way to go. Unfortunately I don't have any board at hand, but I'll buy one later in order to experiment with this technology.

3) This is not going to save you any time. Basically the part that alters the five chars at the end is nothing compared to the rest of the computation.

There are other tricks that can be used, like to compute a fast hamming distance, just xor the bytes of the two strings and count the bits using a lookup table. Or even use some specific asm instruction for bit counting. But again unless you are doing this stuff of the xor in a very slow way this is a negligible amount of work: I commented out the hammer distance computation in my code and the numbers are exactly the smae, 3.5 million comparison per second per core more or less.

Another obvious optimization is of course to avoid doing too much permutations of the words. For every permutation there are a lot of tries to do just altering the final five chars.

Basically there is no way to win without to resort to fast hardware and parallelization, being it a large set of computers, CUDA, or a very lucky run that outputs in 30 hours an entry with an hamming distance of 31 or 32 just... against the probabilities ;)

The only reason I'm running the contest is that it's funny and a very good way to teach something interesting to the programmers working in my company. We care a lot about having fun programming.

Re:Some math about the Engineyard contest by profquail on Friday July 17, 2009 @01:28PM (#710323)
I've done some work with CUDA, so I'll just tell you ahead of time: it will probably be decently fast, but not nearly the kind of speeds you'd get from something like matrix multiplication. The problem is going to be that you need to fit the data to hash in "shared memory" (which is sort of like an L2 cache on the GPU). The standard shared memory size in CUDA is 16kb. Also, because of the way that data must be allocated in shared memory, you're not going to be able to get many string permutations into shared memory at once.

However, I think a good solution (if you're going to use CUDA, which I was thinking about doing as well) might be to load one permuation of words from the dictionary into the shared memory, and then have each thread compute one permuation of the various capitalizations for that string. This way you're mostly working out of the "cache" and that's about the best thing you can do on CUDA.

Re:Some math about the Engineyard contest by sophacles on Friday July 17, 2009 @01:37PM (#710342)
I thought that shared mem of 16kb was on a per core basis? It's very possible I misunderstood, in which case: crap! Either way the, the algorithm I have in mind looks pretty matrixy, if you want I can keep you updated as I test things out.
Re:Some math about the Engineyard contest by profquail on Friday July 17, 2009 @02:11PM (#710408)
It's 16kb per multiprocessor. I believe there are 16 cores per multiprocessor, and multiple threads are scheduled at one time in 'blocks'.

I actually started a thread in the CUDA general discussion forum, perhaps you could come by there and discuss it:

http://forums.nvidia.com/index.php?showtopic=102228

Re:Some math about the Engineyard contest by sophacles on Friday July 17, 2009 @12:22PM (#710193)
Actually, if anyone has a good cuda card and wants to team up on the code writing email me: [email protected]. We an use different random seeds when it comes time to running the stuff or whatever... I just think it would be fun!