Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4178 > unrolled thread

Malloc Query

Back to article view | Back to comp.lang.c

Contents

  Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-17 19:39 +0000
    Re: Malloc Query blp@cs.stanford.edu (Ben Pfaff) - 2011-05-17 12:55 -0700
      Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 12:05 +0100
        Re: Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-18 17:11 +0000
          Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:42 +0100
          Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:10 -0400
        Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 19:34 +0100
          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 17:10 -0400
            Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 00:26 +0100
              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 21:25 -0400
                Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-18 21:38 -0400
                  Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:11 -0400
                    Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-19 22:55 -0400
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:14 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 03:22 +0100
                  Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:20 -0400
                    Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 23:51 +0100
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 20:01 -0400
                    Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-22 02:49 -0700
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:46 -0400
                        Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 12:37 -0500
                          Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 13:02 -0500
                          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 14:12 -0400
                            Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-23 03:06 -0500
                              Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:42 -0700
                              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:10 -0400
                                Re: Malloc Query Keith Thompson <kst-u@mib.org> - 2011-05-23 09:06 -0700
                        Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:18 +0100
                          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 19:18 -0400
                            Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 11:22 +1200
                              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 01:57 -0400
                                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 19:24 +1200
                                  Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 14:20 -0400
                                    Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 07:41 +1200
                                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:24 -0400
                                        Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:20 +1200
                                          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:05 -0400
                                            Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:37 +1200
                                              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:34 -0400
                                      Re: Malloc Query "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:48 -0700
                                        Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:56 +1200
                                    Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:19 -0400
                                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:32 -0400
                            Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 01:04 +0100
                              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 02:36 -0400
                                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:39 -0700
                                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 14:44 +0100
                                  Re: Malloc Query Seebs <usenet-nospam@seebs.net> - 2011-05-23 15:16 +0000
                                  Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:41 -0400
                                  Re: Malloc Query David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
                  Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 18:34 -0400
                    Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 02:36 +0100
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:26 -0400
                        Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 23:32 +0100
                          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 21:17 -0400
                    Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-21 14:30 +1200
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 11:13 -0400
                        Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 08:50 +1200
                          Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 20:03 -0400
                            Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 13:23 +1200
                              Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:01 -0400
                    Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-26 08:12 +0200
                      Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-26 19:16 +1200
                        Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:03 -0400
                          Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:16 +1200
                            Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 17:55 -0400
                          Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-27 05:47 +0200
                      Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:02 -0400
          Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:31 +0100
            Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 23:37 +0100
              Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 01:50 +0100
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 02:50 +0100
                  Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 12:14 +0100
                    Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 15:10 +0100
                      Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 15:48 +0100
        Re: Malloc Query cri@tiac.net (Richard Harter) - 2011-05-18 19:31 +0000
        Re: Malloc Query Ike Naar <ike@iceland.freeshell.org> - 2011-05-18 21:43 +0000
          Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:58 +0100
    Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-17 14:01 -0600
    Re: Malloc Query Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-17 13:21 -0700
    Re: Malloc Query BGB <cr88192@hotmail.com> - 2011-05-17 14:08 -0700
      Re: Malloc Query Michael Press <rubrum@pacbell.net> - 2011-05-17 19:49 -0700
    Re: Malloc Query Lauri Alanko <la@iki.fi> - 2011-05-18 00:50 +0000
    Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-17 21:21 -0400
      Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-18 19:31 +0200
      Re: Malloc Query Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-18 21:36 +0000
        Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:26 -0400
      Re: Malloc Query Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 02:07 -0700
        Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-19 21:13 +1200
    Re: Malloc Query Nobody <nobody@nowhere.com> - 2011-05-18 07:08 +0100
    Re: Malloc Query David Resnick <lndresnick@gmail.com> - 2011-05-19 07:51 -0700
      Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-19 09:12 -0600

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#4510

