The point of strong password hashing functions is to make password processing slow so that attackers find it harder to run a brute force attack on your password. Unfortunately it makes it slower for you too; this is the limit of the exercise. At best, you make the function n times slower for you and n times slower (with the same n) for the attacker; but the attacker can buy some "specialized hardware" (e.g. GPU or FPGA) that, depending on the used function, may allow him to suffer less than you from all the iterations.
So what you want to avoid is a function that increases the computational task more for you than for the attacker. You use a plain general-purpose CPU, probably some sort of x86-compatible PC. The attacker can buy PC, but he can also buy some GPU or some FPGA that may deliver more computing power (i.e. more password tries per second) for the same budget.
Thus, you should avoid SHA-256 and RIPEMD-160, both of which relying on 32-bit integer operations that are remarkably efficient on GPU. SHA-512 would be a better bargain: your PC CPU is rather good at 64-bit operations (either in 64-bit mode, or through SSE2 opcodes in 32-bit mode), while a typical GPU is not. Using SHA-512 will make the task 2 or 3 times harder for the GPU-wielding attacker (he will still gain from using GPU, but not as much as witth SHA-256).
Whirlpool is normally implemented with lookup tables and will probably be quite slow on a GPU (but bitslice implementations should be explored). However, one may expect Whirlpool to map quite well to FPGA (just like AES), so if you fear advanced attackers who don't shy away from using FPGA, then don't use Whirlpool here.
To sum up, PBKDF2/SHA-512 can be said to be your best choice (arguably, it would be better if you could use bcrypt). However, remember that such differences tend to be dwarfed by what you can achieve with a stronger password. Using a high-entropy password is the first line of defence, and more important than the hashing function choice.
