sizeof([ALLOCATED MEMORY])

[Tomás]

while ( *dest = *source ) ++dest, ++source;

This one doesn't do a redundant final incrementation.

for(;*dest = *source;++dest,++source);

Nor does this one.

while ( *dest++ = *source++ );

This one does however.

for(;*dest++ = *source++;

As does this one.


-Tomás

 

[Zara]

This one doesn't do a redundant final incrementation.




Nor does this one.




This one does however.




As does this one.


-Tomás

Dont jump too fast to conclusions:

for(;*dest=*source;++dest,++source);

is compiled under one very popular compiler as the following flow in
pseudo-code

JUMPTO :TEST:
:LOOP:
READ dest
INC
STORE dest
READ source
INC source
STORE source
:TEST:
READ source
READ @source
READ dest
STORE @dest
IFNOTZERO JUMPTO :LOOP:

for(;*dest++=*source++;

is compiled under same compiler as the following flow in pseudo-code

:LOOP:
READ source
READ @source
INC source
STORE source
READ dest
STORE @dest
INC dest
STORE @dest
IFNOTZERO JUMPTO :LOOP:

Which is more optimized in code-size and, probably, also in time.


"Let the profiler tell you" is good advice, always.

Best regards,

Zara

 

[Flash Gordon]

This one doesn't do a redundant final incrementation.


Nor does this one.


This one does however.


As does this one.

Yet as was noted by the person posting them, they all produced the same
machine code thus illustrating that there is no point in selecting one
for reasons of efficiency. At least, not unless you have verified that
on your implementation it really will be more efficient.

No doubt this was in a situation where dest and source were not used
after the loop.

 

[Flash Gordon]

Not only have you fouled up the attributions, but you have fouled
the quote. It is considered very bad form to edit quotations. I
actually wrote:

while (*dest++ = *source++) continue;

as an analogy to something else.

You've made a mistake, Chuck. Tomas was replying to pete, not you, and
pete did post the quoted material.

 

[CBFalconer]

You've made a mistake, Chuck. Tomas was replying to pete, not you, and
pete did post the quoted material.

Could well be. It is threaded here as a reply to me, and was
received before the pete article arrived. Netscape is known to
have anomalies when the References chain grows too long. So when I
saw that the only article with that phrase in it was mine, which
included the 'continue'. Apologies to Tomas.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Tomás]

CBFalconer posted:

Apologies to Tomas.

No problem.


(Which reminds me I've to upgrade to the lastest version of XNews some
time soon... )


-Tomás

 

[=?iso-8859-1?q?Ion_Gazta=F1aga?=]

Not necessarily. Consider the hypothetical "one time use"

allocater. realloc need only allocate a new chunk of the
appropriate size and copy the old over. It doesn't need to know
the size of the old, even for the copying if it can detect 'the
end' by some other means, analogous to encountering EOF.

For the extended malloc interface we should see how malloc is
implemented to see if size information is there and is fast to obtain.

I don't know any malloc implementation that does not store the size. So
if the size is there in all known implementations, it's logical to
propose new functions. If all known malloc implementations (check every
C library out there to check this) store the size, I think that we
should use that information to get better performance and less memory
use.

Maybe obtaining the size is not constant time in the "one time use"
allocator and you must do something similar to "strlen()", but let's be
practical: there is not such allocator in the real world, and I doubt
it will ever exist.

So let's asume that the size information is there and is very cheap to
obtain. Now we can discuss if proposed functions improve performance or
not, or they are useful enough enough to include them in the standard.
I can understand that you can think that those advanced reallocation
functions are not useful because you might never need them for general
purpose C programming. I think that memory reallocation is a common
pattern for a lot of C programs, and that there is an easy way to
improve their performance through these functions.

Regards,

Ion

 

[CBFalconer]

CBFalconer posted:


No problem.

(Which reminds me I've to upgrade to the lastest version of XNews
some time soon... )

Your posts are invariably threaded to the wrong parent, and I
suspect the reference headers are fouled and incorrectly
truncated. This could well be caused by Xnews, which I understand
to be fairly reliable in general. So I encourage the upgrade.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Stephen Sprunk]

For the extended malloc interface we should see how malloc is
implemented to see if size information is there and is fast to obtain.

I don't know any malloc implementation that does not store the size. So
if the size is there in all known implementations, it's logical to
propose new functions. If all known malloc implementations (check every
C library out there to check this) store the size, I think that we
should use that information to get better performance and less memory
use.

<OT>
For most implementations, the size of the allocated block is trivially easy
to discover -- it's usually a few bytes before the address malloc() or
realloc() returns. Check the implementations that you care about, put in
#ifdefs that detect those implementations and deal with them, and leave in
some portable code to handle everything else.