On Sun, May 22, 2011 at 01:23:26PM +1200, Ian Collins wrote:
> On 05/22/11 12:03 PM, Uncle Steve wrote:
> >On Sun, May 22, 2011 at 08:50:26AM +1200, Ian Collins wrote:
> >>On 05/22/11 03:13 AM, Uncle Steve wrote:
> >>>On Sat, May 21, 2011 at 02:30:39PM +1200, Ian Collins wrote:
> >>>>On 05/20/11 10:34 AM, Uncle Steve wrote:
> >>>>>
> >>>>>typedef unsigned long long int T64;
> >>>>>
> >>>>>#define processcputime(p)
> >>>>>\
> >>>>
> >>>>Why go the the trouble of declaring this as a messy macro?
> >>>
> >>>I'm not all that interested in nanosecond resolution for timing
> >>>things, so I scaled the resolution down to microseconds and turned it
> >>>into a 64-bit quantity so arithmetic calculations would be more
> >>>convenient.  I suppose it could be a function call, but inline it
> >>>probably generates ten or so instructions.
> >>
> >>No more or less than an inlined function call.
> >
> >Right, so what's the problem?
> 
> Using a macro where a function would do.

IMO, this is a stylistic preference and has no meaningful impact on
code quality.
 
> >>>Insulating the actual
> >>>system function call also makes porting a little easier.
> >>
> >>But doing so in a macro makes it harder!
> >
> >Not really.  Maybe what I don't get is what you mean by 'harder'.
> >Is 'harder' some ineffable quality that in a more robust age would
> >serve to differentiate the men from the boys?  I like to think so, but
> >I don't think it's a popular view.
> 
> Well there's more to type (all those pesky line continuation characters 
> to line up), no way to step in if you have a bug you can't easily 
> diagnose and stylistic limits imposed by a macro.  The function would be 
> more concise if it could return its result.

One simply writes a replacement macro if the target platform uses
something other than clock_gettime().  If you have to use clock() or
gettime() because your system is older, changes are straightforward,
and it doesn't matter much whether you're adjusting a macro or
function.

I agree that line-continuation is a hassle to maintain, but then so is
everything.  If by 'harder' you mean more robust, I fail to see how.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

[toc] | [prev] | [next] | [standalone]

#4789

"Uncle Steve" <stevet810@gmail.com> ha scritto nel messaggio
news:fb81382c91724d0-17e8d@gmail.com...
> On Thu, May 19, 2011 at 03:22:18AM +0100, Ben Bacarisse wrote:
> [snip]
>
>
> Ok, here's a quick and dirty hack that measures a highly contrived
> scenario.  This code first allocates two arenas of different size, and
> then ping-pongs the allocations between the two arenas for a defined
> number of iterations.  Then, I do more or less the same thing with
> malloc.y
>
> The preliminary results show that my special-purpose allocator is 2-3
> times faster than glibc malloc.  Not quite and order-of-magnitude
> difference in performance (unless you think in base-2), but very
> acceptable.  In some programs there may be a larger difference in
> performance becuase of reduceed memory fragmentation or reduced
> overall memory use.  I do not plan to isolate those factors at this
> time to measure their effect.
>
> Code is compiled with "gcc -O0 -o arena_test arena_test.c -lrt"
>
> The test platform here is an Intel Atom netbook running at 1.333GHz,
> 1G RAM, OpenSuSE 11.4, libc-2.11.3, gcc 4.5.1 20101208.
>
> Typical result:
>
> [31/22:32] nb:pts/10 stevet ~/stuff/src/libs/tools/test: ./arena_test
> Arena: Iterations: 100000; elapsed CPU time (msec): 39181
> Malloc:  Iterations: 100000; elapsed CPU time (msec): 107265
>
>
> Code follows:
>
> #include <stdio.h>
> #include <malloc.h>
> #include <stdlib.h>
> #include <time.h>
> #include <sys/time.h>
>
>
> #define TEST_SIZE    1024 * 1024
> #define ITERATIONS   100000
>
> #define DIFFERENCE   5
>
>
> struct arena_head_s {
>   int      obj_size;
>   int      arena_size;
>   unsigned char *
>            arena;
>   int      free;
>   int      free_list;
> };
>
> typedef struct arena_head_s arena_head;
>
>
> #define arena_obj_addr(x, n) ((void *) &x->arena[n * x->obj_size])
>
>
> arena_qa(arena_head *x)
> {
>   int n;
>
>   n = x->free_list;
>
>   if(n != -1) {
>      x->free_list = *((int *) arena_obj_addr(x, n));
>      x->free--;
>   }
>
>   return(n);
> }
>
> void arena_free(arena_head *p, int n)
> {
>   *((int *) arena_obj_addr(p, n)) = p->free_list;
>   p->free_list = n;
>   p->free++;
>
>   return;
> }
>
> arena_head * arena_creat(size_t s, int n)
> {
>   arena_head * h;
>   int i;
>
>   h = malloc(sizeof(arena_head));
>   if(h == NULL) {
>      perror("malloc()");
>      exit(1);
>   }
>
>   h->obj_size = s;
>   h->arena_size = n;
>   h->free = n;
>
>   h->arena = malloc(s * n);
>   if(h->arena == NULL) {
>      perror("malloc()");
>      exit(1);
>   }
>
>   h->free_list = 0;
>
>   for(i = 0; i < n; i++)
>      *((int *) arena_obj_addr(h, i)) = i + 1;
>
>   *((int *) arena_obj_addr(h, i)) = -1;

this above instruction seems to write in a place where has not to write
Is it possible the space is for n elements but here it is written the
element n+1 [i=n not in 0..n-1]?

i'm not much smart, i not understand well all this code
but it seems to me the bigger error it is all can overflow and
too much confidence all goes well to the HLL
how is good assembly :)
i have the difect i see something good each little instruction at time
[too much near and too much far]

