Mail Archives: djgpp/1994/04/01/17:36:18
> In order to get a rough estimate of the delays accumulated by
> switching between real/protected mode (and the eventual
> inefficiencies of the os) it would be interesting to see mesurements
> taken on the same hardware once under djgpp and once under LINUX or
> any other 32bit os with gcc available.
Well, let's see why this this comparison would be meaningless (I am
writing this on a Linux system :):
0. I'm mostly going to talk about disk i/o, since that is where the
majority of DOS calls get made, and (I'm speculating) that's where the
most likely bottleneck is.
1. DOS is single tasking, Linux is multitasking. So any Linux
measurements would of course be biased by the system load.
2. DOS does synchronous i/o (wait for completion), whereas Linux does
async i/o, where a process blocks until completion. If another process
is running at a higher priority, the Linux process might not come back
immediately upon the i/o finishing.
3. DJ has to use the DOS file system for paging. Linux supports VM in
the kernel. Linux wins big here.
4. It's pretty predictable how DJGPP will page, based on available
RAM. Linux will page based on total system needs.
5. Finally, Linux has a gigantic buffer cache (typically around 4-5Meg
on a 16Meg machine) so disk i/o may not go to the disk; disk i/o on
DOS always goes to the disk, and swapping to a RAM disk is stupid. This
combined with (3) and (4) make it really useless to look at the time
disk i/o takes.
Other 32-bit OSs with gcc (only other Unix flavors, and OS/2 come to mind)
also have most or all of the above mentioned characteristics.
If you wanted to really measure real v. prot. mode, what you would
have to do is code up (at the very least) an ms/dos filesystem that
could be part of the C library. Basically, you need a protected mode
filesystem and bios emulator. At this point, you are starting to write
an OS (albeit a primitive one).
And another point: mode switching isn't the only bottleneck. Consider
that all disk i/o requests have to be copied between lower and upper
memory and done in small blocks (4096 I think it is, with the current
go32). Memcpy is a very expensive call on most systems, and doing i/o
in small chunks is also very expensive.
Summary: There are many variables in play, and to eliminate it to even
a manageable few would be a daunting task.
FWIW It might be interesting to see what happened if all the
filesystem code were in libc.a, and only BIOS calls went to real mode
to access the disk hardware. I think it would be a win. If anybody
knows where to find a freeware DOS filesystem, speak out.
--
J. Alan Eldridge (alane AT wozzle DOT linet DOT org)
- Raw text -