Which, for example, is why something based on SHA3 is bad, because your typical server is just going to be doing SHA3 hashes via CPU. Except SHA3 was chosen to be ASIC-friendly, so your attacker will be able to calculate SHA3 faster than you. As long as the attacker has no faster calculation method than the one you're using, the absolute speed doesn't matter. This is why scrypt, bcrypt (and to a lesser extent pbkdf2-hmac-sha256) are doing well, because running them on GPU or ASIC isn't meaningfully faster than the CPU implementation the defender is using.
All that's left at that point is making it as expensive as possible for them to parallelize their attack. Which is what scrypt and other things attempt to do -- require as many non-CPU resources (memory, hd space, etc) so that the attacker's parallelization cost is also maximized.
(Personally, I've been playing around with the idea of incorporating random accesses to a 2-tb file of random data, so that the attacker would have a HUGE amount of data to steal before my hashes would work. And they'd have to establish shared access to all the CPUs/etc they're attacking with)