If you need it faster, then you can pre-compute a table which converts the random output to normals, and do linear interpolation to go the precise value. Much faster than doing square roots, cos and logs every time.
Precomputing tables of values when the program starts, and using interpolation, is also good for quick and dirty cos, sqrts etc when you know the input will be in some pre-defined range. Much faster than using your languages math library functions every time, and can be made as accurate as you want without sacrificing speed (but sacrificing memory instead).
Even better if you can trick your inputs to be ints. For example, i read that in Wolfenstein and Doom they don't use 360 degree circles or radian-based circles. They define a circle with 256 "degrees". Then any angle can be expressed in exactly 1 unsigned byte, you don't need any bounds-checking when rotating, since if it goes over 255 it wraps around naturally. And they just have arrays of 256 pre-computed sin and cos values directly stuck in the code, so they can use a direct index lookup instead instead of needing computation or maths functions. In any game that you can look around but doesn't need super accuracy, using 256-degree circles has some really nice benefits.
Or in places where memory access like that is expensive, you can reduce them down to approximations. For a system with MAD instructions (Multiply-ADd) (GPUs mostly) which can do a multiply followed by an add for the cost of just doing a multiply, you can approximate y = 1/4sin(x) with:
T = (x * Pi_Inverse) - 1.0;
y = (T * abs(T)) - T;
Where you're using the cost of 2 multiplies to replace a sin. Alternatively, if you can rework your equation such that you need sin to have a domain of 0 to 2 instead of 0 to 2PI, you can rework that to take out the first MAD and replace it with just a subtract. This replacement holds for a full cycle of sin, starting at 0, with maximum error of something like 13% IIRC.
(other stuff about MAD optimizing of shaders)
http://www.humus.name/Articles/Persson_LowLevelThinking.pdfEdit: Also, do what Thief says here:
Graknorke, what language are you using? If it's C++, the (new) C++11 random library has std::normal_distribution to do that kind of thing.
Incidentally, if you're still using rand() in C++ code, STOP. It's one of the worst random generators ever created. Do yourself a favour and learn the new C++ random library.
Assuming you're not doing GPU randomness (noise), use the random library for any sort of random numbers you plan to rely heavily on. rand() is good for prototyping and bashing crap out fast, but that's about it. Moreover, rand() is entirely non-deterministic cross-platform, so a procedural system would generate completely different results depending on who implemented the rand function (I have tested this; it is very different and doesn't even seem to have a consistent range to it).
Though, again, if you do GPU stuff, you've just walked into Mordor and we don't have none of those fancy elven libraries with their big memory footprints they live in or their delicate speech patterns here.