I remember running a program intended for a pdp 11 for a vax.
In the intro the program finds out how much memory there is.
It returns instantaneous on the pdp 11. The vax was not finished
after the Chrismas / New year holiday with its virtual memory.
Apparently it asked for 1 K byte memory more . For this it interrogated
all buffers. They were constantly swapped out to disk memory, hence
the result. So I know: trashing is bad.

Now look here. I have an AMD with 16 Gbyte RAM. My Forth is configured
with 16 Gbyte space, this space is approximately between HERE and where
the data stack begins. (Forth itself and the return stack,block buffers are negligable)


Now look

OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
244.344mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
67782.522mS OK

Apparently zeroing a gigabyte takes approximately a quarter of a second.

8 Gigabyte would take 2 seconds. Although the whole program fits
comfortably in RAM, it takes 30 times longer.
What gives?

(This is an FX870 inasfar as that matters.)

If you are interested: this is the elf header (no sections, no debug)

"
lina16G++: file format elf64-x86-64
lina16G++
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000400078

Program Header:
LOAD off 0x0000000000000078 vaddr 0x0000000000400078 paddr \ 0x0000000000400078 align 2**12
filesz 0x000000000001e8c8 memsz 0x00000003ec004000 flags rwx

Sections:
Idx Name Size VMA LMA File off Algn SYMBOL TABLE:
no symbols

"

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Main memory (DRAM of some type) is the new hard disk.

The difference in speed between cache and main memory looks a lot like
the difference between main memory and hard disk did a few decades ago.
So if you thrash the backing store, operation will slow down.


Potentially complicating things are an OS. Is this Forth running bare
metal on the AMD with no OS? If there is an OS then all sorts of memory management issues appear.

If you need more memory space than you have physical memory, it will
seem as if your backing store is a tape drive. :-)


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@spenarnc.xs4all.nl writes:

Now look

OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
244.344mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
67782.522mS OK

Apparently zeroing a gigabyte takes approximately a quarter of a second.

8 Gigabyte would take 2 seconds. Although the whole program fits
comfortably in RAM, it takes 30 times longer.
What gives?

You obviously have other stuff in more than 8GB of RAM, and paging
enough of that out to accomodate your Forth process takes its time (or
it could also swap out parts of the memory of the Forth system).
That's why I consider swapping pretty useless these days. If RAM is
too small for your needs, buy more RAM.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2024: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 12:18:42 +0000, albert@spenarnc.xs4all.nl wrote:

[..]

8 Gigabyte would take 2 seconds. Although the whole program fits
comfortably in RAM, it takes 30 times longer.
What gives?

I don't know (yet) how it works in Linux, but in Windows there
is something called 'Working-Set'. If I exceed that value,
things slow down.

It is quite difficult (if not impossible) to increase the
Working-Set without extensive knowledge (believe me, I tried).
In iForth I have about 0.7GB now, the WSL has 2GB, FireFox 1.6GB.
This is on a 32GB system with 20GB free.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 17:51:58 +0000, mhx wrote:

I don't know (yet) how it works in Linux, but in Windows there
is something called 'Working-Set'. If I exceed that value,
things slow down.

It is quite difficult (if not impossible) to increase the
Working-Set without extensive knowledge (believe me, I tried).

Have you tried the SetProcessWorkingSetSize function
(memoryapi.h)?

It sets the minimum and maximum working set sizes for the
specified process, they say...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 18:19:44 +0000, minforth wrote:

On Mon, 23 Sep 2024 17:51:58 +0000, mhx wrote:

I don't know (yet) how it works in Linux, but in Windows there
is something called 'Working-Set'. If I exceed that value,
things slow down.

It is quite difficult (if not impossible) to increase the
Working-Set without extensive knowledge (believe me, I tried).

Have you tried the SetProcessWorkingSetSize function
(memoryapi.h)?

It sets the minimum and maximum working set sizes for the
specified process, they say...

