|
Since we are doing benchmarks:
Thu Jul 1 09:49:32 2004
allocating 8388608.000000 bytes... done.
Thu Jul 1 09:49:32 2004
allocating 16777216.000000 bytes... could not get it.
start: Thu Jul 1 09:49:32 2004
end: Thu Jul 1 09:49:32 2004
grabbed 8388608.000000 bytes of memory
System 170-2407(DSD) 1gb memory running V5R3
----------------------------
Bryan Dietz
Aktion Associates
c400-l-bounces@xxxxxxxxxxxx wrote on 07/01/2004 08:37:57 AM:
-> 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 allocated.
->
-> 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
->
-> Kent
->
->
-> -----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
->
-> [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.
->
->
-> _______________________________________________
-> 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 mailing list archive is Copyright 1997-2025 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.