>   return(h);
> }

[toc] | [prev] | [next] | [standalone]

#4791

On 05/26/11 06:12 PM, io_x wrote:
> "Uncle Steve"<stevet810@gmail.com>  ha scritto nel messaggio
>>
>>    *((int *) arena_obj_addr(h, i)) = -1;
>
> this above instruction seems to write in a place where has not to write
> Is it possible the space is for n elements but here it is written the
> element n+1 [i=n not in 0..n-1]?

That's why I told him 5 days ago!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4826

On Thu, May 26, 2011 at 07:16:28PM +1200, Ian Collins wrote:
> On 05/26/11 06:12 PM, io_x wrote:
> >"Uncle Steve"<stevet810@gmail.com>  ha scritto nel messaggio
> >>
> >>   *((int *) arena_obj_addr(h, i)) = -1;
> >
> >this above instruction seems to write in a place where has not to write
> >Is it possible the space is for n elements but here it is written the
> >element n+1 [i=n not in 0..n-1]?
> 
> That's why I told him 5 days ago!

Did you miss the previous message that corrected the typo?



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

[toc] | [prev] | [next] | [standalone]

#4845

On 05/27/11 07:03 AM, Uncle Steve wrote:
> On Thu, May 26, 2011 at 07:16:28PM +1200, Ian Collins wrote:
>> On 05/26/11 06:12 PM, io_x wrote:
>>> "Uncle Steve"<stevet810@gmail.com>   ha scritto nel messaggio
>>>>
>>>>    *((int *) arena_obj_addr(h, i)) = -1;
>>>
>>> this above instruction seems to write in a place where has not to write
>>> Is it possible the space is for n elements but here it is written the
>>> element n+1 [i=n not in 0..n-1]?
>>
>> That's why I told him 5 days ago!
>
> Did you miss the previous message that corrected the typo?

No, why?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4847

On Fri, May 27, 2011 at 09:16:07AM +1200, Ian Collins wrote:
> On 05/27/11 07:03 AM, Uncle Steve wrote:
> >On Thu, May 26, 2011 at 07:16:28PM +1200, Ian Collins wrote:
> >>On 05/26/11 06:12 PM, io_x wrote:
> >>>"Uncle Steve"<stevet810@gmail.com>   ha scritto nel messaggio
> >>>>
> >>>>   *((int *) arena_obj_addr(h, i)) = -1;
> >>>
> >>>this above instruction seems to write in a place where has not to write
> >>>Is it possible the space is for n elements but here it is written the
> >>>element n+1 [i=n not in 0..n-1]?
> >>
> >>That's why I told him 5 days ago!
> >
> >Did you miss the previous message that corrected the typo?
> 
> No, why?

No reason.  just curious.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

[toc] | [prev] | [next] | [standalone]

