[comp.unix.questions] Optimizing use of malloc

blarson@skat.usc.edu (Bob Larson) (10/18/87)

Most versions of malloc will round the amount of memory you request to
some number convienient for it.  Since the pointer returned must be
maximally alligned, this is normally a multiple of the size of the
largest type.  What I need to know what sizes of memory requests to
malloc will reduce wasted space for a variety of systems: bsd 4.2, bsd
4.3, sun 3.*, ultrix 32, sys v (various releases & systems)
I also need to know what to #ifdef for the various systems.  (BSD and
sys V are in separate files already, but I think the malloc stratagy
changed from 4.2 to 4.3, and likly did elsewhere.)

This is for mg (MicroGnuEmacs) (version 2a is under development).  It
will be usable without this information, however it will be slower
(reallocating memory more often) and bigger.

Please mail your replies to one of the addresses below (or just use
r).  I'll sumerize if anyone else wants the information.
--
Bob Larson		Arpa: Blarson@Ecla.Usc.Edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson		blarson@skat.usc.edu
Prime mailing list (requests):	info-prime-request%fns1@ecla.usc.edu

daveb@geac.UUCP (10/22/87)

In article <4753@oberon.USC.EDU> you write:
>Most versions of malloc will round the amount of memory you request to
>some number convienient for it.  Since the pointer returned must be
>maximally alligned, this is normally a multiple of the size of the
>largest type.  What I need to know what sizes of memory requests to
>malloc will reduce wasted space for a variety of systems: 

bsd 4.2, bsd4.3, -- long
sun 3.*,	-- not known, probably int (its a 68k)
ultrix 32, 	-- long
sys v (various releases & systems) -- varies with machine

  The basic rule is laid down by the hardware designers: if a machine
will fetch longwords from a byte address, its a don't-care. If it
requires an even address, use int alignment.  Otherwise use long.
IBM /376's can require double! (/370's require long).
  The information should vary mostly with cpu-chip, and can be
obtained from CPU manuals.

  You may find that the cost of the malloc header dominates the cost
of alignment: I wrote a paranoid/debugging allocator for GCOS 8 and
discovered header-size to be significant on that machine (which
needed long alignment).

 --dave (I couldn't get through to you by mail) c-b
-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.


-- 
 David Collier-Brown.                 {mnetor|yetti|utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind)
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.

mike@unmvax.UUCP (11/02/87)

In article <1665@geac.UUCP>, daveb@geac writes:
~In article <4753@oberon.USC.EDU> you write:
~>Most versions of malloc will round the amount of memory you request to
~>some number convienient for it.  Since the pointer returned must be
~>maximally alligned, this is normally a multiple of the size of the
~>largest type.  What I need to know what sizes of memory requests to
~>malloc will reduce wasted space for a variety of systems: 

~  The basic rule is laid down by the hardware designers: if a machine
~will fetch longwords from a byte address, its a don't-care. If it
~requires an even address, use int alignment.  Otherwise use long.
~IBM /376's can require double! (/370's require long).
~  The information should vary mostly with cpu-chip, and can be
~obtained from CPU manuals.

This is not the whole story.  On BSD, malloc uses a binary buddy
system.  So, if you request 33 longs of data, you are liable to get
more like 60.  (Not 64, because there is some header information kept
for free().)
--
				Michael I. Bushnell
				a/k/a Bach II
				mike@turing.unm.edu
				{ucbvax,gatech}!unmvax!turing!mike
---
Those aren't WINOS--that's my JUGGLER, my AERIALIST,
 my SWORD SWALLOWER, and my LATEX NOVELTY SUPPLIER!!
				-- Zippy the Pinhead
				Michael I. Bushnell
				a/k/a Bach II
				mike@turing.unm.edu
				{ucbvax,gatech}!unmvax!turing!mike
---
Those aren't WINOS--that's my JUGGLER, my AERIALIST,
 my SWORD SWALLOWER, and my LATEX NOVELTY SUPPLIER!!
				-- Zippy the Pinhead