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


Groups > comp.lang.c > #43704

Re: Defined and undefined C pointer manipulation

From Ian Collins <ian-news@hotmail.com>
Newsgroups comp.lang.c
Subject Re: Defined and undefined C pointer manipulation
Date 2014-04-28 22:38 +1200
Message-ID <bs6pd7FoqddU3@mid.individual.net> (permalink)
References (2 earlier) <ljjhvo$9o6$1@dont-email.me> <malloc-20140427210817@ram.dialup.fu-berlin.de> <26f2fae3-dd78-49dd-b55b-d891527f1efa@googlegroups.com> <bs6g7dFoqddU1@mid.individual.net> <a8478945-3b55-4361-9026-3497fc1c4246@googlegroups.com>

Show all headers | View raw


Malcolm McLean wrote:
> On Monday, April 28, 2014 9:01:49 AM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>> In both these cases it's easy to use extremely efficient algorithms to
>>> replace malloc().
>>
>> Really?  If so, why to system designers spend so much effort
>> implementing (usually more than one) efficient memory allocators?
>>
> Because they're trying to keep the same interface as malloc(), rather
> than doing a higher-level analysis of what patterns are actually going
> to be needed first? Because they are doing a higher-level analysis, but
> not doing it very well, because they are maybe less skilled, or less
> highly qualified than I am? Because they know that very simple efficient
> algorithms are available, but there's a case for using a very complex,
> over-engineered one, and they get paid to do engineering, not as a
> share of the venture's profits? Because they're writing for small specialised
> systems which have rather different requirements to those running
> general-purpose programs?

Normally because they want to get the best performance from a range of 
applications and hardware.  The better their allocator behaves, the 
better the synthetic benchmark results they can brag about.

> A stack allocator and a fixed block allocator are trivial to write, and will
> cover maybe 80% of memory allocations if a typical program is written
> to take advantage of them.

So you end up reinventing a slab allocator, which any decent system will 
already have.

-- 
Ian Collins

Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-26 18:35 +0100
  Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-26 12:04 -0700
    Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 19:11 +0100
      Re: Defined and undefined C pointer manipulation Barry Schwarz <schwarzb@dqel.com> - 2014-04-27 11:46 -0700
        Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 12:46 -0700
        Re: Defined and undefined C pointer manipulation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 02:53 +0100
      Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 12:57 -0700
        Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 21:56 +0100
          Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 14:25 -0700
            Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:51 +0000
  Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 06:21 -0700
    Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-27 16:51 +0100
      Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 10:36 -0700
      Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 11:40 +1200
  Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 19:23 +0100
    Re: Defined and undefined C pointer manipulation Richard Damon <Richard@Damon-Family.org> - 2014-04-27 14:56 -0400
      Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 20:52 +0100
        Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 13:16 -0700
    Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-27 20:55 +0100
      Re: Defined and undefined C pointer manipulation "James Harris" <james.harris.1@gmail.com> - 2014-04-27 21:20 +0100
        Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:39 +0000
        Re: Defined and undefined C pointer manipulation glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 22:43 +0000
        Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-28 00:13 +0100
    Re: Defined and undefined C pointer manipulation Keith Thompson <kst-u@mib.org> - 2014-04-27 13:01 -0700
    Re: Defined and undefined C pointer manipulation James Kuyper <jameskuyper@verizon.net> - 2014-04-27 22:07 -0400
    Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 00:47 -0700
      Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 20:01 +1200
        Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 02:11 -0700
          Re: Defined and undefined C pointer manipulation Ian Collins <ian-news@hotmail.com> - 2014-04-28 22:38 +1200
            Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 04:50 -0700
      Re: Defined and undefined C pointer manipulation "BartC" <bc@freeuk.com> - 2014-04-28 09:22 +0100
        Re: Defined and undefined C pointer manipulation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 05:31 -0700

csiph-web