Yes, but...
"The handle must have the PROCESS_SET_QUOTA access right.
For more information, see Process Security and Access Rights"

And there the rabbit hole opens...

It does appears to be better documented than the last time
I looked:
"PROCESS_SET_QUOTA (0x0100) Required to set memory limits using SetProcessWorkingSetSize."
... should be used with
"To retrieve a process's security descriptor, call the
GetSecurityInfo function. To change a process's security
descriptor, call the SetSecurityInfo function."

I expect it wants the executable run by an Administrator,
but that would only be a temporary nuisance.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 23 Sep 2024 19:10:08 +0000, mhx wrote:

On Mon, 23 Sep 2024 18:19:44 +0000, minforth wrote:

Have you tried the SetProcessWorkingSetSize function
(memoryapi.h)?

It sets the minimum and maximum working set sizes for the
specified process, they say...

Yes, but...

I was of the perhaps naive opinion that it would be sufficient
to get the actual min/max quota using

GetProcessWorkingSetSize(..)

then increase the max quotum and call

SetProcessWorkingSetSize(..)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <KRudnVPYhcFA8Wz7nZ2dnZfqn_SdnZ2d@earthlink.com>,
David Schultz <david.schultz@earthlink.net> wrote:

Main memory (DRAM of some type) is the new hard disk.

The difference in speed between cache and main memory looks a lot like
the difference between main memory and hard disk did a few decades ago.
So if you thrash the backing store, operation will slow down.

Potentially complicating things are an OS. Is this Forth running bare
metal on the AMD with no OS? If there is an OS then all sorts of memory >management issues appear.

If you need more memory space than you have physical memory, it will
seem as if your backing store is a tape drive. :-)

Everybody knows that, including myself.

Haven't you read the original post?
I'm not using half of the ram present.

--
http://davesrocketworks.com
David Schultz

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2024Sep23.184821@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:

albert@spenarnc.xs4all.nl writes:

Now look

OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
244.344mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
67782.522mS OK

Apparently zeroing a gigabyte takes approximately a quarter of a second.

8 Gigabyte would take 2 seconds. Although the whole program fits >>comfortably in RAM, it takes 30 times longer.
What gives?

You obviously have other stuff in more than 8GB of RAM, and paging
enough of that out to accomodate your Forth process takes its time (or
it could also swap out parts of the memory of the Forth system).
That's why I consider swapping pretty useless these days. If RAM is
too small for your needs, buy more RAM.

I have 8 Gbyte ram to spare in this situation (total 16).

However this must be the correct explanation. I never thought that the effect was
so dramatic, though. Maybe put 16 Gbyte more solves it.

Erasing memory is not comparable to a database. The part of the Forth that must be in memory at any given time is kbytes not Mbytes. Linux is apparently not smart
about it.

A
- anton

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <nnd$0b021237$626a8881@55133cc8c31c4c51>,
<albert@spenarnc.xs4all.nl> wrote:

I remember running a program intended for a pdp 11 for a vax.

<SNIP>

I confused the issue with talking too much.

I run on a AMD FX870 with 16 Gbyte RAM
I run as root, and killed the gimp prime search and firefox browser.
I also give absolute priority to Forth (nice negative).

root@cherry:/home/albert/PROJECT/ciforths/ciforth# nice -20 lina16G++

AMDX86 ciforth beta 2022Feb17
WANT ELAPSED
ASSEMBLERi86-HIGH : (WARNING) NOT PRESENT, THOUGH WANTED
OK
MARK-TIME HERE 16,000,000,000 ERASE ELAPSED .mS
12810.175mS OK
MARK-TIME HERE 16,000,000,000 ERASE ELAPSED .mS
394536.356mS OK
BYE

The second time it takes 30 times longer!

Playing around where demanding programs like
prime96 and firefox were started and terminated
is confusing , but that is not the cause of this
discrepancy.

