1. Run out of memory under WIN95
- Posted by Marcel Kollenaar <M.Kollenaar at SLO.NL>
Jul 01, 1996
-
Last edited Jul 02, 1996
On June 28, Rob Craig answered:
>[...]
>I typed in this quick example of what you seem to be doing and it
>ran ok for me under windows 3.1 with an 8Mb RAM machine.
>It generated a 1.5 Mb "junk.dat" file.
>I will try it later on a win95 machine. Maybe you can post some of
>your code so we can see more precisely what you are doing.
>[...]
Rob, Thanks for the explanation and example code.
Here follows some code of the program which ran out of memory at
the moment it read in the entire list. EX was running in a DOS-box in
WIN95.
----------- start of mycode -----------------------
-- 29/05/96
-- modified 01/07/96: translated
-- small testprogram to examine the write time for print(fnum,list)
-- for a given list with structure {{n,n},{n,n},{..,..}}.
include sort.e
include get.e
include machine.e
constant EXAMPLES = 100000 -- number of keys in list
constant SCREEN = 1 -- standard output
atom t0, t1 -- time
sequence list -- list of numbers
integer fnum -- file handle number
--with trace
--trace(1)
-- create empty list
list = {}
-- fill the list with random numbers
puts(SCREEN,"Fill the list with random numbers.\n")
t0 = time()
for i = 1 to EXAMPLES do
list = append(list,{rand(1000000),i}) -- structure {{n,n},{n,n}}
end for
t1 = time()
printf(SCREEN,"Time to create the list: %f\n",t1-t0)
-- sort the list on key-field
puts(SCREEN,"Sorting.\n")
t0 = time()
list = sort(list)
t1 = time()
printf(SCREEN,"Sorting time: %f\n",t1-t0)
-- write list to file in structure {{...},{...}}
puts(SCREEN,"Writing the list to file list.ind.\n")
fnum = open("list.ind","wb")
t0 = time()
print(fnum,list)
t1 = time()
printf(SCREEN,"Writing time: %f\n",t1-t0)
close(fnum)
-- make the list empty
list = {}
-- Read the list from disk
puts(SCREEN,"Read the list from disk.\n")
fnum = open("list.ind","rb")
t0 = time()
list = get(fnum)
t1 = time()
printf(SCREEN,"Time to read the list: %f\n",t1-t0)
close(fnum)
------------- end of mycode --------------------
To overcome temporary the problem:
I've changed the MS-DOS "settings" (I don't know how it is
called in English because I've a Dutch version) to "Pure MS-DOS",
WIN95 is closed and all what remains is good old 'new-95-MS-DOS'.
The program runs fine and at EXIT Windows starts all over again.
To get the same possibility as DOS/Windows 3.11 I changed in the
hidden systemfile MSDOS.SYS the parameter BootGUI = 1 to
BootGUI = 0 so WIN95 wil not start up and will stop after loading
AUTOEXEC.BAT. Be careful, MSDOS.SYS attribs must remain RHS after
editing. If you want to go to Windows type "WIN".
Regards,
Marcel Kollenaar
2. Re: Run out of memory under WIN95
On July 1, Marcel Kollenaar wrote:
> Here follows some code of the program which ran out of memory at
> the moment it read in the entire list. EX was running in a DOS-box in
> WIN95.
I ran your program on a 24Mb win95 machine in a DOS box.
It worked fine. The disk was quiet (not swapping). The mem command showed
23Mb of free extended memory.
I then ran it on an 8Mb win 3.11 machine under "pure" DOS.
It worked ok there too.
I then tried it in a DOS box on the same 8Mb win 3.11 machine.
During the sort it started swapping intensely and after half an hour I gave
up and hit control-alt-delete. When a program repeatedly steps through a large
sequence that won't all fit into memory the "least-recently-used"
algorithm for virtual memory breaks down badly. The program ends up
reading the disk every time for each chunk of the sequence that it needs. It
never has the required data in memory because, for example, the first part
of the sequence has always been swapped out by the time it finishes the last
part and is ready to start over again.
Regards,
Rob Craig
Rapid Deployment Software
3. Re: Run out of memory under WIN95
Robert wrote,
> I ran your program on a 24Mb win95 machine in a DOS box.
> It worked fine. The disk was quiet (not swapping). The mem command showed
> 23Mb of free extended memory.
>
> I then ran it on an 8Mb win 3.11 machine under "pure" DOS.
> It worked ok there too.
For the time being I will work under "pure" WIN95-DOS.
> I then tried it in a DOS box on the same 8Mb win 3.11 machine.
> During the sort it started swapping intensely and after half an hour I gave
> up and hit control-alt-delete. When a program repeatedly steps through a large
> sequence that won't all fit into memory the "least-recently-used"
> algorithm for virtual memory breaks down badly. The program ends up
> reading the disk every time for each chunk of the sequence that it needs. It
> never has the required data in memory because, for example, the first part
> of the sequence has always been swapped out by the time it finishes
> the last part and is ready to start over again.
Robert, I'll change the code (takes some time) to break up the
large sequence in more manageable parts (eg. 20,000 items or less),
shellsort each part, put them on disk and end up with a mergesort also
in small parts on disk, with an index on the index.
Maybe that someone who reads this has an better idee.
Thanks for your help.
Marcel Kollenaar
