One important difference between your construction and PBKDF2 is that PBKDF2 uses a pseudo-random function (prf), typically HMAC, instead of a hash directly. SHA1 and SHA2 are not prfs, and so certain security proofs don't apply to them.
One theoretical problem with your construction is that you can hit internal collisions or short chains. Because your salt and password stays in each iteration, if you ever produce the same hash twice as you go through, then you will end up in a cycle of hashes. (PBKDF2 suffers from a variant of this as well, but it does illustrate the kind of thing to look out for.)
So you would do better with your loop looking like
hash = hmac-sha512(i + salt + password, hash)
but for all of the reasons that others have pointed out, you are still better off using PBKDF2, warts and all, instead of rolling your own.
scrypt is superior to PBKDF2 for almost all situations. But it is harder to learn to use correctly. PBKDF2 is superior to bcrypt.
It also should be noted that PBKDF2 was designed for key derivation, not for password hashing. So it has some features and characteristics that aren't really what you need. (And it has a bug in that component that only matters for key derivation, and only is very unusual circumstances).
As much as I'm criticizing PBKDF2, I still think it is better to use it than to roll your own. The particular problems with it are not something that you will run into with password hashing.
A successor to PBKDF2/scrypt/bcrypt
You may wish to follow the developments of the Password Hashing Competition. This is an attempt to find a suitable successor to PBKDF2, scrypt, bcrypt for password hashing. But for the moment, just use scrypt if available to you or PBKDF2.