Theories about working set doesn't cut it.
Also the system freezes, I expect better from a system with 8 cores,
but maybe this is caused by nice.

P.S.
The following result up to 8 Gbyte are more sensible,
up to 8 Gbyte the second time is faster.

root@cherry:/home/albert/PROJECT/ciforths/ciforth# nice -20 lina16G++
WANT ELAPSED
...
OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
537.777mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
253.468mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
257.628mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
781.149mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
503.593mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1916.234mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1554.072mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
8059.426mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
5519.860mS OK

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@spenarnc.xs4all.nl writes:

You obviously have other stuff in more than 8GB of RAM, and paging
enough of that out to accomodate your Forth process takes its time (or
it could also swap out parts of the memory of the Forth system).

Try shutting off swap, see "man swapoff".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@spenarnc.xs4all.nl wrote:

In article <nnd$0b021237$626a8881@55133cc8c31c4c51>,
<albert@spenarnc.xs4all.nl> wrote:

I remember running a program intended for a pdp 11 for a vax.

<SNIP>

I confused the issue with talking too much.

I run on a AMD FX870 with 16 Gbyte RAM

Have you checked how much RAM is available? Things like integrated
graphics or hole in address space for peripherials can eat hundreds
of megabytes. Linux takes part of memory for itself. Use 'free'
to know how much memory is in use. 'top' can tell you how much
memory is in use for various processes.

I run as root, and killed the gimp prime search and firefox browser.
I also give absolute priority to Forth (nice negative).

root@cherry:/home/albert/PROJECT/ciforths/ciforth# nice -20 lina16G++

AMDX86 ciforth beta 2022Feb17
WANT ELAPSED
ASSEMBLERi86-HIGH : (WARNING) NOT PRESENT, THOUGH WANTED
OK
MARK-TIME HERE 16,000,000,000 ERASE ELAPSED .mS
12810.175mS OK
MARK-TIME HERE 16,000,000,000 ERASE ELAPSED .mS
394536.356mS OK
BYE

The second time it takes 30 times longer!

You probably exceeded available memory. On first write Linux
allocates you a fresh zeroed page. To get memory Linux may have
to swap something else, but that happens only when memory use
exceeds available RAM. But on second run Linux have to bring
back what if swapped. Actually, your second time looks quite
good: linear walk trough array bigger than RAM is a classic
example of of worst case for swapping. Classic algorithm
is expected to swap the whole 16GB, I do not think that your
hardware is capable of doing it in 39 seconds.

Another possibility is delayed write: Linux may anticipate need
for more memory and schedule some parts to be written to disc.
But this normally does not happen immediately, but with some
delay (used to be 30 seconds). You can test this by waiting
few minutes between the two commands.

Theories about working set doesn't cut it.
Also the system freezes, I expect better from a system with 8 cores,
but maybe this is caused by nice.

You can not expect much when system runs out of memory. Almost
anything may need memory allocation and freezes waiting for
free memory (that is for other things to be swapped out).
Nice makes things worse, as memory eater is scheduled first
and eats available RAM and swap bandwidth.

--
Waldek Hebisch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 24 Sep 2024 12:20:42 +0000, albert@spenarnc.xs4all.nl wrote:
[..]

The following result up to 8 Gbyte are more sensible,
up to 8 Gbyte the second time is faster.

root@cherry:/home/albert/PROJECT/ciforths/ciforth# nice -20 lina16G++
WANT ELAPSED
....
OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
537.777mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
253.468mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
257.628mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
781.149mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
503.593mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1916.234mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1554.072mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
8059.426mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
5519.860mS OK

This is exactly the problem that I encountered on
Windows: allocating GBytes of memory is a lot faster
the second time you do it, which points to an OS
memory-management feature. For me it happened when
the allocated memory size was reaching 1GB on a 32GB
system with 20GB still free, so your Linux numbers are
actually quite good.

