How did you arrive at $2^{10} \cdot 2^{50} \cdot 2^{10}$? Presumably, it's meant to represent something like:
For each user u
For each password p
Compute PBKDF2(p) and compare with u.hashed_password
Which gives $2^{10} \cdot 2^{50}$ invocations of PBKDF, each of which is $2^{10}$ hash function calls. But consider this approach:
For each password p
For each user u
Compute PBKDF2(p) and compare with u.hashed_password
Notice that it's not necessary to calculate the PBKDF inside the loop, and instead you can do this:
For each password p
Compute h = PBKDF2(p)
For each user u
compare h with u.hashed_password
This gives a total of just $2^{10} \cdot 2^{50}$ calls to the hash function. So in fact, the number of users does not impact the number of hash invocations required. Preventing this optimization is exactly the purpose of a salt. It means that there is an input to the PBKDF that depends on a property of the user, so that the hash calculation can not be hoisted out of the inner loop.