«

Is the file "bcopy.c" in the "libitery" directory the implement of the
GNU C library function "bcopy"? If so, how can it run so fast?(copy-by-byte
rather than copy-by-word) When I copy the code of "libitery/bcopy.c" to my
own code, I find that it is so slow even if I turn on "-O3" and define
"NDEBUG". Why?

> Is the file "bcopy.c" in the "libitery" directory the implement of the
>GNU C library function "bcopy"?

Most likely. I'm not sure I'm looking at the same version you are,
and that interface and functionality of "bcopy()" predates GNU, I
believe, but it looks like it.

>If so, how can it run so fast?

Who claims that it does run fast, whether so or non-so? And with
what evidence?

>(copy-by-byte
>rather than copy-by-word)
>When I copy the code of "libitery/bcopy.c" to my
>own code, I find that it is so slow even if I turn on "-O3" and define
>"NDEBUG". Why?

That implementation of bcopy() (which seems to be portable to all
platforms) still runs faster than a program that needs bcopy() but
doesn't have any implementation of it at all (and therefore won't
link).

Often you have a tradeoff: pick 1:

portable and mediocre performance
unportable, good performance on some platforms,
won't work or works incorrectly on others
unportable, good performance on some platforms,
terrible performance on others

Gordon L. Burditt

Thank you for your reply, and I should say sorry for my unclear expression of these questions, which should mainly attribute to my poor English

In "libitery", I find the file, "memcpy.c". In it, there is the following code fragment,

PTR
DEFUN(memcpy, (out, in, length), PTR out AND const PTR in AND size_t length)
{
bcopy(in, out, length);
return out;
}


It is clear that memcpy() calls bcopy(). So, I open "bcopy.c" in the same directory and find these codes,

void
bcopy (src, dest, len)
register char *src, *dest;
int len;
{
if (dest < src)
while (len--)
*dest++ = *src++;
else
{
char *lasts = src + (len-1);
char *lastd = dest + (len-1);
while (len--)
*(char *)lastd-- = *(char *)lasts--;
}
}


This version of bcopy() is implemented to behave more "correctly" when memory blocks are overlaped. We know that according to the C89 standard, function memcpy() does not need to have this kind of "correct" behavior(maybe bcopy() needs for some dependence issues), and if a programmer calls memcpy() with two overlaped memory blocks, its behavior is not defined. So, I feel that this implementation of memcpy() is too awful. The following implementation can be better,

void* memcpy1 (register void* des, register void* src, register size_t len)
{
void* pdes = des;

for(; len>0; --len)
*(char*)des++ = *(char*)src++;

return pdes;
}

And it can be more efficient when copy a word directly,

void* memcpy2 (register void* des, register void* src, register size_t len)
{
void* pdes = des;

switch(len%sizeof(int))
{
case 3: *(char*)des++ = *(char*)src++;
case 2: *(char*)des++ = *(char*)src++;
case 1: *(char*)des++ = *(char*)src++;
}
for(len/=sizeof(int); len>0; --len)
*(int*)des++ = *(int*)src++;

return pdes;
}

It can be much more efficient if I copy more words rather than one word from des to src in "for" loop. Anyhow, memcpy2() should run faster than memcpy() does when processing large memory blocks, I believe. But, when I test them(copy between two 10240 bytes memory blocks), I am surprised to find that memcpy() runs the fastest. This result make me completely confused. Do you know the reason? Would you kind to explain it to me? Thank you!


Liang Chen

"Gordon Burditt" <> wrote in message news:cfk1d1$...
> > Is the file "bcopy.c" in the "libitery" directory the implement of the
> >GNU C library function "bcopy"?
>
> Most likely. I'm not sure I'm looking at the same version you are,
> and that interface and functionality of "bcopy()" predates GNU, I
> believe, but it looks like it.
>
> >If so, how can it run so fast?
>
> Who claims that it does run fast, whether so or non-so? And with
> what evidence?
>
> >(copy-by-byte
> >rather than copy-by-word)
> >When I copy the code of "libitery/bcopy.c" to my
> >own code, I find that it is so slow even if I turn on "-O3" and define
> >"NDEBUG". Why?
>
> That implementation of bcopy() (which seems to be portable to all
> platforms) still runs faster than a program that needs bcopy() but
> doesn't have any implementation of it at all (and therefore won't
> link).
>
> Often you have a tradeoff: pick 1:
>
> portable and mediocre performance
> unportable, good performance on some platforms,
> won't work or works incorrectly on others
> unportable, good performance on some platforms,
> terrible performance on others
>
> Gordon L. Burditt

