× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



James,

The 16mb barrier is due the max size of an MI object.  A single allocation
greater than 16mb requires teraspace pointer support (non-MI memory model).
Teraspace pointers were first available in V4R4.  Look for the TERASPACE
parm on CRTCMOD.

Mike's observations on the performance problems associated with teraspace
pointers is both interesting and disapointing.  Hopefully this gets fixed in
newer releases.


Keith




----- Original Message ----- 
From: "James Rich" <james@xxxxxxxxxxx>
To: "C programming iSeries / AS400" <c400-l@xxxxxxxxxxxx>
Sent: Wednesday, June 30, 2004 5:08 PM
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
>
> [snip]
>
> > 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>
>
> int
> 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");
>   break;
> }
>       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.
>
>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.