#4864

"Uncle Steve" <stevet810@gmail.com> ha scritto nel messaggio
news:38207d4ffa9b1eb-1423c@gmail.com...
> On Thu, May 26, 2011 at 07:16:28PM +1200, Ian Collins wrote:
>> On 05/26/11 06:12 PM, io_x wrote:
>> >"Uncle Steve"<stevet810@gmail.com>  ha scritto nel messaggio
>> >>
>> >>   *((int *) arena_obj_addr(h, i)) = -1;
>> >
>> >this above instruction seems to write in a place where has not to write
>> >Is it possible the space is for n elements but here it is written the
>> >element n+1 [i=n not in 0..n-1]?
>>
>> That's why I told him 5 days ago!

yes i plonk Ian Collins some months ago

> Did you miss the previous message that corrected the typo?
>
>
>
> Regards,
>
> Uncle Steve
>
> -- 
> Should a professional politician be charged with molestation if he
> kisses babies while attending political rallies?
>

[toc] | [prev] | [next] | [standalone]

#4825

On Thu, May 26, 2011 at 08:12:59AM +0200, io_x wrote:
> 
> "Uncle Steve" <stevet810@gmail.com> ha scritto nel messaggio
> news:fb81382c91724d0-17e8d@gmail.com...
> > On Thu, May 19, 2011 at 03:22:18AM +0100, Ben Bacarisse wrote:
> > [snip]
> >
> >
> > Ok, here's a quick and dirty hack that measures a highly contrived
> > scenario.  This code first allocates two arenas of different size, and
> > then ping-pongs the allocations between the two arenas for a defined
> > number of iterations.  Then, I do more or less the same thing with
> > malloc.y
> >
> > The preliminary results show that my special-purpose allocator is 2-3
> > times faster than glibc malloc.  Not quite and order-of-magnitude
> > difference in performance (unless you think in base-2), but very
> > acceptable.  In some programs there may be a larger difference in
> > performance becuase of reduceed memory fragmentation or reduced
> > overall memory use.  I do not plan to isolate those factors at this
> > time to measure their effect.
> >
> > Code is compiled with "gcc -O0 -o arena_test arena_test.c -lrt"
> >
> > The test platform here is an Intel Atom netbook running at 1.333GHz,
> > 1G RAM, OpenSuSE 11.4, libc-2.11.3, gcc 4.5.1 20101208.
> >
> > Typical result:
> >
> > [31/22:32] nb:pts/10 stevet ~/stuff/src/libs/tools/test: ./arena_test
> > Arena: Iterations: 100000; elapsed CPU time (msec): 39181
> > Malloc:  Iterations: 100000; elapsed CPU time (msec): 107265
> >
> >
> > Code follows:
> >
> > #include <stdio.h>
> > #include <malloc.h>
> > #include <stdlib.h>
> > #include <time.h>
> > #include <sys/time.h>
> >
> >
> > #define TEST_SIZE    1024 * 1024
> > #define ITERATIONS   100000
> >
> > #define DIFFERENCE   5
> >
> >
> > struct arena_head_s {
> >   int      obj_size;
> >   int      arena_size;
> >   unsigned char *
> >            arena;
> >   int      free;
> >   int      free_list;
> > };
> >
> > typedef struct arena_head_s arena_head;
> >
> >
> > #define arena_obj_addr(x, n) ((void *) &x->arena[n * x->obj_size])
> >
> >
> > arena_qa(arena_head *x)
> > {
> >   int n;
> >
> >   n = x->free_list;
> >
> >   if(n != -1) {
> >      x->free_list = *((int *) arena_obj_addr(x, n));
> >      x->free--;
> >   }
> >
> >   return(n);
> > }
> >
> > void arena_free(arena_head *p, int n)
> > {
> >   *((int *) arena_obj_addr(p, n)) = p->free_list;
> >   p->free_list = n;
> >   p->free++;
> >
> >   return;
> > }
> >
> > arena_head * arena_creat(size_t s, int n)
> > {
> >   arena_head * h;
> >   int i;
> >
> >   h = malloc(sizeof(arena_head));
> >   if(h == NULL) {
> >      perror("malloc()");
> >      exit(1);
> >   }
> >
> >   h->obj_size = s;
> >   h->arena_size = n;
> >   h->free = n;
> >
> >   h->arena = malloc(s * n);
> >   if(h->arena == NULL) {
> >      perror("malloc()");
> >      exit(1);
> >   }
> >
> >   h->free_list = 0;
> >
> >   for(i = 0; i < n; i++)
> >      *((int *) arena_obj_addr(h, i)) = i + 1;
> >
> >   *((int *) arena_obj_addr(h, i)) = -1;
> 
> this above instruction seems to write in a place where has not to write
> Is it possible the space is for n elements but here it is written the
> element n+1 [i=n not in 0..n-1]?

All that statement does is simulate defining the target arena object
as a union of int, and whatever the caller plans to store in each
object slot.  It's actually a more convenient solution because in the
case where you do use a union, the code in the loop above would have
to look something like this.


for(i =0; i < (n -1); i++)
   h->arena[i].un.freelist_next = i + 1;

h->arena[i].un.freelist_next = -1;

And accessing whatever it is that is actually being stored there would
have to be similar to *arena_obj_addr(h, i) = whatever.  As the free
list management is internal to the alocator, the application should
not care what is stored in the free slots of the 'array'.

> i'm not much smart, i not understand well all this code
> but it seems to me the bigger error it is all can overflow and
> too much confidence all goes well to the HLL

There was an off-by-one error in the above code from a transcription
error, which was resolved in a subsequent message.  Otherwise, an
out-of-bounds access is the fault of the application programmer.
Caveat emptor.

> how is good assembly :)
> i have the difect i see something good each little instruction at time
> [too much near and too much far]
> 
> >   return(h);
> > }