>This version of bcopy() is implemented to behave more "correctly" when =
>memory blocks are overlaped. We know that according to the C89 standard, =
>function memcpy() does not need to have this kind of "correct" =
>behavior(maybe bcopy() needs for some dependence issues), and if a =
>programmer calls memcpy() with two overlaped memory blocks, its behavior =
>is not defined. So, I feel that this implementation of memcpy() is too =
>awful. The following implementation can be better,

I believe the "definition" of bcopy() (which is not ANSI C, but some
kind of old BSD de-facto non-standard) includes non-destructive
handling of overlapping areas. This is NOT true of memcpy() in
ANSI C but is true of memmove().

>void* memcpy1 (register void* des, register void* src, register size_t =
>len)
>{
> void* pdes =3D des;
>
> for(; len>0; --len)
> *(char*)des++ =3D *(char*)src++;
>
> return pdes;
>}
>
>And it can be more efficient when copy a word directly,

Warning: source code below appears to have been MIMEd to death.

>void* memcpy2 (register void* des, register void* src, register size_t =
>len)
>{
> void* pdes =3D des;
>
> switch(len%sizeof(int))
> {
> case 3: *(char*)des++ =3D *(char*)src++;
> case 2: *(char*)des++ =3D *(char*)src++;
> case 1: *(char*)des++ =3D *(char*)src++;
> }
> for(len/=3Dsizeof(int); len>0; --len)
> *(int*)des++ =3D *(int*)src++;

I can see no reason why the above line won't smegfault on a
majority of calls to memcpy2() on a machine which enforces alignment
restrictions. Nasty example:
char buf[10240];

... something to put some data in buf ...
memcpy2(buf+3, buf, strlen(buf)+1);

Another possibility is that the machine doesn't enforce alignment
restrictions but comes up with the wrong answer. That is, assuming
4 byte ints,
*(int *) 0xdeadbee3
fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
*NOT* 0xdeadbee3 thru 0xdeadbee6.

> return pdes;
>}
>
>It can be much more efficient if I copy more words rather than one word =
>from des to src in "for" loop.

I don't consider "segmentation fault - core dumped" to be more
efficient than anything which doesn't core dump. There are ways
to copy words at a time in the presence of alignment restrictions.
This isn't it.

>Anyhow, memcpy2() should run faster than =
>memcpy() does when processing large memory blocks, I believe.

I believe that any such statement about how performance otto-be is
made *BECAUSE* it is wrong.

>But, when =
>I test them(copy between two 10240 bytes memory blocks), I am surprised =
>to find that memcpy() runs the fastest. This result make me completely =
>confused. Do you know the reason? Would you kind to explain it to me? =
>Thank you!

I don't see any measurement methodologies or test results here.
Any performance measurements where the difference between two
ways of doing something are less than 1% or less than 10 times
the granularity of the clock being used to measure the time are
likely crap. And multitasking screws things up even worse.
The best performance demonstrations are those where you can
easily measure the difference in time with a wrist watch, *IF*
throwing the test in a loop and repeating it a million times
doesn't screw up what you are trying to measure (e.g. maybe
you don't want the test run completely from cache).

Also, are you sure you are using the memcpy() from the libiberty
directory? (As opposed to one in libc?) On FreeBSD the two
are very different.

Gordon L. Burditt

Liang Chen wrote:
>
> Part 1.1 Type: Plain Text (text/plain)
> Encoding: quoted-printable

Please do not use html or mime attachments in newsgroups.

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

