4 ms·

Not an apples-to-apples comparison. The Python version is fully general, using Random() to create probes (as many as needed). Instead use the optimized, 4Kb f

Not an apples-to-apples comparison. The Python version is fully general, using Random() to create probes (as many as needed). Instead use the optimized, 4Kb fixed size version shown later in the recipe. Also, improve your timing by making the loop in a function and using something other than range(1000000) to fill-up memory (like timeit does). The C version should also use sha224 for comparability (otherwise, you're basically comparing two different hash functions in two different languages meaning that some of the difference can be ascribed to the choice of hash algorithm). That being said, you've done a great job showing that it doesn't take long to correctly implement this algorithm in C. That is a nice win.

haberman 15y ago
> Not an apples-to-apples comparison. These kinds of arguments make sense if you're 20% different, or 2x different, or even 10x different. When you're 1000x different, no amount of minor tweaking is going to bridge the gap. Using the 4k version and using timeit() instead of range(), the speed is 21 seconds instead of 32 seconds, so it did speed up, but it's still 800x slower. I'm pretty sure that only a tiny fraction of Python's time is calculating sha224, so I don't think that making them use the same hash function is necessary. Look, Python is cool and has it's place. But it's annoying to get downvoted for stating the obvious: algorithms like this will be much, much faster in C. It's annoying to hear people insist that dropping to C is a waste of time when my personal experience shows time and time again that it can lead to drastic improvements.