As others have said, the requirements of kernel programming are
different from conventional application logic.  But this code is not
part of an operating system, or anything even remotely similar to an
operating system.  It is a kernel only in a limited and specialized
sense.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?

[toc] | [prev] | [next] | [standalone]

#4247

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.9e954b297cf63735a997.20110518193428BST.87zkmjuabv.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
>
>> "Ben Pfaff" <blp@cs.stanford.edu> wrote in message
>> news:87aael3xw1.fsf@blp.benpfaff.org...
> <snip>
>>> According to an academic study I read some time ago, there is
>>> rarely any significant advantage to special-purpose memory
>>> allocators.  In a quick online search, I didn't find a reference
>>> to this paper, but perhaps someone else here has a copy of it.
>>
>> I've just done a test where allocating and freeing large numbers of
>> 4-byte blocks took twenty times longer using malloc/free (and probably
>> took 2-4
>> times as much space) than using a special allocator.
>
> That's interesting, but of limited value unless you can give more
> details.  Ideally, can you post the code?  That way it can tried on
> different systems with different C libraries.

Nothing special, just a contrived example of a special allocator, in this
case (since I was short of time) just linearly allocating 100,000 ints one 
after another, then freeing them in the same order. Nevertheless, malloc
took much longer. The code I used is given below (actually it wasn't written 
in C that's why it's 1-based).

> At least say what the "special allocator" is.  Relative speed up must be
> relative to something known, not something mysterious.
>
>> How significant this is depends on the application, but I don't think
>> you can just dismiss such an allocator.
>
> But no one else can consider it either since we don't know what it is.

It depends on how much of an application is spent on these special
allocations. (In my code, I use special allocators for sizes up to 1KB, and 
malloc/free beyond that.)

#include <stdio.h>
#include <stdlib.h>

/* Use 1 for malloc/free, or 0 for the simple allocator used here */
#define USEMALLOC 1

#define maxsize 100000
int data[maxsize+1];
int* freelist=0;
int dataindex=0;

int* allocint(void){
int *p;

#if USEMALLOC
 return malloc(sizeof (int));
#endif

if (freelist) {
 p=freelist;
 freelist=(int*)*freelist;
 return p;
}
if (dataindex>=maxsize) {
 puts("Out of memory");
 exit(0);
}
return &data[++dataindex];
}

