Well, you can lower the cycles setting to make it run more realtime(less cycles = more realtime).
But that will come at the cost of running software of course slowing down, as the amount of instructions each second (in emulated time, not realtime) becomes less.
The main issue is that according to most profiling I did on Windows builds, it's spending most time on memory accesses alone (RAM and ROM memory). I'm trying hard to optimize it to get faster, but it's proven difficult because no dynarec of any sorts is implemented (it's about ~20% CPU emulation(of which about only memory accesses itself being the main cuprit for that), ~20% video card emulation and 60% of only the other hardware and timing overhead).
It's running better on Android (5%) and i7-4790K Windows (~20%), but I have no idea what to change atm to make it more fast right now. Most memory accesses are already reduced to single 16/32-bit accesses where possible, but most of it seems to be prefetching only (filling up the Prefetch Input Queue to contain the maximum instruction length each instruction). Although said overhead is less on cycle-accurate mode(due to not loading unneeded bytes from memory most of the time), it has it's own optimization difficulties (due to ticking hardware and CPU multiple times during a instruction (the amount of CPU cycles for an instruction)).
Disabling some of the emulated hardware should theoretically free up some speed for the CPU to run faster(if it's enough), but the CPU is mostly ticking way more than the hardware anyways(all but VGA and CPU always ticking at 14.31818MHz base intervals, with the VGA depending on it's state(25/28MHz on VGA, 14.31818MHz on CGA, EGA, MDA clock crystals, even higher on SVGA when setup(up to Dosbox's ratings of the Tseng chips)) and CPU acting as the base timing for all hardware (divided it up into video card and 14MHz(1MHz for Sound Blaster, ticking at 14MHz base clock division) depending on it's speed setting(the IPS cycle setting).