>>1
Why do you malloc a string of constant length?
Name:
Anonymous2012-07-09 18:33
malloc(3 * sizeof(char)); printf("mango");
Name:
Anonymous2012-07-09 19:25
This fails with tripcodes that contain one of the characters &, <, > or ". It also fails for typical UTF-8 input since you don't translate to SJIS.
ver2 will be a threaded trip code explorer
It's an embarrassingly parallel task so you could just add a fork call in there and now you're utilizing all the cores.
ver3 will be a CUDA trip code explorer
On current hardware this is not feasible due to lack of registers, try searching "crypt on cuda" or "des on cuda", results have been abysmal with typical speedup of just 2 over a single cpu core.
Name:
Anonymous2012-07-09 19:40
On current hardware this is not feasible due to lack of registers
>>4 >>5
Salt was originally a dynamically allocated string because I thought the length of salt depended on the length of the input. When I realised this wasn't so I just modified the malloc statement. Lazy of me.
>printf("mango");
That's just some stupid debug code.
>>6
I'm aware of the special character and UTF-8 encoding shortcomings. Any ideas about how to use UTF-8 in C and converting SJIS?
>>7 Not on a SPARC bitch
Do you even know what CUDA is?
Name:
Anonymous2012-07-10 3:59
>>13 Any ideas about how to use UTF-8 in C and converting SJIS?
Use iconv.
>>16 Why the openmp doesn't work on GPUs?
Check out mint, it translates annotated C (like openmp) to CUDA. Seems to work well enough on stencil methods at least, I don't know if it has been used on other stuff.
Name:
Anonymous2012-07-10 4:19
>>16
But just accelerating that outer loop on the GPU wouldn't work (at least not efficiently) in this case, you have to implement some kind of bitslice scheme but as stated earlier the current hardware simply doesn't have enough registers/fast enough shared memory for this to efficient.
Name:
Anonymous2012-07-10 4:57
>>15
OP here. Thanks for posting that. It has given me a few ideas on how to implement a few missing features.
I'm not a fan of using programming idioms. It makes the code too dense, though this might be because I'm not an expert.
Name:
Ordinary Western Wizard !ZmaRIsaGOY2012-07-12 11:28
http://pastebin.com/mEqCcaLx
Why is this so slow? It barely checks over 1 millions of tripcodes per second on my AMD64 i5 2500 system running glibc 2.15 and Linux 3.3.7. Could I get a huge speedup by using a specialised crypt function?
Name:
Anonymous2012-07-12 11:37
>>28
You are using a specialized crypt function. If you mean using the kernel's crypto stuff, that won't give you jack schitt. Seeing as how tripcodes used DES, I bet someone with an EE background could make a deep cracker.
Name:
Anonymous2012-07-12 11:58
>>29
This may surprise you, but !MILKRIBS4k was actually the director of the EFF.
>>32-34
Profiling won't tell you much in this case, of course the bottleneck is going to be the crypt, he could profile the shit out of DES_fcrypt but the algorithm itself is fundamentally broken. Even if he changes to a modern algorithm it will still be the bottleneck.