Maybe obtaining the size is not constant time in the "one time use"
allocator and you must do something similar to "strlen()", but let's be
practical: there is not such allocator in the real world, and I doubt
it will ever exist.

IIRC, such an allocator was recommended on clc the other day to someone
whose normal malloc() didn't fit on an embedded system with only a few kB of
memory. I'm pretty sure someone, somewhere has implemented such before
because it's useful in certain cases.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin


*** ***

 

[Herbert Rosenau]

This one doesn't do a redundant final incrementation.

Says who? One of the mashines I had do use such loop it had an extra
cost of dest--, source--; at the end of the loop. The cause: the
mashine had an mashine code like

*dest++ = *source++;

as single memory to memory instruction, but not equivalent without the
increments.
So to get the final pointers right both hand needed an separate
decrement to fit the "as if" clause.

Nor does this one.

Says who? See above.

This one does however.

Best optimum because 'as if' qualifies as 'really done'. Except: don't
save spaces!
while (*dest++ = *source++) ;
= that little space helps to see that
the body is empty. More readable would be: bring the semicolon on the
next line on one more indention.

As does this one.

Yep.

As I found out since about 1990: save typing but don't save on
meaningfull comments so good as possible and let the copiler do the
optimising on mashine code level. It will do better as you ever will
get it in acceptable time.

Meaningfull comments needed for maintenance after haing the code
untouched for 12 month or longer. Save typing means: write compact
code without consideration of beginners in programming but don't
require with real experts with more than 5 years extensive experience.

Don't mircro optimazion by hand because the next compiler version may
turn back that in its absolute contrary. Rethink the algorithm you use
will give a better optimazion anyway.

Use the highest possible warning level even on the final compile with
highest optimazion, remove any diagnostic the compiler may give by
resolving the cause - but use casts only when you have rethinking the
logic and you knows exactly that you knows absolutely that you knows
exactly why you have to cast and there is nothing else that can be
done, but never cast when it is only to get the compiler quiet.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Default User]

Your posts are invariably threaded to the wrong parent, and I
suspect the reference headers are fouled and incorrectly
truncated. This could well be caused by Xnews, which I understand
to be fairly reliable in general. So I encourage the upgrade.

Hmmm. Doing a quick look at the entire thread, Tomas's messages seem to
be properly threaded for me.




Brian

 

[CBFalconer]

Hmmm. Doing a quick look at the entire thread, Tomas's messages seem to
be properly threaded for me.

I now suspect it is netscapes fault here. My reply to Tomas has 21
references, your reply to me has 20 references. References are
supposed to be cut off at 20, by deleting the 2nd oldest, and it
appears NS has not done this. Then Tomas's reply ignored the last
ref linking to me, and cut things back correctly.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[ais523]

Ion Gaztañaga wrote:

I don't know any malloc implementation that does not store the size.

<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer). It would seem
reasonable for a DOS implementation of malloc to use these system calls
to do the allocation, rounding up sizes. From the C library, unless the
size was stored separately (which would impose a performance penalty),
the size of a malloc would be impossible to determine after the malloc
had been done. Although presumably the DOS kernel itself would be
keeping track of the size somewhere, there is no portable (within DOS)
method of determining what it is. (I don't know if this method was ever
used in practice on a DOS implementation.)

(Despite the OS-specifity, I think this is ontopic because a malloc
implementation which doesn't store the size was requested.)

 

[CBFalconer]

Ion Gaztañaga wrote:


<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer). It would seem
reasonable for a DOS implementation of malloc to use these system calls
to do the allocation, rounding up sizes. From the C library, unless the
size was stored separately (which would impose a performance penalty),
the size of a malloc would be impossible to determine after the malloc
had been done. Although presumably the DOS kernel itself would be
keeping track of the size somewhere, there is no portable (within DOS)
method of determining what it is. (I don't know if this method was ever
used in practice on a DOS implementation.)

(Despite the OS-specifity, I think this is ontopic because a malloc
implementation which doesn't store the size was requested.)

And you haven't found one. The DOS system stores the size in the
16 bytes immediately preceding the assigned memory, so everything
is accessible via a segment register.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Ben Pfaff]

Ion Gaztaqaga wrote:

I don't know any malloc implementation that does not store the size.

<snip>

IIRC, DOS has system calls that act identically to malloc, realloc, and
free, except that they only accept sizes that are multiples of 16
octets (which is the alignment of the resulting pointer).
[...]

Most implementations round up to some granularity, but they store
the rounded size. DOS does this too, if I recall correctly.