$ time ./md5 e80b5017098950fc58aad83c8c14978e 6 6 1
initializing..
h/s:3862242.086957
(1) I found a collision!
message:abcdef
g_thread_active_cnt:0
real 0m23.590s
user 0m23.108s
sys 0m0.015s
multi-threaded test outcome:
$ time ./md5 e80b5017098950fc58aad83c8c14978e 6 6 2
initializing..
digest_target is 17500be8fc5089093cd8aa588e97148c
g_thread_active_cnt:1
h/s:1610514.000000
(2) I found a collision!
message:abcdef
g_thread_active_cnt:0
finished sniffing and found some other problems in my code and updated it and voila roughly 25% faster. O what a decent night of sleep can do. I became a father for the 2nd time on the 29th of may, which is my birthday also, and finally i can sleep for 5 consecutive hours again. Me is happy.
removed yet another memcpy as it was not needed anymore due to the loop unroll and intergrated two loops into one. further more the test i moved to md5hash as you did. It seemed to help a few percent.
basically it works like this now pseudo code ofcourse:
the code was in the previous post. currently i'm building a multithread solution to see if i can improve further by is seems to be stuck near 5.2 Million hashes per second. needs more investigation.
looked into that but the answer is no. look at the hash function you'll see that A, B, C, D is used in every line. As for the GUI that hardly cost many time if handled correctly. i'll not be able to work on it today/tonight so'll look into it again tomorrow. Though we have come along way since 300 K hashes/sec.
I've just added your corrections to my build and I'm getting ~2.43M h/s and on my box cain runs at ~3.31M h/s so sadly we haven even beat cain yet
I did: (downloaded the code in the last post) g++ brute.cc -lm -lpthread -O3 -march=i686 -o brute && time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
2.972 million hashes per second
I know you are telling the truth about being in the 4 million range simply because my very own gets 4.3 million, but if someone else runs it the total drops to some pitiful amount..
The question I am wondering is exactly how do we end up perfecting the algorithm just for our processors? Ok. You might say we kept changing and running until we got it right.. but I did not. I changed what I wanted to change and it worked and got a increase in hashes per second.
Let me get my other computer booted (AMD), and see if I get drastically different results.
hmm.. i also think mine works best on my box, per GHz, , also I've found that the MMX regs are 64bit and every CPU supports it, could we use those somehow?
g++ cocaine.c -lm -lpthread -O3 -march=i686 -o cocaine && time ./cocaine 5b9104dc42e2f8fdd3f6a801f7656d65 5
2.918634 million hashes per second
My Laptop (Only computer doing any testing ever.) processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.40GHz
stepping : 8
cpu MHz : 1400.000
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx up
bogomips : 2795.45
clflush size : 64
also I've found that the MMX regs are 64bit and every CPU supports it, could we use those somehow?
Yes. The MMX extension allows you to perform operations on two thirty-two bit values. It is not hard to do this by using the intrinsic functions provided by C/C++. I have used MMX this way before.
candy@blackbox:~/brute$ time ./brute 5b9104dc42e2f8fdd3f6a801f7656d65 5
Collision Found!
hash[5b9104dc42e2f8fdd3f6a801f7656d65] = 'glich'
- time: 0.59s
- avg. hash/s: 5490989.83 h/s
real 0m0.592s
user 0m0.591s
sys 0m0.001s
candy@blackbox:~/brute$
Is that faster?
No it isn't.
Removing what I thought might be good and adding -march=i686 (on a p4) ups this to 5.5 million. Adding -fomit-frame-pointer ups that to 5.7 million. This is still on a single core.
What if you generate the strings beforehand or separately?
Last edited by Candy on Thu Jul 05, 2007 2:55 pm, edited 1 time in total.