I tried this on V5R2 on a model 720 with 1GB main storage and it ran it all 
within 1 second.  I modified the number of bytes to allocate to be 16MB - 
100000 to allocate nearly 16MB.  Apparently some of the 16MB max is already 

start: Thu Jul  1 08:13:42 2004
end: Thu Jul  1 08:13:42 2004   
grabbed 16677216 bytes of memory

Using teraspace I got the following results:
start: Thu Jul  1 08:36:18 2004    
end: Thu Jul  1 08:36:20 2004      
grabbed 2147483148 bytes of memory


-----Original Message-----
From: James Rich [mailto:james@xxxxxxxxxxx]
Sent: Wednesday, June 30, 2004 8:08 PM
To: C programming iSeries / AS400
Subject: Re: [C400-L] RE: Porting C Linux to ILE C: Performance problem

On Wed, 30 Jun 2004, Mike Mills wrote:

> How much memory are you allocating?  In particular, are you allocating and
> using more than 16MB?  It used to be that you could not malloc() more than


> You can test this yourself by writing a small C program that allocates, say,
> 32MB of memory, and then loops through 'touching' each byte.  If you print a
> message every megabyte or so, you can see the slowdown immediately after
> crossing the 16MB boundary - assuming the problem still exists.

I was curious so I wrote a program along these lines.  It doesn't touch
the bytes but nonetherless was instructive.  It also just uses malloc()
instead of realloc().

Here are the results on linux 2.6.3 (slackware 9.1) AMD Athlon 450 MHz
256 MB RAM:

start: Wed Jun 30 17:47:45 2004
end: Wed Jun 30 17:47:45 2004
grabbed 16777216.000000 bytes of memory

On another linux machine running 2.4.18 on a Pentium 200 MHz with 32MB RAM
I get the same results as above.

On V4R1 old machine with 96(?) MB RAM and unsure of CPU (sorry that's not
too helpful):

start: Wed Jun 30 17:57:42 2004
end: Wed Jun 30 17:57:46 2004
grabbed 8388608.000000 bytes of memory

Interesting part is that it could not allocate 16MB of memory.  And it
took 4 seconds to do it's work.  Compared to linux which didn't fail until
I tried allocating 1 GB of memory and did it in under 1 second (too short
to measure with my crude methods here).

I wonder why the 16 MB malloc() failed?  I wonder why the 4 seconds?

Anyway, here is the code:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <locale.h>
#include <math.h>

main ()
  char *buffer;
  char startstring[50];
  time_t curtime;
  struct tm *curdate;
  int i;

  setlocale (LC_ALL, "");
  curtime = time (NULL);
  curdate = localtime (&curtime);
  sprintf (startstring, "start: %s", asctime (curdate));
  fprintf (stderr, "%s", startstring);
  buffer = malloc (2);

  for (i = 2; i <= 24; i++)
      curtime = time (NULL);
      curdate = localtime (&curtime);
      fprintf (stderr, "%s\tallocating %lf bytes... ", asctime (curdate),
               pow (2, i));
      buffer = malloc (pow (2, i));
      if (buffer == NULL)
          free (buffer);
          fprintf (stderr, "could not get it.\n");
      free (buffer);
      fprintf (stderr, "done.\n");
  curtime = time (NULL);
  curdate = localtime (&curtime);
  fprintf (stderr, "\n%s", startstring);
  fprintf (stderr, "end: %s", asctime (curdate));
  fprintf (stderr, "grabbed %lf bytes of memory\n", pow (2, (i - 1)));
  return (0);

James Rich

Vs lbh cynl n Zvpebfsg PQ  onpxjneqf, lbh pna urne fngnavp zrffntrf. Ohg
rira jbefr, vs lbh cynl vg sbejneq, vg vafgnyyf gurve fbsgjner!
        -- Fcbgvphf ba /.
This is the C programming iSeries / AS400 (C400-L) mailing list
To post a message email: C400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/c400-l.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].