Re: [Freedos-devel] When is FreeDOS slow and when fast
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
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] When is FreeDOS slow and when fast
Hi,
On Sat, Oct 29, 2022 at 2:11 AM Ladislav Lacina wrote:
>
> In the last time I worked a lot with the Freepasval compiler.
> 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)
>
> FD, cwsdpmi, noUIDE, noLBAcache: 208,2s
> FD, cwsdpmi, noUIDE, LBAcache4096: 54,9s
>
> FD, cwsdpmi, UIDE160, noLBAcache: 72,1s
> FD, cwsdpmi, UIDE160, LBAcache4096: 72,2s - 178,8s
>
> The conclusions:
> 1) The speed without any cache is really awfull. On the speed machine and od
> the SSD disk!
> I do not understand why. Maybe the DOS uses some techniques which are
> contraproductive on SSDs
Cache (and even BUFFERS) takes RAM, which early DOS systems couldn't
spare. Even MS won't partition larger than 32 GB FAT32 drives because
it's slow to access it all in real mode.
> 2) Hdpmi32 does not use the RAM disk swapping while CWSDPMI does
> and it seems to be a reason why it speeds up the things so much.
> I do not understand why CWSDPMI does it even on machine with 512MB RAM.
CWSDPMI shouldn't be swapping at all. It does create an empty swap
file by default, but it doesn't use it until needed. You are using r7
from 2010, right?
CWSDPMI was designed to work on old machines (e.g. his old 386 laptop
with only 512 kb of low RAM), so it put the 4 kb page tables in low
memory, too. (He said this is also hard to debug / fix.) That will
overflow on machines with large amounts of RAM, hence the (default but
optional) r7 feature of using Pentium's 4 MB pages when possible.
HDPMI32 does presumably keep the page tables in extended memory.
If you want to load CWSDPMI resident and try without any swapping, try
"cwsdpmi -p -s-".
It's still better than Causeway, which will swap the *entire* used RAM
out to disk (instead of only how much extra is needed).
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] When is FreeDOS slow and when fast
In the last time I worked a lot with the Freepasval compiler. In the GUI
version it shows the compilation time so it is a perfect tool for
benchmarking. The results are very interresting.
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
FD, cwsdpmi, noUIDE, noLBAcache: 208,2s
FD, hdpmi32, noUIDE, noLBAcache: 159,8s
FD, cwsdpmi, noUIDE, LBAcache4096: 54,9s
FD, hdpmi32, noUIDE, LBAcache4096: 20,5s
FD, cwsdpmi, UIDE160, noLBAcache: 72,1s
FD, hdpmi32, UIDE160, noLBAcache: 40,6s
FD, cwsdpmi, UIDE160, LBAcache4096: 72,2s - 178,8s
FD, hdpmi32, UIDE160, LBAcache4096: 18,7s
FD, hdpmi32, UIDE160, LBAcache16384: 18,6s
MSDOS 7.1, hdpmi32, UIDE160, LBAcache4096: 10,4s
MSDOS 7.1, hdpmi32, UIDE160, LBAcache16383: 7,6s
The conclusions:
1) The speed without any cache is really awfull. On the speed machine and od
the SSD disk! I do not understand why. Maybe the DOS uses some techniques
which are contraproductive on SSDs
2) Hdpmi32 does not use the RAM disk swapping while CWSDPMI does and it
seems to be a reason why it speeds up the things so much. I do not
understand why CWSDPMI does it even on machine with 512MB RAM.
3) UIDE helps but even with the cache size 160MB is the gained performance
much less than from LBAcache with 4MB.
4) Windows98 is a speed king
5) MS-DOS 7.1 is faster than FreeDOS
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
