Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Thu, 26 May 2011 15:02:15 -0400 Organization: Friends of the Galactic Collective Lines: 168 Message-ID: <3f300b882b4511e-c3e99@gmail.com> References: <87aael3xw1.fsf@blp.benpfaff.org> <0.9e954b297cf63735a997.20110518193428BST.87zkmjuabv.fsf@bsb.me.uk> <0.3ac369f64d11bcd06d18.20110519002615BST.87ei3vtwtk.fsf@bsb.me.uk> <98a074c87051012-452fb@gmail.com> <0.bf5e9ff46dfbfc1e78d6.20110519032218BST.87tycrsa3p.fsf@bsb.me.uk> <4dddef1f$0$38644$4fafbaef@reader1.news.tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="HoLaDevQz+VWJX9t0+Um9g"; logging-data="21343"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1885Fi2K4PFt54XJkDrkypq" User-Agent: nn 6.7.3 Content-Length: 4802 Cancel-Lock: sha1:dyNroU+EOKWezt0Cs93EqC7eL+8= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4825 On Thu, May 26, 2011 at 08:12:59AM +0200, io_x wrote: > > "Uncle Steve" 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 > > #include > > #include > > #include > > #include > > > > > > #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?