It is possible to design a PRNG upon a hash function, but it requires some care, notably because existing hash functions are not random oracles (being collision-resistant and preimage-resistant is not all that can be dreamed of for a hash function).
NIST Special Publication SP 800-90 describes some PRNG designs which are "Approved" (in the bureaucratic sense) for cryptographic purposes.
HMAC_DRBG are based upon a hash function (within HMAC for the latter). If you use a hash function with an output of n bits, then
Hash_DRBG will require, asymptotically, one hash function invocation (over a small input) per n bits of produced alea (for
HMAC_DRBG, this will be two such invocations). This means that on a basic PC, using SHA-256, you will be able to produce, say, about 60 to 70 megabytes of alea per second, using a single core; I am talking about an Intel x86 Core2, with no fancy programming -- one should be able to double that bandwidth with SSE2 instructions (for
HMAC_DRBG, divide performance by 2). Depending on your application, this speed can be total overkill, grossly inefficient, or anything in between.
Hash functions are (usually) very good at processing much input data, for which they yield a small output. This is exactly the opposite of what we want for a fast PRNG, which is why performance of a hash-based PRNG may be somewhat low. Some hash functions are designed on a "reversible" core which can accept input data and produce output very efficiently; these are designs which can be used as hash functions or stream ciphers. PANAMA is such a function (very fast, even faster than MD4 as a hash function; unfortunately, it turned out to be very broken too). A more recent reversible design is Skein, a candidate for SHA-3; other hash function designs are amenable to conversion to a stream cipher (e.g. all so-called Sponge functions). Caution should be exercised: hash functions and stream ciphers are not analyzed with the same techniques or goals; that a reversible function looks secure as a hash function does not mean that the corresponding stream cipher is secure, or vice versa. In particular, the SHA-3 process tells very little about use of Skein as anything else than a hash function.
For faster cryptographically secure PRNG, look up stream ciphers, in particular those selected by the eSTREAM project. A good, secure stream cipher should be able to output, say, 750 MB/s worth of alea on a basic PC (that's what I do on my 2.4 GHz Core2, there again with a single core, using SOSEMANUK).
Non-cryptographic RNG can be devilishly fast (more than 1 GB/s), albeit they do so by having detectable biases which may or may not be an issue for any given application. A sure sign of a PRNG not being cryptographically secure is any assertion about how large the "period" is. For cryptography, the period is mostly irrelevant (anything beyond 2128 is good enough); a long period says almost nothing about security.
On a recent enough x86 processor, forget all of the above: the AES-NI instructions should be used to implement an AES-based PRNG (like
CTR_DRBG in NIST SP 800-90) which will provide excellent alea (fit for any purpose, including cryptography) at 2 GB/s or so.