Edit. I just realized tio.run is running raku from 2018 which is a LOT slower than current raku, whereas it's running a more recent python. I could well believe

Edit. I just realized tio.run is running raku from 2018 which is a LOT slower than current raku, whereas it's running a more recent python. I could well believe the sequential raku numbers are much closer to the python numbers and the parallel could perhaps be an order of magnitude faster. Fwiw, I ran the above on tio.run. It took 0.9s. I also ran the perl code in the OP in the section headed "Using an Array Instead of a Hash". That took about twice as long. The changes in the section headed "Further Optimizations" supposedly deliver about a 30% improvement. So, closer to your Python code -- but still noticeably slower. The changes in the section headed "Combining Caching and Parallel Execution" then sped things up a further 15x on 32 cores -- more than an order of magnitude faster. (I presume it would be fairly easy to parallelize the python code too and it might be equally efficiently implemented, but the proof, as they say, is in the pudding...) In the meantime the sequential raku code is way off, something like 5X as slow as the perl code I tested on tio.run, so 10x slower than the python code you wrote. Then again Liz made some mods to the raku code that she says doubled its speed.[1] And it's typically relatively easy to parallelize raku code, so presumably the raku code could relatively easily be made to outperform your python code on hardware with enough cores -- at a guess around 10 or so. [1] https://www.reddit.com/r/rakulang/comments/g2au9v/revisiting_the_collatz_sequence_laurent_rosenfeld/ https://www.reddit.com/r/rakulang/comments/g2au9v/revisiting...