I hoped to improve matters with the Working-Set
size (which is explicitly shown on Windows 11's
Task manager) but was not successful at the time
(will look again).

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <f9e2a709183796c9cee0d60d24b0cf89@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:

On Tue, 24 Sep 2024 12:20:42 +0000, albert@spenarnc.xs4all.nl wrote:
[..]

The following result up to 8 Gbyte are more sensible,
up to 8 Gbyte the second time is faster.

root@cherry:/home/albert/PROJECT/ciforths/ciforth# nice -20 lina16G++
WANT ELAPSED
....
OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
537.777mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
253.468mS OK
MARK-TIME HERE 1,000,000,000 ERASE ELAPSED .mS
257.628mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
781.149mS OK
MARK-TIME HERE 2,000,000,000 ERASE ELAPSED .mS
503.593mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1916.234mS OK
MARK-TIME HERE 4,000,000,000 ERASE ELAPSED .mS
1554.072mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
8059.426mS OK
MARK-TIME HERE 8,000,000,000 ERASE ELAPSED .mS
5519.860mS OK

This is exactly the problem that I encountered on
Windows: allocating GBytes of memory is a lot faster
the second time you do it, which points to an OS
memory-management feature. For me it happened when
the allocated memory size was reaching 1GB on a 32GB
system with 20GB still free, so your Linux numbers are
actually quite good.

I hoped to improve matters with the Working-Set
size (which is explicitly shown on Windows 11's
Task manager) but was not successful at the time
(will look again).

Hebish explained it for a great deal.
Clearing a 16 Gbyte area was done with with a large
fraction of memory somehow used.
free reveals a 10 Gbyte memory available.
That nicely explains the discrepancy between 8 Gbyte
and 16 Gbyte clearance.

-marcel

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Sep 2024 9:53:32 +0000, albert@spenarnc.xs4all.nl wrote:

I played around with it some more on Windows 11.

FORTH> .TICKER-INFO
AMD Ryzen 7 5800X 8-Core Processor, timer & PROCESSOR-CLOCK of 4192MHz
Peak WorkingSetSize = 650 kB
Current WorkingSetSize = 631 kB
Total memory size = 31 GB
Available memory size = 16 GB
ok
FORTH> 0 VALUE am1 ok
FORTH> TIMER-RESET #2000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.215 seconds elapsed. ok

FORTH> TIMER-RESET #2000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.155 seconds elapsed. ok

Faster the second time.

FORTH> TIMER-RESET #8000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.902 seconds elapsed. ok

FORTH> TIMER-RESET #8000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.616 seconds elapsed. ok

FORTH> TIMER-RESET #8000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.583 seconds elapsed. ok

FORTH> TIMER-RESET #8000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.586 seconds elapsed. ok

With 8 GB the OS apparently is busy in the background and takes 4x as
long, a linear increase.

FORTH> TIMER-RESET #1000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.076 seconds elapsed. ok

If we go back to 1 GB the memory/diskspace is apparently pooled.

FORTH> TIMER-RESET #12000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 1.120 seconds elapsed. ok

The timing suggests that the pool is increased, not build from 0.

FORTH> TIMER-RESET #12000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.908 seconds elapsed. ok
FORTH> TIMER-RESET #12000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.881 seconds elapsed. ok

FORTH> TIMER-RESET #12000000000 ALLOCATE ?ALLOCATE TO am1 .ELAPSED
am1 FREE ?ALLOCATE 0.883 seconds elapsed. ok

FORTH> .TICKER-INFO
AMD Ryzen 7 5800X 8-Core Processor, timer & PROCESSOR-CLOCK of 4192MHz
Peak WorkingSetSize = 12075 kB
Current WorkingSetSize = 631 kB
Total memory size = 31 GB
Available memory size = 16 GB

The WorkingSetSize reflects the program's size + allocated memory.
AFAIR, this was a lot worse a few years ago.
Mysteriously, available memory size is still 16 GB.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 30 Sep 2024 15:21:57 +0000, mhx wrote:

