I'm not 100% sure what you are seeing/experiencing over there, but also remember that hashcat is highly parallelized and therefore all your OpenCL devices and all cores of just a single device (CPU/GPU) run different password candidates. That means that you can't really say that one word is run before the other, because the chuncks are run in parallel and start at different offsets. even if a word is at a higher line number than another word, doesn't mean that it is tested later... because a different core could run it because it's next in the queue within this particular chunk/split.
parallelization is often not so easy to grasp, I'm not sure if this is what you are seeing or just the dictstat generation etc, but it is for sure something very easy to understand if you somehow understand the architecture/inner working of hashcat.
I don't think it's a problem, but you could try to explain it in more detail and maybe we can find out what is going on. What are the times we are talking about here ? hours/days ? or just seconds (again it's difficult to compare with very small time frames)... and the second question is, are you sure it's not the init phase that makes the difference for you ? did you try testing with --runtime etc instead ?
BTW: also salts influence the speed by a lot. You should also always mention the hash type you are targeting. If you run hash lists with much fewer salts, it's of course much faster... Did you look at the Speed status prompt (H/s, kH/s or MH/s), is it almost the same between all the different commands you are trying ?
parallelization is often not so easy to grasp, I'm not sure if this is what you are seeing or just the dictstat generation etc, but it is for sure something very easy to understand if you somehow understand the architecture/inner working of hashcat.
I don't think it's a problem, but you could try to explain it in more detail and maybe we can find out what is going on. What are the times we are talking about here ? hours/days ? or just seconds (again it's difficult to compare with very small time frames)... and the second question is, are you sure it's not the init phase that makes the difference for you ? did you try testing with --runtime etc instead ?
BTW: also salts influence the speed by a lot. You should also always mention the hash type you are targeting. If you run hash lists with much fewer salts, it's of course much faster... Did you look at the Speed status prompt (H/s, kH/s or MH/s), is it almost the same between all the different commands you are trying ?