malloc and calloc

N

Nils Petter Vaskinn

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.
 
P

Peter Nilsson

Rahul Gandhi said:
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.
 
R

Rob Thorpe

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.
 
J

Jarno A Wuolijoki

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).
 
C

CBFalconer

Rob said:
(e-mail address removed) (Rahul Gandhi) wrote


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).
 
A

Alan Balmer

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.
 
D

Dan Pop

In said:
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
 
R

Rob Thorpe

CBFalconer said:
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.
 
M

Malcolm

Dan Pop said:
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.
 
C

Christian Bau

"Malcolm said:
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!
 
K

Keith Thompson

Christian Bau said:
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.
 
C

Christian Bau

Keith Thompson said:
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.
 
D

Dan Pop

In said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top