First of all, --force is not used to enable your CPU, but --force is used to run hashcat even if it detected some hard problems on your system.
-D 1 (or --opencl-device-types 1) instead needs to be used if you have GPUs and CPUs on your system (because hashcat defaults to using only your GPUs, because they are faster in general) and you want to enable all your CPU devices. Again, this only needs to be done if you have at least one graphics card on your system.
Whenever you use --force you will see this:
This means that you shouldn't report any problems but fix the (most likely always) driver installation instead.
I know we are toxic sometimes when it comes to people reporting bugs/problems and at the same time use --force, but it should be quite clear that the (mostly driver installation) problems need to be fixed first before reporting anything .... and even worse claming that with --force everything works (in your case you claim that you do not even need to use -D - which is correct but --force has in fact nothing to do with enabling CPUs - , but just can use --force, which is kind of missleading... because --force has nothing to do with your device type and device selection, but it just ignores some very serious problems/errors on your system).
Back to the "lag" problem. There is no such thing as (initialization) lag in hashcat.
When hashcat starts it needs to initialize a lot of things and most importantly the OpenCL devices are initialized and info is queried (this somtimes takes some time). There are other steps that hashcat does of course at startup, like checking the files, counting lines in the hash and word list etc... all of this sums up to a few milliseconds to seconds, but is probably negligible (because the driver initialization takes most of the time).
Of course this initialization step can't really be skipped and I would say (my opinion) there is little room for improvement (even if you optimize everything possible, it still would take about 20 seconds on your system @ startup).
Furthermore, you should always mention the hash type that you are trying to attack. There might be the possibility for much more clever attacks (like salted vs non-salted hashes etc).
In some cases it might also be better to use the stdin mode (by using a pipe) and generate the password candidates with an optimized password candidate generator that only produces very likely candidates. If this is efficient of course depends also on the hash type (if it is ntlm or bcrypt makes a lot of difference for instance).
I would also argue that 20 seconds shouldn't matter too much if you optimize your attack s.t. each job runs for several hours/days with very many hits (rule based attack etc ?). Therefore, the startup time of the next run is negligible again (a few seconds compared to a couple of days)... but this of course depends a lot on your use case (but in general very quick runs of just a few seconds are not really recommended, because it might also mean that hashcat has not enough keyspace to fully accererate)
-D 1 (or --opencl-device-types 1) instead needs to be used if you have GPUs and CPUs on your system (because hashcat defaults to using only your GPUs, because they are faster in general) and you want to enable all your CPU devices. Again, this only needs to be done if you have at least one graphics card on your system.
Whenever you use --force you will see this:
Code:
You can use --force to override this, but do not report related errors.This means that you shouldn't report any problems but fix the (most likely always) driver installation instead.
I know we are toxic sometimes when it comes to people reporting bugs/problems and at the same time use --force, but it should be quite clear that the (mostly driver installation) problems need to be fixed first before reporting anything .... and even worse claming that with --force everything works (in your case you claim that you do not even need to use -D - which is correct but --force has in fact nothing to do with enabling CPUs - , but just can use --force, which is kind of missleading... because --force has nothing to do with your device type and device selection, but it just ignores some very serious problems/errors on your system).
Back to the "lag" problem. There is no such thing as (initialization) lag in hashcat.
When hashcat starts it needs to initialize a lot of things and most importantly the OpenCL devices are initialized and info is queried (this somtimes takes some time). There are other steps that hashcat does of course at startup, like checking the files, counting lines in the hash and word list etc... all of this sums up to a few milliseconds to seconds, but is probably negligible (because the driver initialization takes most of the time).
Of course this initialization step can't really be skipped and I would say (my opinion) there is little room for improvement (even if you optimize everything possible, it still would take about 20 seconds on your system @ startup).
Furthermore, you should always mention the hash type that you are trying to attack. There might be the possibility for much more clever attacks (like salted vs non-salted hashes etc).
In some cases it might also be better to use the stdin mode (by using a pipe) and generate the password candidates with an optimized password candidate generator that only produces very likely candidates. If this is efficient of course depends also on the hash type (if it is ntlm or bcrypt makes a lot of difference for instance).
I would also argue that 20 seconds shouldn't matter too much if you optimize your attack s.t. each job runs for several hours/days with very many hits (rule based attack etc ?). Therefore, the startup time of the next run is negligible again (a few seconds compared to a couple of days)... but this of course depends a lot on your use case (but in general very quick runs of just a few seconds are not really recommended, because it might also mean that hashcat has not enough keyspace to fully accererate)