pdfcrack

Hi Marek,

I know, the missing multithreading is the number one requested feature but unfortunately noone has stepped up to do it, and I simply lack motivation and time at the moment.

The difference between OS X and Windows is quite interesting, but I need a bit more details to actually find out what it could be.

First a few things you should know about pdfcrack:

1. The reported words/sec when working is the actual work performed. This means that if something grabs CPU time from pdfcrack (for example other processes running) it will report a lower value.
2. pdfcrack use extremely little memory as no data structures are larger than at most a few hundred bytes. The whole program will probably fit within L1 cache of your machines so it is entirely CPU dependant and memory is not a bottleneck (hence, throwing more memory on it would not help).
3. pdfcrack is by default compiled without optimization for a specific platform so the default compiler values are what is used.

This leads me to ask you to try:

pdfcrack --bench

on both machines to see how many words /sec it crunches away if we only calculate based on the time it has been running, instead of clock time. This would remove most factors about how much other processes are stealing time from it.

Another thing to look into, if the numbers persist, is if the two binaries are compiled with the same version of gcc and if they have the same compile flags in the Makefile.

My assumption here, if the numbers are different with "pdfcrack --bench", is that the compilers are different and/or the compiler have better optimizations under one platform than the other. This is at least as long as the numbers are not similar (I am not sure what the margin of error here is, you might want to try the --bench a few times to see how much the values fluctuate).

To speed things up you should try to experiment with flags for your architecture and add them to the Makefile and recompile.
It might help and it might get worse but it should be possible to cram out a bit more speed without going into the dirty business of adding hand optimized assembler for the hard working parts of the program.

Sincerely
Henning