If you don't use any delay function you have to deal with this problem. The cpu or gpu tries to do the things as fast as possible so your program runs in different speeds depends on cpu's clock frequency or pc's performance but if you use a delay function (such as Sleep(ms)) on main function (for non-graphic operations) you'll define the limits.
Extra info: Human eyes can see about 24 frames in a second. That can be a reference 40miliseconds as usual.
Actually the human eye is capable of seeing substantially more than 24 frames per second and in some cases is substantially slower to process the information . In passive perception, like when watching TV or a movie, you are very unlikely to notice a lack of motion, even well below the start 23.9frames provided by NTSC ( or 29.8ish for PAL people ).
However, the inverse is not true when it is an active experience. IF you are using a PC and expecting to see a certain amount of movement, the lack of that movement is easily perceptible, even if sampling at well over 24fps. This is why the mouse cursor operates on a hardware cursor independent to everything else. If your mouse visibly updated at 24 fps, unless moving slowly or stationary, it would drive most people bonkers.
As to the topic at hand, "sleeping" is generally a bad idea, unless yielding back to the OS in some form. Generally best practice for a situation like this is to seperate your render loop from your update thread and run as fast as possible. If no bottlenecks are encounter, simply smooth your animation out be applying the elapsed time against the amount of animation, this way things will run at the same speed on different class of machines. It's when your machines aren't capable of hitting a minimum performance level that things get tricky...
