When cycles are set to max (or more than what max can be) it can't go any faster, cycles need to be lower than max to do something. And since max depends on host cpu, so is turbo.
Also maybe I'm saying the obvious here but you know you need to keep alt+f12 pressed right? You don't just enable it with a keypress, it works for as long as keys are kept pressed.

I may have figured out what's going on. Here's a rough chart to explain:

The large columns are the amount of time available to render 1 frame on the host system. At 60fps this is 1000/60 or ~16.67ms, during which the emulated system is given some slice of that time to do its work, and then the screen grabbed for display.

Normally, when you have say 3000 cycles allotted, this emulation step happens in much less than 16.67ms, and so the host has some time to wait around because it's not time yet to put up the next frame. So, it inserts a delay here. This keeps the system from running too fast.

When you enable turbo mode, all that happens is that these delays are skipped. This causes the host to just do as many emulation steps as it can, in 3000-cycle increments, and show the frames as they come in. Which could be way faster than 60fps. (Also called "unlocked" mode, i.e. the emulator no longer attempts to "lock" to 60fps)

If you set cycles too high, the system cannot keep up - emulation step takes >16.67ms, and the display lags. You may need to frameskip to keep up. Turbo mode does nothing different here, because there are no delays to remove.

Setting cycles to MAX causes Dosbox to estimate how many cycles fit into the timeslot, and then dynamically adjust them to fit. On normal mode, this fills most of the available time. Turbo mode has a specific workaround to give each slice only 1/3 of the calculated max, which means the game can run at (up to) 3x speed.

Of course there is still work to be done by the emulated machine, and if 3000 cycles is not enough, it'll just bleed into the next block to do the work. You may not get any speedup at all. Extremely low cycles probably cause a lot of overhead switching into / out of the emulator function, so the system spends a lot of time thrashing and not getting anything done.

---

I believe that if a game requests an interrupt at VSYNC, and then puts the processor to sleep, this will cause DOSBox to set its remaining cycles to 0 immediately triggering the next frame. Newer games would do this, but a lot of older ones don't. I think there are some places this can be improved further through speedhacks - for example, if a game polls the VGA port 0x3da asking "are you in vsync yet" and the answer is no, DOSBox could also take away most of the remaining cycles, forcing emulation step to end much quicker and advancing to the next one. Also, I'm unsure if the system timer is independent of game speed, but it makes sense that it should be scaled up as well - games may spend a bunch of time waiting for this to tick over to time things.