Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

Listen

Name: Anonymous 2011-04-03 6:16

memcpy should be aliased to memmove.

Thread over.

Name: Anonymous 2011-04-03 6:19

Question, why are you so autismal?

Name: Anonymous 2011-04-03 6:20

U mena [MoveMemorySegmentFrom: to: DeleteTheFirstSegment:].

Name: Anonymous 2011-04-03 7:13

Isn't memcpy faster by virtue of having to do less? I'm aware that this isn't true in GLIBC because it tests for basically everything except overlap so it's just a useless memmove, but generally speaking.

Name: Anonymous 2011-04-03 7:52

>>4
Faster by virtue of not doing any overlapping checks, thus saving about 3 processor cycles (out of 10000000000000000000)

Name: Anonymous 2011-04-03 8:31

>>4
Yes, using memcpy is so OMG OPTIMIZED.

Name: Anonymous 2011-04-03 12:44

>>5
If you need to allocate 10000000 objects, then overhead becomes significant.

Name: Anonymous 2011-04-03 13:03

>>5
Branch misprediction is not a mere 3 cycle penalty, it can be as much as 40-50 cycles. memmove needlessly pollutes the branch prediction table of modern CPUs when you know that two regions of memory don't overlap.

Name: Anonymous 2011-04-03 15:57

memcpy tells the programmer that is going to read your source code that the segments won't overlap.

Name: Anonymous 2011-04-03 18:11

>>5

memcpy may be implemented with one instruction on x86 systems (disregarding stack manipulation) memmove may have to allocate more space.

Name: Anonymous 2011-04-03 22:39

>>10
memmove may have to allocate more space
I beg you, please tell me you're trolling.

Name: Anonymous 2011-04-03 23:59

>>10
rep movs[bwd] may be much slower than an optimized memcpy using SSE's movapd/movdqa.

Name: Anonymous 2011-04-04 5:27

>>11
He's not.  Anusonix kernel has recursive memmove.

Don't change these.
Name: Email:
Entire Thread Thread List