If what you're trying to compare are the two scenarios:
- Server uses regular hash with salt, and attacker obtains both
- Server uses truncated hash with salt, and attacker obtains both
Then obviously the attacker has an easier job in Scenario #2 because for a truncated hash computed via the same algorithm, he will find a collision faster (If those are different algorithms, the output hash being shorter doesn't necessarily imply that the hash is faster to compute).
Remember that the attacker doesn't have to guess the correct password, he only needs to calculate a password that matches whatever hash value the server stores. I'm making the reasonable assumption that the server stores only the hash, not the password itself, otherwise storing a hash is rather pointless (at least as far as security goes).
Now, if an attacker only has access to the truncated hash but not the salt, then obviously it makes a big difference exactly how you perform the truncation. The "modulo 1000" example you gave for example will yield any hash trivially breakable, because the hash value will be in the range $0-999$ which is an exceedingly small search space. Of course, here he doesn't know the salt value, so he has no way to precompute possible hashes on his own, yet this is still an extremely insecure way to compute a hash, because of the ease of performing an exhaustive search attack directly on the server. However, if it is a reasonable hash function truncated to a reasonable size, for example:
truncate(sha512(password||salt), 256) then probably the attacker isn't much better off without access to the salt value.
In general, I don't see any security benefit in truncating a hash for this specific use case. There are interesting security-related use cases where truncating a hash can be useful: if you want to create some kind of data equivocation, e.g. make it difficult for an adversary to ascertain that a hash value belongs to a certain object and not another.
But again, since when talking about password hashes, the correctness of the password sent to the server in general doesn't matter, but only it (in combination with the salt, if used) having a matching hash value, I don't see how that can have any security benefit.