FAQ
Hi Gophers,

Please see the code snippet, is the behavior of copy correct?
http://play.golang.org/p/8VZdwjaJst

From the document I just saw overlapping is allowed but doesn't describe
the expected result. From what real program, it seems the behavior is
similar to memmove().

As I understand memmove() does more bookkeeping hence the performance is
worse than memcpy(). Say if I have a lot of memory to copy and want to
squeeze the performance (also in my program I prefer memcpy behavior, if
it's consistent at all) is there any why in Go that I can do better than
copy()?

BTW, where can I find the copy builtin implementation in the go source
tree? the cmd/gc/builtin.c doesn't seem to have it.

Thanks
Andy

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Nov 7, 2013 at 8:56 am

    On Thu, Nov 7, 2013 at 9:42 AM, Andy Song wrote:
    Please see the code snippet, is the behavior of copy correct?
    http://play.golang.org/p/8VZdwjaJst
    AFAICS, yes.
    From the document I just saw overlapping is allowed but doesn't describe the
    expected result.
    It does. The specs says: "the result is independent of whether the
    memory referenced by the arguments overlaps". That fully defines the
    behavior because that wording is equal to saying that copy (virtually)
    makes a copy of the src to some temp first before copying that temp to
    the dest.

    -j

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andy Song at Nov 7, 2013 at 9:02 am
    Thanks Jan.
    Yes you are right, don't know how I overlooked that. Maybe I too expect
    something similar to memcpy().

    Cheers
    Andy

    On Thu, Nov 7, 2013 at 4:56 PM, Jan Mercl wrote:
    On Thu, Nov 7, 2013 at 9:42 AM, Andy Song wrote:
    Please see the code snippet, is the behavior of copy correct?
    http://play.golang.org/p/8VZdwjaJst
    AFAICS, yes.
    From the document I just saw overlapping is allowed but doesn't describe the
    expected result.
    It does. The specs says: "the result is independent of whether the
    memory referenced by the arguments overlaps". That fully defines the
    behavior because that wording is equal to saying that copy (virtually)
    makes a copy of the src to some temp first before copying that temp to
    the dest.

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andy Song at Nov 7, 2013 at 11:53 am
    BTW, the memcpy() behavior is truly tricky. e.g
    #include "string.h"
    #include "stdio.h"

    int main(){
         unsigned char m[] = {1,2,3,4,5,6,7,8,9,10};
         unsigned char *p = m;

         for (int i=0; i<10; i++){
             printf("%d ", p[i]);
         }
         printf("\n");
         memcpy(p+2, p, 8);
         for (int i=0; i<10; i++){
             printf("%d ", p[i]);
         }
         printf("\n");
         return 0;
    }

    Really hard to follow why the result is the result.

    On Thu, Nov 7, 2013 at 5:01 PM, Andy Song wrote:

    Thanks Jan.
    Yes you are right, don't know how I overlooked that. Maybe I too expect
    something similar to memcpy().

    Cheers
    Andy

    On Thu, Nov 7, 2013 at 4:56 PM, Jan Mercl wrote:
    On Thu, Nov 7, 2013 at 9:42 AM, Andy Song wrote:
    Please see the code snippet, is the behavior of copy correct?
    http://play.golang.org/p/8VZdwjaJst
    AFAICS, yes.
    From the document I just saw overlapping is allowed but doesn't
    describe the
    expected result.
    It does. The specs says: "the result is independent of whether the
    memory referenced by the arguments overlaps". That fully defines the
    behavior because that wording is equal to saying that copy (virtually)
    makes a copy of the src to some temp first before copying that temp to
    the dest.

    -j
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Nov 7, 2013 at 12:05 pm

    On 7 November 2013 11:53, Andy Song wrote:

    BTW, the memcpy() behavior is truly tricky. e.g
    #include "string.h"
    #include "stdio.h"

    int main(){
    unsigned char m[] = {1,2,3,4,5,6,7,8,9,10};
    unsigned char *p = m;

    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    memcpy(p+2, p, 8);
    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    return 0;
    }

    Really hard to follow why the result is the result.
    You know that the result is undefined, yes? Whatever
    you get for overlapping objects is whatever falls out
    of what the library-writer used as blazingly fast code
    (because otherwise, why bother).

    Chris

    --
    Chris "allusive" Dollin

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andy Song at Nov 7, 2013 at 12:19 pm
    Guess you are right. But see this link:
    http://sourceware.org/bugzilla/show_bug.cgi?id=12518

    On Thu, Nov 7, 2013 at 8:05 PM, chris dollin wrote:
    On 7 November 2013 11:53, Andy Song wrote:

    BTW, the memcpy() behavior is truly tricky. e.g
    #include "string.h"
    #include "stdio.h"

    int main(){
    unsigned char m[] = {1,2,3,4,5,6,7,8,9,10};
    unsigned char *p = m;

    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    memcpy(p+2, p, 8);
    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    return 0;
    }

    Really hard to follow why the result is the result.
    You know that the result is undefined, yes? Whatever
    you get for overlapping objects is whatever falls out
    of what the library-writer used as blazingly fast code
    (because otherwise, why bother).

    Chris

    --
    Chris "allusive" Dollin
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrey mirtchovski at Nov 7, 2013 at 3:44 pm
    the behaviour of copy() should be obvious given the following:

    https://plus.google.com/116810148281701144465/posts/GKfM9zWMXYp


    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Nov 7, 2013 at 4:42 pm

    On Thu, Nov 7, 2013 at 4:18 AM, Andy Song wrote:
    Guess you are right. But see this link:
    http://sourceware.org/bugzilla/show_bug.cgi?id=12518
    Linus is of course a great programmer, but he is also a strong
    proponent of "tools should behave as I expect" rather than "tools
    should behave as described in a written standards document." Both
    positions have their rationales, but compiler and library
    implementers, including me, tend to adopt the latter one.

    Ian

    On Thu, Nov 7, 2013 at 8:05 PM, chris dollin wrote:
    On 7 November 2013 11:53, Andy Song wrote:

    BTW, the memcpy() behavior is truly tricky. e.g
    #include "string.h"
    #include "stdio.h"

    int main(){
    unsigned char m[] = {1,2,3,4,5,6,7,8,9,10};
    unsigned char *p = m;

    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    memcpy(p+2, p, 8);
    for (int i=0; i<10; i++){
    printf("%d ", p[i]);
    }
    printf("\n");
    return 0;
    }

    Really hard to follow why the result is the result.

    You know that the result is undefined, yes? Whatever
    you get for overlapping objects is whatever falls out
    of what the library-writer used as blazingly fast code
    (because otherwise, why bother).

    Chris

    --
    Chris "allusive" Dollin

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Nov 7, 2013 at 4:47 pm

    On Thu, Nov 7, 2013 at 12:42 AM, Andy Song wrote:
    BTW, where can I find the copy builtin implementation in the go source tree?
    the cmd/gc/builtin.c doesn't seem to have it.
    The implementation of the copy builtin is runtime·copy in
    src/pkg/runtime/slice.c.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Keith Randall at Nov 8, 2013 at 12:28 am
    FWIW, memmove is only trivially more expensive than memcpy. Our (amd64)
    implementation doesn't even care about overlap sizes <= 256 bytes, and
    larger than that its a branch and a few instructions.
    On Thursday, November 7, 2013 8:47:32 AM UTC-8, Ian Lance Taylor wrote:

    On Thu, Nov 7, 2013 at 12:42 AM, Andy Song <wso...@gmail.com <javascript:>>
    wrote:
    BTW, where can I find the copy builtin implementation in the go source tree?
    the cmd/gc/builtin.c doesn't seem to have it.
    The implementation of the copy builtin is runtime·copy in
    src/pkg/runtime/slice.c.

    Ian
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 7, '13 at 8:43a
activeNov 8, '13 at 12:28a
posts10
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase