For some reason I've found DOSBox to be particularly slow on compiled QB programs. I don't know what it is, but something just chokes them - maybe memory handling. On a machine that can run more typical games & demos in DOSBox at roughly the speed of a Pentium MMX or II, my QB4.5 executables seem to run like a 486SX. It's also really inconsistent and slows down more or less depending on which instructions are being used.

FWIW QB EXEs slow down pretty drastically on real DOS when EMM386 (or JEMM386/JEMMEX) is loaded, so I think it's something to do with memory management, but I haven't found exactly what..

EMM386 and JEMM switch the processor into VM86 mode, which is somewhat slower than real mode. Paging checks on memory access can impact performance for both real systems and DOSBox.

In DOSBox, certain instructions drop from dynamic (recompiled) core to execute on the normal core, which can reduce speed significantly if it happens often. Not sure about QB, but many forms of compiled BASIC, unlike other compiled programming languages, use interrupt handlers extensively, and the numerous INT instructions cause frequent drops to normal core. This degradation of speed could be mitigated if the BASIC compiler can be instructed to use far procedures instead of interrupts. Because INTs are smaller than CALLs, such a compiler option might be disguised as a "size versus speed" sort of thing.

I had forgotten about QB64! That could also be a viable solution.

ripsaw8080 wrote:

EMM386 and JEMM switch the processor into VM86 mode, which is somewhat slower than real mode. Paging checks on memory access can impact performance for both real systems and DOSBox.

In DOSBox, certain instructions drop from dynamic (recompiled) core to execute on the normal core, which can reduce speed significantly if it happens often. Not sure about QB, but many forms of compiled BASIC, unlike other compiled programming languages, use interrupt handlers extensively, and the numerous INT instructions cause frequent drops to normal core. This degradation of speed could be mitigated if the BASIC compiler can be instructed to use far procedures instead of interrupts. Because INTs are smaller than CALLs, such a compiler option might be disguised as a "size versus speed" sort of thing.

Interesting, thanks for the explanation. Seems plausible.

I don't know if QB has that low-level of compiler options though. Might look into this when i get some time. 😀

ripsaw8080 wrote:

... Not sure about QB, but many forms of compiled BASIC, unlike other compiled programming languages, use interrupt handlers extensively, and the numerous INT instructions cause frequent drops to normal core. This degradation of speed could be mitigated if the BASIC compiler can be instructed to use far procedures instead of interrupts. Because INTs are smaller than CALLs, such a compiler option might be disguised as a "size versus speed" sort of thing.

QuickBASIC v.3.00, "QB87", offers a "size versus speed" option for compilation. With my test program, choosing 'speed' speeds execution by just 15%. So that particular "speed versus size" option isn't disguising CALLs vs INTs, or INTs are not the source of much of DOSBox's slowness.

A fellow at planetsquires.com/protect/forum showed a nifty way to get a significantly speedier FreeBASIC compilation. You simply make the compiler options '-lang qb -gen gcc -Wc -Ofast' instead of '-lang qb'. Then FreeBASIC runs my test program 650× faster than the QuickBASIC in DOSBox does. He also showed a cumbersome way to make a somewhat speedier QB64 compilation. Then QB64 runs my test program 200× faster than the QuickBASIC in DOSBox does.

DC

Unfortunately, QB 3.0 generates executables that are rife with INT instructions regardless of its optimization choice. As much as MS compiled BASIC uses INTs, Borland Turbo BASIC takes it to another level, with executables that are an ocean of INTs.

Do I understand correctly that the QB87 executable is machine code plus some instructions to DOS? So the executable is specialized to a class of CPUs and to DOS. The QB87 executable, despite its abundance of INT instructions, runs decently fast in NTVDM -- about 80× faster than it does in DOSBox. Do we have an explanation for this great difference?

First, and most importantly, DOSBox executes program instructions in an emulation of a CPU; it does not execute the instructions natively on the host CPU as NTVDM does. This has already been mentioned, but perhaps it was not clear enough. Second, due to the extensive use of INT instructions, compiled BASIC is relatively slower compared to the speed that is possible with the dynamic core in DOSBox.

DOSBox is not a replacement for the NTVDM. DOSBox is intended for playing DOS games, which it does more compatibly, if not faster, than the NTVDM.