|
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-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.