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






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