on my 4-core MBP (2.6ghz ivy bridge) i can manage ~1.8 billion hashes per second.
i could parallelize with OpenCL, but i think this is enough. after a few minutes, i get ARbyhlf as a valid name (although i don't know if this is actually valid.. but it definitely might be)
Most of the time is spent on generating the random string, which was because I very quickly realised looking through the entire possibility space in order would be unproductive. Granted, my entire approach was unproductive, as shown by linuxbochs, pedrox, and others below :)
I actually did some micro-benchmarking in the midst of all that and found that hashing a single, static, string took something of the order of 20ns. That's half a billion hashes per second, or 2 billion on four cores. Add a little overhead for string generation, and yeah, we get the same number.
Most of the time is spent on generating the random string
when i took out string generation, i went from 1.2 GH/s to 1.8GH/s (although, i'm assuming my string generation was much simpler)
I very quickly realised looking through the entire possibility space in order would be unproductive
you say that, but it's not as unproductive as you might think. assuming the hash function is uniformly distributed (hah), there are 4 billion hash values that could result from a string. if we can check 2 billion a second, we should see a result every few seconds. maybe my search space pruning was particularly bad, because i see on average ~4-10 a minute, and they are usually quite clustered together. this suggests the hash is not uniformly distributed (although a cursory glance at the function should make it obvious to people with a maths background).
anyways, it was good fun to poke around :) cheers for sharing!
Comments
i was intrigued by this, so i done it in C.
on my 4-core MBP (2.6ghz ivy bridge) i can manage ~1.8 billion hashes per second.
i could parallelize with OpenCL, but i think this is enough. after a few minutes, i get ARbyhlf as a valid name (although i don't know if this is actually valid.. but it definitely might be)
(removed)
edit: just realised that my nonce calculation was wrong.. http://pastebin.com/bcHcECPJ
Most of the time is spent on generating the random string, which was because I very quickly realised looking through the entire possibility space in order would be unproductive. Granted, my entire approach was unproductive, as shown by linuxbochs, pedrox, and others below :)
I actually did some micro-benchmarking in the midst of all that and found that hashing a single, static, string took something of the order of 20ns. That's half a billion hashes per second, or 2 billion on four cores. Add a little overhead for string generation, and yeah, we get the same number.
when i took out string generation, i went from 1.2 GH/s to 1.8GH/s (although, i'm assuming my string generation was much simpler)
you say that, but it's not as unproductive as you might think. assuming the hash function is uniformly distributed (hah), there are 4 billion hash values that could result from a string. if we can check 2 billion a second, we should see a result every few seconds. maybe my search space pruning was particularly bad, because i see on average ~4-10 a minute, and they are usually quite clustered together. this suggests the hash is not uniformly distributed (although a cursory glance at the function should make it obvious to people with a maths background).
anyways, it was good fun to poke around :) cheers for sharing!