The purpose of a salt is not to make computing the hash slower, it's to prevent rainbow tables from being useful. A single iteration of SHA512 is way too fast to be useful against bruteforcing attacks.
On a decent GPU, you can do ~100M hashes/sec (new link) with SHA512. Multiply this for systems with multiple GPUs. With a slow KDF such as bcrypt, you can tweak the iteration count to be more suitable. You want something around ~0.3s/hash for a good security margin.
Keep in mind that 50 bytes is 400 bits, or a keyspace of 2^400. You're almost guaranteed to find a collision in SHA512 if you manage to compute 2^400 hashes. However, the attacker isn't trying to guess the salt. What you should be worried about is an attacker cracking the hashes when they already know the salt.
The solution is use PBKDF2, bcrypt, or scrypt, and store the salt in plaintext in the database.
It looks like you're trying to implement your own scheme. Please do not do this. There are two widely accepted rules of cryptography:
- Cryptography is hard.
- Don't roll your own.
I cannot stress strongly enough how dangerous it is to roll your own schemes, especially when dealing with crypto. Not even the legendary Bruce Schneier would dare write his own cryptosystem without serious peer review and months (if not years) of testing and tweaks.
The advice I've given you with regards to hashing is a standard based on peer review and a huge amount of theoretical and practical testing. Attempting to augment it using extra hashing and other black-magic is a bad idea, and will only increase the attack surface of your application and create a potential security flaw. Stick to the standard.