RE: regarding memmov( )

["Bukka, Veerasham" <vbukka lucent com>]

Hi,

First let me say sorry, i donot know exactly for what this list intend to
use. 
And your guess is correct, i am interested to know about memmove() not
memmov()...  typo error.

Thanks a lot,
/
Veeresh.

gcc gcc gnu org

-----Original Message-----
From: Kaz Kylheku [mailto:kaz ashi footprints net]
Sent: Wednesday, October 18, 2000 3:42 PM
To: Bukka, Veerasham
Cc: 'gtk-devel-list gnome org'
Subject: Re: regarding memmov( )


On Wed, 18 Oct 2000, Bukka, Veerasham wrote:

> Date: Wed, 18 Oct 2000 15:20:30 -0400
> From: "Bukka, Veerasham" <vbukka lucent com>
> To: "'gtk-devel-list gnome org'" <gtk-devel-list gnome org>
> Subject: regarding memmov( )
> 
> Hi,
> 
> I want to know how expensive is memmov() in terms of time??

Surely you mean memmove? There is no memmov.  Also, what does that have
to do with GTK?

> Is there any function, which can be efficient than memmov()??
> How the time taken by memmov() related to the size of the memory to be
> moved??

A reasonable, platform-independent assumption is that it is directly
proportional, when the moves are large, with a constant that depends on the
memory bandwidth. The actual behavior of many small moves will depend on
caching.

In principle, moves in which the source and destination address happend to
be
page aligned could be achieved by virtual memory trickery; simply fudge the
page tables of the process so that the data magically appears in different
virtual pages, then just take care remainder data at the end of the last
page.
Copy-on-write could be used to split the pages on demand when they
are modified.  (I don't know of any memcpy or memmove implementation which
does
anything this).

GNU libc has fairly well optimized versions of the various character and
memory
handling functions. Some functions are written in assembly language for some
architectures. Not too long ago I was looking at the i386 implementation of
memchr which loads 32 bits at a time and does some bit operation tricks to
determine whether the sought after byte is found in the source word.

Each platform has its own implementation of these functions, so you can't
make
any general statement like ``the library implementors have done a superb job
so
you don't have to worry about making your own''.  I would rather spend the
time
finding a design which avoid the memory move entirely, than worry about the
speed of the memory move.