malloc and calloc

[Rahul Gandhi]

Which one is more fast?
malloc followed by memset
or
calloc

[Nils Petter Vaskinn]

On Mon, 02 Feb 2004 02:41:31 -0800, Rahul Gandhi wrote:

Which one is more fast?
malloc followed by memset
or
calloc

That would depend on the plattform. If there is one it probably won't be
big enough to matter. If you think it would then it's time for you to make
measurements on your target platform.

I wouldn't be surprised to see calloc implemented to just call malloc and
then memset.

--
NPV

"the large print giveth, and the small print taketh away"
Tom Waits - Step right up

[Peter Nilsson]

"Rahul Gandhi" <ga*********@hotmail.com> wrote in message
news:26**************************@posting.google.c om...

Which one is more fast?
malloc followed by memset
or
calloc

Red functions tend to go faster. But you'll have to do some profiling to
determine the appropriate chromodynamic hue of each function.

I.e. the standard doesn't impose speed requirements on functions. It's a
'Quality of Implementation' issue.

--
Peter

[Rob Thorpe]

ga*********@hotmail.com (Rahul Gandhi) wrote in message news:<26**************************@posting.google. com>...

Which one is more fast?
malloc followed by memset
or
calloc

It is platform dependent.

But do you really care about the speed of malloc? If you do you have
a part of your program that's not written very well.

You will also find that it's quite common for 'free' to be by far the
slowest.

[Jarno A Wuolijoki]

On 2 Feb 2004, Rahul Gandhi wrote:

Which one is more fast?
malloc followed by memset
or
calloc

Try to implement
a) malloc using calloc
b) calloc using malloc
...and you'll see how much reason there is for either to be slower
than another.

Then it's up to you to decide whether your focus is reasonable and
sane implementations. The standard doesn't mandate that. On
DeathStation you might have to put ifdefs depending on whether you
want less parallel throughput (several bytes/s for HPCSRNG) or
more latency (sometimes days when waiting for other callocs to
group with).

[CBFalconer]

Rob Thorpe wrote:

ga*********@hotmail.com (Rahul Gandhi) wrote

Which one is more fast?
malloc followed by memset
or
calloc

It is platform dependent.

But do you really care about the speed of malloc? If you do you
have a part of your program that's not written very well.

You will also find that it's quite common for 'free' to be by far
the slowest.

That will normally be because the system is searching for adjacent
areas to combine, which may well be O(n) where n is the count of
allocations and free blocks. This makes freeing a large
collection of items O(sqr(N)). It is shown up quite dramatically
in the test suite for hashlib, which in turn was the inspiration
for nmalloc for the DJGPP system, where those two operations
become O(1) and O(n) respectively. Both can be found at:

<http://cbfalconer.home.att.net/download/>

(nmalloc is freely available under the DJGPP license. Hashlib is
under GPL).

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Alan Balmer]

On Mon, 2 Feb 2004 22:04:31 +1100, "Peter Nilsson" <ai***@acay.com.au>
wrote:

"Rahul Gandhi" <ga*********@hotmail.com> wrote in message
news:26**************************@posting.google. com...

Which one is more fast?
malloc followed by memset
or
calloc
Red functions tend to go faster. But you'll have to do some profiling to
determine the appropriate chromodynamic hue of each function.

But the blue ones are more critical, because they're coming toward
you.
I.e. the standard doesn't impose speed requirements on functions. It's a
'Quality of Implementation' issue.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Dan Pop]

In <26**************************@posting.google.com > ga*********@hotmail.com (Rahul Gandhi) writes:

Which one is more fast?
malloc followed by memset
or
calloc

In principle, calloc could be implemented as malloc followed by memset.

However, it could skip the memset call if the allocated memory came
directly from the OS (rather than being "recycled"), because many OSs
clear themselves the memory they allocate to a program (for obvious
security reasons).

So, a calloc call need not be slower than a malloc plus a memset call,
but it could be faster. I was deliberately ignoring the cost of the
additional multiplication calloc has to perform (due to its interface).

However, this should NOT be the criterion for choosing one or another.
If your application needs zeroed memory, call calloc, otherwise call
malloc.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Rob Thorpe]

CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...

Rob Thorpe wrote:

ga*********@hotmail.com (Rahul Gandhi) wrote

Which one is more fast?
malloc followed by memset
or
calloc
It is platform dependent.

But do you really care about the speed of malloc? If you do you
have a part of your program that's not written very well.

You will also find that it's quite common for 'free' to be by far
the slowest.

That will normally be because the system is searching for adjacent
areas to combine, which may well be O(n) where n is the count of
allocations and free blocks. This makes freeing a large
collection of items O(sqr(N)).

