en-us https://www.intensedebate.com/users/606025 Comments by MarkusQ http://www.engineyard.com/blog/2009/programming-contest-closed/#IDComment27933281 Tried to narrow the task from both ends (fixed 512 bit prefix block and most of tail block fixed, exploiting patterns, etc.) to reduce computation per test etc. then compile with gcc -O3, but realized too late that I shoulda CUDA. -- MarkusQ Wed, 22 Jul 2009 06:11:51 +0000 http://www.engineyard.com/blog/2009/programming-contest-closed/#IDComment27933281 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27531867 That was roughly my reasoning the other day (see my point in the middle of page 2), but I also applied a guesstimate of how much resources people will actually be willing to throw at it. People with 250 quad core servers generally have better things to do with them. -- MarkusQ Fri, 17 Jul 2009 16:52:51 +0000 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27531867 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27531443 That optimization doesn't _need_ to use exactly 69, but if it does (or if it uses 68) the final 512 bits are knowable in advance and the second pass reduces to a pure function f(u160,u40) or f(u160,u32). If we are allowed to use repeated words in the preamble this reduces to g(u16,u32) or so, which (if we had the NSA's resources, and yet still cared about this contest) would be a solution right there. I don't say this will make much difference here(in fact, I suspect it won't), but in a real world problem being able to factor the space like that can be a huge win. -- MarkusQ Fri, 17 Jul 2009 16:45:52 +0000 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27531443 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27484517 I think several people here have independently found the optimization you allude to (e.g. see Angus's blog). There are also at least two other possibilities (see the questions being asked) but at this moment I've only got the "69 character answer" hack working myself. Fri, 17 Jul 2009 02:36:32 +0000 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27484517 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27484282 Without algorithmic improvement each successive bit takes ~3.25 times as long, so to get two more bits (on average) you'll need an order of magnitude more resources. That means it's still got a large element of chance unless you do something tricky. Fri, 17 Jul 2009 02:32:02 +0000 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27484282 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27320645 My call four days before the contest: after doing some commute time mental math on it, I've concluded that I'll hit hamming distance 38±1 and the winner will be at 36±2. Anything <30 will amaze me. -- MarkusQ Wed, 15 Jul 2009 06:05:16 +0000 http://www.engineyard.com/blog/2009/programming-contest-win-iphone-3gs-2k-cloud-credit/#IDComment27320645