void freeint(int* p){

#if USEMALLOC
 free(p);
 return;
#endif
*p=(int)freelist;
freelist=p;
}

int main(void){
int a=0;
int i,n;

for (n=1; n<=100; ++n) {
 for (i=1; i<=maxsize; ++i)
  allocint();

 for (i=1; i<=maxsize; ++i)
  freeint(&data[i]);
}
}

 

[toc] | [prev] | [next] | [standalone]

#4254

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.9e954b297cf63735a997.20110518193428BST.87zkmjuabv.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>>
>>> "Ben Pfaff" <blp@cs.stanford.edu> wrote in message
>>> news:87aael3xw1.fsf@blp.benpfaff.org...
>> <snip>
>>>> According to an academic study I read some time ago, there is
>>>> rarely any significant advantage to special-purpose memory
>>>> allocators.  In a quick online search, I didn't find a reference
>>>> to this paper, but perhaps someone else here has a copy of it.
>>>
>>> I've just done a test where allocating and freeing large numbers of
>>> 4-byte blocks took twenty times longer using malloc/free (and probably
>>> took 2-4
>>> times as much space) than using a special allocator.
>>
>> That's interesting, but of limited value unless you can give more
>> details.  Ideally, can you post the code?  That way it can tried on
>> different systems with different C libraries.
>
> Nothing special, just a contrived example of a special allocator, in this
> case (since I was short of time) just linearly allocating 100,000 ints
> one after another, then freeing them in the same order. Nevertheless,
> malloc
> took much longer. The code I used is given below (actually it wasn't
> written in C that's why it's 1-based).

It's still not possible for me to make any assessment of this evidence.
Your measurement was not in C, and the C program you posted crashes in
both the USEMALLOC case and the other one.

I am not saying you did not see the numbers you saw.  What I *am* saying
is that it would be useful if we had numbers for specific special
allocation types (in C programs) that can be tested on various machines.
Without that, it's just another anecdote about how slow malloc is.  It
contributes to the notion of what people seem to think is true but it
does not add to the data about what is actually the case.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4263

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.39781b4c5b947949b1a8.20110518233702BST.87k4dntz3l.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> Nothing special, just a contrived example of a special allocator, in this
>> case (since I was short of time) just linearly allocating 100,000 ints
>> one after another, then freeing them in the same order. Nevertheless,
>> malloc
>> took much longer. The code I used is given below (actually it wasn't
>> written in C that's why it's 1-based).
>
> It's still not possible for me to make any assessment of this evidence.
> Your measurement was not in C, and the C program you posted crashes in
> both the USEMALLOC case and the other one.