> I can see no reason why the above line won't smegfault on a
> majority of calls to memcpy2() on a machine which enforces alignment
> restrictions. Nasty example:
> char buf[10240];
>
> ... something to put some data in buf ...
> memcpy2(buf+3, buf, strlen(buf)+1);

Could I consider that memcpy2() is un-portable and hardware-sensitive?

> Another possibility is that the machine doesn't enforce alignment
> restrictions but comes up with the wrong answer. That is, assuming
> 4 byte ints,
> *(int *) 0xdeadbee3
> fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
> *NOT* 0xdeadbee3 thru 0xdeadbee6.

I run and test my programmes on a PC. The CPU is Intel Pentium. The OS is
Linux 2.4.18-12L, not xBSD. I use GDB to debug memcpy2(), and I find that
the situation is not the same as you said above. *(int*)0xdeadbee3 does
fetch and store the integer, for example, at the addresses 0xdeadbee3 thru
0xdeadbee6 rather than 0xdeadbee0 thru 0xdeadbee3.

> I don't consider "segmentation fault - core dumped" to be more
> efficient than anything which doesn't core dump. There are ways
> to copy words at a time in the presence of alignment restrictions.
> This isn't it.

I checked my programme thoroughly last night. Now, memcpy2() looks like
this,

void* memcpy2 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

for(; len%sizeof(int)!=0; --len, dest=(char*)dest+1, src=(char*)src+1)
*(char*)dest = *(char*)src;
for(len/=sizeof(int); len>0; --len, dest=(int*)dest+1, src=(int*)src+1)
*(int*)dest = *(int*)src;

return pdest;
}

It is a ANSI C program this time. But my machine doesn't enforce alignment
restrictions. I do not know how to copy words at a time in the presence of
alignment restrictions. Can you give me some examples or hints?

> I don't see any measurement methodologies or test results here.
> Any performance measurements where the difference between two
> ways of doing something are less than 1% or less than 10 times
> the granularity of the clock being used to measure the time are
> likely crap. And multitasking screws things up even worse.
> The best performance demonstrations are those where you can
> easily measure the difference in time with a wrist watch, *IF*
> throwing the test in a loop and repeating it a million times
> doesn't screw up what you are trying to measure (e.g. maybe
> you don't want the test run completely from cache).

Now memcpy2() is as fast as memcpy() in library.

> Also, are you sure you are using the memcpy() from the libiberty
> directory? (As opposed to one in libc?) On FreeBSD the two
> are very different.

When I say "memcpy()", I mean the memcpy() in libc.
They are different? You mean the memcpy() in libiberty is not the real code
to be compiled to add into libc? But, does the libc be made when I MAKE a
GCC package? If it does, where is it's source codes, whatever they are C
codes or ASM codes?

Chen L.

> I can see no reason why the above line won't smegfault on a
> majority of calls to memcpy2() on a machine which enforces alignment
> restrictions. Nasty example:
> char buf[10240];
>
> ... something to put some data in buf ...
> memcpy2(buf+3, buf, strlen(buf)+1);

Could I consider that memcpy2() is un-portable and hardware-sensitive?

> Another possibility is that the machine doesn't enforce alignment
> restrictions but comes up with the wrong answer. That is, assuming
> 4 byte ints,
> *(int *) 0xdeadbee3
> fetches or stores the integer at the addresses 0xdeadbee0 thru 0xdeadbee3,
> *NOT* 0xdeadbee3 thru 0xdeadbee6.

I run and test my programmes on a PC. The CPU is Intel Pentium. The OS is
Linux 2.4.18-12L, not xBSD. I use GDB to debug memcpy2(), and I find that
the situation is not the same as you said above. *(int*)0xdeadbee3 does
fetch and store the integer, for example, at the addresses 0xdeadbee3 thru
0xdeadbee6 rather than 0xdeadbee0 thru 0xdeadbee3.

> I don't consider "segmentation fault - core dumped" to be more
> efficient than anything which doesn't core dump. There are ways
> to copy words at a time in the presence of alignment restrictions.
> This isn't it.

I checked my programme thoroughly last night. Now, memcpy2() looks like
this,

