Protected mode speed

[sparhawk]

A few years ago I wrote a program where I needed all the speed I could muster. For this reason I coded it in assembly, and optmized it heavily, so that I could get the best possible performance. I was running this program in Windows 98 at that time, and I figured that windows adds a certain overhead even when letting it run without any interference. So I used a protected mode wrapper and tried to run it straight from DOS, switching to protected mode and dong my thing.

The surprising result was that letting it run in Windows with it's overhead, was faster then letting it run on a plain DOS machine (which means no overhead at all) while running in protected mode. If I remember correctly, running it under Windows it was almost two times faster.

The program had a minimum of output, because I didn't want it to distract from the actual task, so I printed on the console every few seconds a status line, but nothing else. Only when it found the data it was designed to find, was a record written to the disc. This happened on average every ten days, so this can certainly not account for why it was much slower. Printing the status line was being done using calls from protected mode to real mode DOS, because I didn't want to implement my own screen drivers just for that, so this was the only thing that might have actually slowed it down, but that was done every few seconds, so I still don't understand it.

The reason why it had to be so imptomized was because the code was doing some heavy computational stuff, and each clock cycle that I saved resulted in an average decrease of total runtime of about 2-3 days. So it was well worth the effort to do this as the total runtime was, on average, about 30 days.

Any ideas what could have caused such a difference?

[Draakie]

The program had a minimum of output, because I didn't want it to distract from the actual task, so I printed on the console every few seconds a status line, but nothing else. Only when it found the data it was designed to find, was a record written to the disc. This happened on average every ten days, so this can certainly not account for why it was much slower. Printing the status line was being done using calls from protected mode to real mode DOS, because I didn't want to implement my own screen drivers just for that, so this was the only thing that might have actually slowed it down, but that was done every few seconds, so I still don't understand it.

Any ideas what could have caused such a difference?

Seesh that was an easy one - you answered your'e own question so elequently. Remember Windows is allways in
protected mode anyway (protected mode hardware drivers for display / disk management etc.). Any calls in and out
of protected mode to REAL MODE interupts would cause lag - In windows those interupts are remapped to their
protected mode counterparts ==> thus sppeeeeeeedd !

[sparhawk]

That was what I also assumed, but I find it strange, that a print, that occurs only every N (N > 1) seconds can slow down a process so drastically.

[Draakie]

Just a Theory (might be a crackpot one)

It might be dependant on what Interupt requests you were using and other factors
RE:
Real mode INT 21 remaps to HARDWARE level INT's\IRQ's with Port IN's and OUT's
Real mode memory model limitations and alignment issues
Gate A20 Lag with discriptor table Load \ unloads -> effectively getting in and out of protected mode takes up cycles.

[ecube]

wow that was an interesting read, thanks for that. Some of the best asm optimization pro's alive are apart of this board so sure some can help you further.

[MichaelW]

How were you calling real-mode interrupts from protected mode, and what were you using for a timer? Perhaps the major part of the slow down was the DOS extender, or what ever you were using.