OK, there was a mistake in the way test allocations are freed (although I
didn't see any crashes).

Fixing that, I still saw big factors (15x for gcc, in general 5x-40x
slowdown).

> I am not saying you did not see the numbers you saw.  What I *am* saying
> is that it would be useful if we had numbers for specific special
> allocation types (in C programs) that can be tested on various machines.
> Without that, it's just another anecdote about how slow malloc is.  It
> contributes to the notion of what people seem to think is true but it
> does not add to the data about what is actually the case.

malloc() can be surprisingly fast. But, in my work on interpreters, using a
custom allocator for blocks below 1KB generally makes execution faster.

For example, executing a program implementing the Binary_Trees benchmark
from the Shootout game, is about 50% faster than if malloc() was used for
everything. Sometimes, code can be much faster (such as 200% faster); 
rarely, it can run slower. (An interpreter doesn't know what code mix it 
will run.)

These numbers will vary if the malloc() implementation  changes,
or a different program is interpreted. But my point is that these custom
allocators should be taken seriously and not just dismissed.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#4269

"BartC" <bc@freeuk.com> writes:
<snip>
> These numbers will vary if the malloc() implementation  changes,
> or a different program is interpreted. But my point is that these custom
> allocators should be taken seriously and not just dismissed.

I am trying to do just that (not dismiss them).  Can you post something
I can test and time?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4315

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.6f44358df7e79cba9436.20110519025036BST.8739kbtq4z.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
> <snip>
>> These numbers will vary if the malloc() implementation  changes,
>> or a different program is interpreted. But my point is that these custom
>> allocators should be taken seriously and not just dismissed.
>
> I am trying to do just that (not dismiss them).  Can you post something
> I can test and time?

I tried a slightly more substantial test, allocating 16-byte blocks in a 
random fashion. The dedicated code was 3-6 times as fast as using malloc().

I'm not going to post code again because these things are very difficult to 
evaluate. Sometimes it is not just this scale factor that is significant, it 
might be that all the small blocks live in the same region that is an 
advantage (for example, the entire lot can be deallocated in one call to 
free*()); or that an ultra-simple allocator lends itself to being 
incorporated directly in a piece of inline assembly.

It can just be part of optimisation.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#4320

"BartC" <bc@freeuk.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.6f44358df7e79cba9436.20110519025036BST.8739kbtq4z.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>> <snip>
>>> These numbers will vary if the malloc() implementation  changes,
>>> or a different program is interpreted. But my point is that these custom
>>> allocators should be taken seriously and not just dismissed.
>>
>> I am trying to do just that (not dismiss them).  Can you post something
>> I can test and time?
>
> I tried a slightly more substantial test, allocating 16-byte blocks in
> a random fashion. The dedicated code was 3-6 times as fast as using
> malloc().
>
> I'm not going to post code again because these things are very
> difficult to evaluate.

!!!  You are protecting me from something you think I'd have trouble
evaluating?  Thanks, but I'll take the risk.

> Sometimes it is not just this scale factor that
> is significant, it might be that all the small blocks live in the same
> region that is an advantage (for example, the entire lot can be
> deallocated in one call to free*()); or that an ultra-simple allocator
> lends itself to being incorporated directly in a piece of inline
> assembly.

Yes, and sometimes there's no need to free at all; and if your
allocations are single bytes and catastrophic failure is permitted, the
allocator can be just 'return p++'.  In that case you'd be comparing
malloc(1) with an inline addition.  It's clear that at one end of the
spectrum the advantage over malloc can be made very large indeed.  At
the other end, you'll loose because it turn out malloc is better at it's
job than you imagine.  If we actually had some timing code, we'd be able
to see what the range of ratios is over different systems and for
different special-case allocation patterns.  Your code, run on several
systems, could provide some of this data.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#4325

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message 
news:0.7f305af158b42052648a.20110519151039BST.87vcx6rdb5.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:

>> Sometimes it is not just this scale factor that
>> is significant, it might be that all the small blocks live in the same
>> region that is an advantage (for example, the entire lot can be
>> deallocated in one call to free*()); or that an ultra-simple allocator
>> lends itself to being incorporated directly in a piece of inline
>> assembly.
>
> Yes, and sometimes there's no need to free at all; and if your
> allocations are single bytes and catastrophic failure is permitted, the
> allocator can be just 'return p++'.  In that case you'd be comparing
> malloc(1) with an inline addition.  It's clear that at one end of the
> spectrum the advantage over malloc can be made very large indeed.

Yes, that's why it might be worth exploiting. And also why a simplistic test 
may not be meaningful other than showing the advantage *can* be large.

> At
> the other end, you'll loose because it turn out malloc is better at it's
> job than you imagine.

That's agreed. And when the blocks are large enough the allocation overheads 
get less significant.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#4240

On Wed, 18 May 2011 12:05:20 +0100, "BartC" <bc@freeuk.com> wrote:

>
>
>"Ben Pfaff" <blp@cs.stanford.edu> wrote in message 
>news:87aael3xw1.fsf@blp.benpfaff.org...
>> Pushpa <pushpa@nospam.invalid> writes:
>>
>>> Many users claim that malloc() and free() provided by the language
>>> library results in considerable
>>> amount of overhead in terms of calling the same. Can we really
>>> eliminate overhead by using
>>> used defined functions/user defined memory manager. Is there any
>>> significant advantage in providing user defined malloc() and
>>> free().
>>
>> According to an academic study I read some time ago, there is
>> rarely any significant advantage to special-purpose memory
>> allocators.  In a quick online search, I didn't find a reference
>> to this paper, but perhaps someone else here has a copy of it.
>
>I've just done a test where allocating and freeing large numbers of 4-byte 
>blocks took twenty times longer using malloc/free (and probably took 2-4 
>times as much space) than using a special allocator.
>
>How significant this is depends on the application, but I don't think you 
>can just dismiss such an allocator.

That sounds rather odd thing to do, since on many machines the block
addresses would be as large as the block.



 

[toc] | [prev] | [next] | [standalone]

#4250

On 2011-05-18, BartC <bc@freeuk.com> wrote:
> I've just done a test where allocating and freeing large numbers of 4-byte 
> blocks took twenty times longer using malloc/free (and probably took 2-4 
> times as much space) than using a special allocator.

How does the special allocator allocate its memory?
Does it use malloc?

[toc] | [prev] | [next] | [standalone]

#4251

"Ike Naar" <ike@iceland.freeshell.org> wrote in message 
news:slrn3vfsit8fbt.eei.ike@iceland.freeshell.org...
> On 2011-05-18, BartC <bc@freeuk.com> wrote:
>> I've just done a test where allocating and freeing large numbers of 
>> 4-byte
>> blocks took twenty times longer using malloc/free (and probably took 2-4
>> times as much space) than using a special allocator.
>
> How does the special allocator allocate its memory?
> Does it use malloc?

I'm talking about allocators that request large blocks via malloc() then 
allocate smaller regions within that (although the code I posted elsewhere 
just used a static allocation for the large block).

-- 
Bartc

  

[toc] | [prev] | [next] | [standalone]

#4181

Pushpa <pushpa@nospam.invalid> writes:

> Hi all,
>
> Many users claim that malloc() and free() provided by the language
> library results in considerable
> amount of overhead in terms of calling the same. Can we really
> eliminate overhead by using
> used defined functions/user defined memory manager. Is there any
> significant advantage in providing user defined malloc() and free(). I
> want to exclude realtime systems or embedded systems which are memory
> constrained here.
> I am talking about general purpose applications. With a user defined
> memory manager can it handle
> memory allocation and de-allocation in a much better way than what OS
> would have done. Any inputs/comments
> on the same are highly appreciated.

I haven't come across the claim that they are especially expensive.  You
really aren't going to do much better trying to write a general-purpose
memory allocator.  Also, by the way, you seem to be making an assumption
that malloc() and free() are OS calls -- they aren't.  They're C library
calls.  They go on to call an OS space allocator (something in the brk()
family, last time I checked which was years ago) if they need it.

Now, if you're doing something special, you can write a special-purpose
allocator/deallocator that's optimized for it.  A long, long time ago I
wrote a program that required ridiculous numbers of memory allocations
and frees of one particular size object.  I sped that program up a lot
by maintaining my own free list of those objects, and writing my own
allocator/deallocator for them, and then only calling malloc() when my
free space pool was empty.  The kernel does something similar with its
slab allocator (though not on top of malloc()/free(), of course).
-- 
"It used to be that the USA was pretty good at producing stuff teenaged 
boys could lose a finger or two playing with."	-- James Nicoll

[toc] | [prev] | [next] | [standalone]

#4183

> amount of overhead in terms of calling the same. Can we really
> eliminate overhead by using
> used defined functions/user defined memory manager. Is there any
> significant advantage in providing user defined malloc() and free(). I

If you have an expert tailoring the functions to the specific needs of the 
program. I would say expert because with virtual memory, ignoring VM can ruin 
performance.

Few projects can afford this kind of code.

A simple alternative that works well for some programs is a mark/release 
secondary stack.

> I am talking about general purpose applications. With a user defined
> memory manager can it handle
> memory allocation and de-allocation in a much better way than what OS
> would have done. Any inputs/comments
> on the same are highly appreciated.

On systems like unix, malloc is not part of the OS; users can and do freely 
substitute alternatives to libc. The OS memory manager is brk, mmap, etc.

-- 
Damn the living - It's a lovely life.           I'm whoever you want me to be.
Silver silverware - Where is the love?       At least I can stay in character.
Oval swimming pool - Where is the love?    Annoying Usenet one post at a time.
Damn the living - It's a lovely life.                              In 1492....

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web