This might be a little confusing but try to bear with me.
When you set cycles to a number it tells the emulator to emulate that many "virtual cycles" in one "virtual millisecond."
Each time a CPU instruction is emulated it consumes some number of cycles. I don't know the exact number. On a real CPU, some instructions will take more cycles than others, with the timing getting more complex with newer CPUs. My guess is that DOSBox uses a model simpler than what CPUs use, possibly as simple as every instruction taking exactly one cycle.
Virtual events like timers and video IRQs probably fire at cycle intervals that correspond correctly with their real world timings. So if a timer is set to go off in 100 milliseconds and you set cycles to 1000 it'll be scheduled to go off in 100,000 cycles.
After emulating N virtual milliseconds, that is, N * X cycles where X is the "cycle" number, DOSBox will synchronize with real time.
So let's say it synchronizes every 50 milliseconds. It will first emulate 50 virtual milliseconds, or if you set "cycles" to 1000, it'll emulate 50,000 cycles. Now let's say that it took 20 milliseconds of real time to emulate these. It will then stop and wait 30 milliseconds. This way, your virtual CPU which is supposed to take 50 milliseconds to execute 50,000 cycles will actually appear to be doing just that. For this reason, the higher you set the cycle count to, the faster a virtual CPU you'll be emulating.
But let's say that that emulating thos 50,000 cycles took 100ms to instead. In this case the best the emulator can do is start emulating more cycles immediately without waiting, possibly skipping frames or somehow reducing CPU pressure in some other way to try free up more time for emulating the CPU in the future. If it continues emulating the 50,000 cycles at 100ms between every synchronization point then the game will appear to run 1/2 as fast as it's supposed to.
One thing to realize is that no matter how DOSBox tries to correlate instructions with cycles there'll never be some fixed number that represents the maximum it can handle. That's because emulating some instructions will take a lot longer to emulate other instructions. Even if the emulator makes those more expensive instructions take more cycles it'll never scale correctly because what's expensive for an emulator and what's expensive for hardware are two very different things.
What I'm getting at is that one game might still run at full speed up to say, 4,000 cycles, but another game might only run fullspeed up to 3,000. Or it might vary even within the same game. It all depends on the software. It also depends on what sort of support hardware needs to be emulated and how heavily the software stresses these external things.
