Hi!
The computer: Pentium 4, SSD PATA disk, 512MB RAM
The task: Compilation of the full Blocek source ("Build all") - 64603 lines
of code using FreePascal 3.2.0 (GUI)
Windows 98: 5,6s
Everything happened on a FAT32 partition, I assume?
FD, cwsdpmi, noUIDE, noLBAcache: 208,2s
FD, hdpmi32, noUIDE, noLBAcache: 159,8s
FD, cwsdpmi, noUIDE, LBAcache4096: 54,9s
FD, hdpmi32, noUIDE, LBAcache4096: 20,5s
Note that all caches larger than BUFFERS involve some sort
of protected mode memory access today. It seems that CWSDPMI
is a lot slower than HDPMI32 here, either in the memory
access itself or in switching between modes and tasks, for
example normal protected mode ones versus VM86 style tasks.
FD, hdpmi32, UIDE160, noLBAcache: 40,6s
FD, hdpmi32, UIDE160, LBAcache4096: 18,7s
FD, hdpmi32, UIDE160, LBAcache16384: 18,6s
It does not surprise me that making the second cache
larger does not help more. The interesting part is
that using only UIDE is slower than only LBACACHE.
This could be because LBACACHE is small enough to
keep metadata tables in DOS memory, so you may see
a speed difference because it needs fewer steps of
looking at different types of memory (DOS, XMS...).
Apparently the ability to have a LARGER cache in
UIDE does not gain as much speed as the point of
having a SIMPLER cache with LBACACHE for the task.
In particular, I expect this difference to also
be related to whether or not your task uses DPMI
or any type of EMM386 style driver. It can also
make a difference whether and which EMM386 style
driver you use. It clearly does make a difference
which DPMI you use, as your results already show.
MSDOS 7.1, hdpmi32, UIDE160, LBAcache4096: 10,4s
MSDOS 7.1, hdpmi32, UIDE160, LBAcache16383: 7,6s
That could mean that MSDOS 7.1 has a kernel which
bundles I/O better, or that it has a better EMM386
or HIMEM driver, but it would be very interesting
to also see the results for MSDOS 7.1 without UIDE
and/or without LBACACHE as additional comparisons.
1) The speed without any cache is really awfull.
I agree.
On the speed machine and on the SSD disk!
SSD with BIOS I/O are not necessarily fast in
doing many tiny (512 byte sector) transfers
and without a cache, nothing might pool them
in typical DOS environments. Remember that
NWCACHE had this option to combine writes
in a small buffer in DOS memory. While the
buffer is a lot smaller than the main cache
and the feature probably added quite a bit
of complexity, I still assume it helped :-)
2) Hdpmi32 does not use the RAM disk swapping while CWSDPMI does
You can configure whether and how CWSDPMI swaps.
3) UIDE helps but even with the cache size 160MB...
You may want to try UIDE with a smaller size ;-)
4) Windows98 is a speed king
5) MS-DOS 7.1 is faster than FreeDOS
The 2 MS options are pretty similar here,
but I guess that Win98 pre-loads all FAT
metadata into RAM while booting, giving
it a "warmed up" built-in cache here.
Thanks for testing!
Regards, Eric
PS: Sorry about that off-topic PS.
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