Interesting, I've never actually looked at the time order of this. I
just read the code to some malloc's once and noticed that free
obviously did more work
It is shown up quite dramatically
in the test suite for hashlib, which in turn was the inspiration
for nmalloc for the DJGPP system, where those two operations
become O(1) and O(n) respectively. Both can be found at:

<http://cbfalconer.home.att.net/download/>

(nmalloc is freely available under the DJGPP license. Hashlib is
under GPL).

I didn't know that, but I can see the sense in "shifting the work to
the other side" in some cases. There are similar tradeoffs in GCs.

[Malcolm]

"Dan Pop" <Da*****@cern.ch> wrote in message

However, this should NOT be the criterion for choosing one or
another.
If your application needs zeroed memory, call calloc, otherwise call
malloc.

I would suggest malloc() followed by memset() for all occasions.
calloc() is a trap for the unwary, since floating point types and pointers
have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
guaranteed.
Of course your application won't suffer from these problems, but another
programmer looking at the code will be surprised to see a call to calloc(),
and ask himself, "does the programmer who wrote this really know what he is
doing?".
In some environments it is a fairly common thing to trawl through code
looking for allocations. Searches for "malloc" and "realloc" are
unavoidable. If you have to search for "calloc" as well then it adds a layer
of difficulty no-one needs.
calloc() is a nuisance function that should be allowed to fall into disuse.
malloc() followed by memset() indicates your intention to allocate a chunk
of memory and initialise it to all bits zero.

[Mark McIntyre]

On Mon, 02 Feb 2004 11:03:23 -0700, in comp.lang.c , Alan Balmer
<al******@att.net> wrote:

On Mon, 2 Feb 2004 22:04:31 +1100, "Peter Nilsson" <ai***@acay.com.au>
wrote:

Red functions tend to go faster. But you'll have to do some profiling to
determine the appropriate chromodynamic hue of each function.

But the blue ones are more critical, because they're coming toward
you.

/really/ REALLY fast.....

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Christian Bau]

In article <bv**********@newsg3.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message

However, this should NOT be the criterion for choosing one or
another.
If your application needs zeroed memory, call calloc, otherwise call
malloc.

I would suggest malloc() followed by memset() for all occasions.
calloc() is a trap for the unwary, since floating point types and pointers
have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
guaranteed.

Excuse me, but malloc () + memset () has exactly the same problem!

[Keith Thompson]

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bv**********@newsg3.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message

However, this should NOT be the criterion for choosing one or
another.
If your application needs zeroed memory, call calloc, otherwise call
malloc.

I would suggest malloc() followed by memset() for all occasions.
calloc() is a trap for the unwary, since floating point types and pointers
have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
guaranteed.

Excuse me, but malloc () + memset () has exactly the same problem!

I *think* Malcom's point is that memset() makes it more explicit that
the memory is being set to all-bits-zero, whereas calloc(), being more
implicit might lead the unwary to assume that floating-point values
are set to 0.0 and pointers to NULL.

I'm not convinced, either that Malcolm is right or that I'm correctly
guessing what he meant.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Christian Bau]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <bv**********@newsg3.svr.pol.co.uk>,
"Malcolm" <ma*****@55bank.freeserve.co.uk> wrote:

"Dan Pop" <Da*****@cern.ch> wrote in message
> However, this should NOT be the criterion for choosing one or
> another.
> If your application needs zeroed memory, call calloc, otherwise call
> malloc.
>
I would suggest malloc() followed by memset() for all occasions.
calloc() is a trap for the unwary, since floating point types and
pointers
have all bits zero for 0.0 and NULL on almost all platforms, but this
isn't
guaranteed.

Excuse me, but malloc () + memset () has exactly the same problem!

I *think* Malcom's point is that memset() makes it more explicit that
the memory is being set to all-bits-zero, whereas calloc(), being more
implicit might lead the unwary to assume that floating-point values
are set to 0.0 and pointers to NULL.

I'm not convinced, either that Malcolm is right or that I'm correctly
guessing what he meant.

Languages like Pascal did a certain amount of extra work for built-in
functions like "writeln". The C language could in principle do something
similar for calloc: Instead of calloc (nmemb, size) there could be an
alternative calloc (nmemb, type) which would allocate an array of
(nmemb) elements of the given type, each initialised like static
variables would be initialised. For example, calloc (100, double) could
with a little bit of support in the compiler allocate an array of 100
doubles, each set to 0.0.

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

I *think* Malcom's point is that memset() makes it more explicit that
the memory is being set to all-bits-zero, whereas calloc(), being more
implicit might lead the unwary to assume that floating-point values
are set to 0.0 and pointers to NULL.

Even the unwary could ask himself: how could calloc guess which bytes
are going to be used for storing floating-point values and/or pointers,
from the available information: N objects of M bytes each?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de