Re: [gtk-list] g_memmove() (another RAM quickie)

[Tim Janik <timj gtk org>]

On Thu, 9 Mar 2000, Derek Simkowiak wrote:

> 
> #define     g_memmove(dest, src, num_bytes)
> 
> 	Does the difference between dest & src affect the execution time
> of a memmove() (or bcopy() )?  That is, will
> 
> /* move ten bytes not very far */
> g_memmove(pointer, pointer + 5, 10 )
> 
> 	...go faster than...
> 
> /* move ten bytes a little farther */
> g_memmove(pointer, pointer + 9999, 10 )
> 
> 	This would be for an overlapping region of memory.
> 
> 	Again, any references/docs/FAQs to read are greatly appreciated.

hm, strange question... ;)

well, usually the copying of arbitrary memory regions is done in constant
time, irregardless of the distance between source and destination (what
you are seeing there, 9999, is most probably not even the real distance
the processor is moving you data by, 'cause the virtual memory management
systems can place logical pages anywhere in physical RAM, so "distant"
pages in logical adress space of your program may end up sitting right
next to each other in physical RAM (or on the harddisk)).

you may encounter different performance behaviours though, when caching
comes into play, so say a

g_memmove (src + 5, src, 3);

may be cheaper if src is at a cache line boundary, than

g_memmove (src + 512 + 5, src, 3);

since in the first example, the destination regions is completely in the
processor's first level cache after the source region has been loaded
(assuming cache lines of >= 8 bytes, what exactly are they on most normal
processors nowadays?)
you can encounter certain (and worse) effects with the OS' page size,
since a new page you're trying to access may be residing on the hard disk,
so under extremely bad cicumstances,

g_memmove (src + 4096 + 5, src, 3);

may take several seconds, but so would probably be the case with any
other operation you program would do.

so the base line is, don't worry about distances at the g_memove() level,
rather a better and much more promising attempt is to plug memory leaks
in your program and to design small and compact structures in the first way,
if you're sure they end up being used in highly repetitive, time critical,
code sections.

i guess at this point, the discussion has become highly off-topic, but what
the heck... ;)

> 
> Thank You,
> Derek Simkowiak
> dereks@kd-dev.com
> 

---
ciaoTJ