void* memcpy2 (register void* dest, register void* src, register size_t len)
{
void* pdest = dest;

for(; len%sizeof(int)!=0; --len, dest=(char*)dest+1, src=(char*)src+1)
*(char*)dest = *(char*)src;
for(len/=sizeof(int); len>0; --len, dest=(int*)dest+1, src=(int*)src+1)
*(int*)dest = *(int*)src;

return pdest;
}

It is a ANSI C program this time. But my machine doesn't enforce alignment
restrictions. I do not know how to copy words at a time in the presence of
alignment restrictions. Can you give me some examples or hints?

> I don't see any measurement methodologies or test results here.
> Any performance measurements where the difference between two
> ways of doing something are less than 1% or less than 10 times
> the granularity of the clock being used to measure the time are
> likely crap. And multitasking screws things up even worse.
> The best performance demonstrations are those where you can
> easily measure the difference in time with a wrist watch, *IF*
> throwing the test in a loop and repeating it a million times
> doesn't screw up what you are trying to measure (e.g. maybe
> you don't want the test run completely from cache).

Now memcpy2() is as fast as memcpy() in library.

> Also, are you sure you are using the memcpy() from the libiberty
> directory? (As opposed to one in libc?) On FreeBSD the two
> are very different.

When I say "memcpy()", I mean the memcpy() in libc.
They are different? You mean the memcpy() in libiberty is not the real code
to be compiled to add into libc? But, does the libc be made when I MAKE a
GCC package? If it does, where is it's source codes, whatever they are C
codes or ASM codes?

Chen L.

[someone noted possible alignment problems in some code variants]

In article <news:cfrqn3$5fo$>
Liang Chen <> wrote:
>I run and test my programmes on a PC. The CPU is Intel Pentium. ...

Pentium-based systems never[%] enforce alignment constraints.
Try a MIPS, ARM, or SPARC-based system, for instance (if you
can get hold of one).

>When I say "memcpy()", I mean the memcpy() in libc.
>They are different? You mean the memcpy() in libiberty is not the real code
>to be compiled to add into libc? But, does the libc be made when I MAKE a
>GCC package? If it does, where is it's source codes, whatever they are C
>codes or ASM codes?

None of these are really questions about using Standard C, but rather
about how to build GNU programs with nonstandard extensions.

As it happens, the answer (based on your earlier mention of underlying
OS -- which I snipped) is that they are indeed different, the source
code is not in libiberty at all, and the source code *is* available
somewhere (because of the nature of Linux) but it is difficult to
say precisely where (again because of the nature of Linux ).
The Linux C library is built when you build the Linux C library --
which, unless you-the-reader rebuild Linux, is not something you-
the-reader would normally do, even when installing various GNU
software.

As it also happens, if you use the GNU C compiler on a Pentium
system and turn optimization up high, calls to memcpy() often never
even call anything at all -- they turn into inline assembly code
instead. The compiler is allowed to do this because the name
"memcpy" is reserved, so the compiler can be sure precisely what
any call to memcpy() is supposed to do. This in turn means that
if you attempt to replace memcpy(), but do it by supplying a
different memcpy() function, your new function may never get called
at all!

The behavior described in the last paragraph above -- in which an
attempt to replace a C library function with some other substitute
fails -- is allowed by the C standard. If you want your programs
to run on any system that supports Standard C, do not attempt to
override library functions: if it works at all, it may not work
correctly.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

In article <news:> I wrote:
>Pentium-based systems never[%] enforce alignment constraints.

Gah, I forgot the footnote:

[%] What, never?
No, never!
What, never?
Well, hardly ever!

(The SSE instructions require alignment.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Chris Torek <> writes:

> In article <news:> I wrote:
>>Pentium-based systems never[%] enforce alignment constraints.
>
> Gah, I forgot the footnote:
>
> [%] What, never?
> No, never!
> What, never?
> Well, hardly ever!
>
> (The SSE instructions require alignment.)

Also, if you set bit 18, called "AC" or "Alignment Check", in
EFLAGS, then most unaligned accesses in user mode will fault.
--
"I should killfile you where you stand, worthless human." --Kaz