From: antispam@fricas.org   
      
   albert@spenarnc.xs4all.nl wrote:   
   > In article ,   
   >   wrote:   
   >>I remember running a program intended for a pdp 11 for a vax.   
   >    
   >   
   > 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: you cannot sedate... all the things you hate (1:229/2)