On Mon, 30 Sep 2024 9:53:32 +0000, albert@spenarnc.xs4all.nl wrote:

[..]

FORTH> .TICKER-INFO
AMD Ryzen 7 5800X 8-Core Processor, timer & PROCESSOR-CLOCK of 4192MHz
Peak WorkingSetSize = 12075 kB
Current WorkingSetSize = 631 kB
Total memory size = 31 GB
Available memory size = 16 GB

The WorkingSetSize reflects the program's size + allocated memory.
AFAIR, this was a lot worse a few years ago.
Mysteriously, available memory size is still 16 GB.

Arrgh, this is not correct. 12075 kB is 12 MB, not 12 GB. The
workingsetsize increases, but the relation to allocated memory
is not obvious, nor is it clear that a larger Peak WorkingSetSize
means decreased allocation delays.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bug found - the units were wrong.

iSPICE> 13 tt ( allocate 13 GB )
1.000 seconds elapsed. ok
iSPICE> 13 tt .TICKER-INFO
1.113 seconds elapsed.
AMD Ryzen 7 5800X 8-Core Processor, timer & PROCESSOR-CLOCK of 4192MHz
Peak WorkingSetSize = 13982 MB
Current WorkingSetSize = 67 MB
Total memory size = 31 GB
Available memory size = 17 GB
Total paged memory size = 40 GB
Available paged memory size = 16 GB

I now use ...
SetProcessWorkingSetSizeEx(
hProcess,
1000000000, /* dwMinimumWorkingSetSize 1GB */
16000000000, /* dwMaximumWorkingSetSize 16GB */
QUOTA_LIMITS_HARDWS_MAX_DISABLE /* Flags */
);

This minimizes the time for a/the first (large)
allocation and discourages the OS to swap out
deallocated memory.

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

albert@spenarnc.xs4all.nl writes:

In article <KRudnVPYhcFA8Wz7nZ2dnZfqn_SdnZ2d@earthlink.com>,
David Schultz <david.schultz@earthlink.net> wrote:

Main memory (DRAM of some type) is the new hard disk.

The difference in speed between cache and main memory looks a lot like
the difference between main memory and hard disk did a few decades ago.
So if you thrash the backing store, operation will slow down.


Potentially complicating things are an OS. Is this Forth running bare
metal on the AMD with no OS? If there is an OS then all sorts of memory >>management issues appear.

If you need more memory space than you have physical memory, it will
seem as if your backing store is a tape drive. :-)

Everybody knows that, including myself.

Haven't you read the original post?
I'm not using half of the ram present.

You still don't know what kind of memory management strategy your OS is
using.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ve9afs$3q5al$2@amigaxess.de>,
Schlomo Goldberg <schlomo.goldberg@mailinator.com> wrote: >albert@spenarnc.xs4all.nl writes:

In article <KRudnVPYhcFA8Wz7nZ2dnZfqn_SdnZ2d@earthlink.com>,
David Schultz <david.schultz@earthlink.net> wrote:

Main memory (DRAM of some type) is the new hard disk.

The difference in speed between cache and main memory looks a lot like >>>the difference between main memory and hard disk did a few decades ago. >>>So if you thrash the backing store, operation will slow down.


Potentially complicating things are an OS. Is this Forth running bare >>>metal on the AMD with no OS? If there is an OS then all sorts of memory >>>management issues appear.

If you need more memory space than you have physical memory, it will
seem as if your backing store is a tape drive. :-)

Everybody knows that, including myself.

Haven't you read the original post?
I'm not using half of the ram present.

Others have cleared up that despite using half of the ram present
the "unused" memory is what matters most.

You still don't know what kind of memory management strategy your OS is >using.

In practice I care most for experiments. It is hard to conclude
from knowledge of strategy what your programs will do.

Groetjes Albert


--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)